Choosing Between Uniform and Flexible Orchestration Modes in Azure Virtual Machine Scale Sets

Decision and constraints

When you create an Azure Virtual Machine Scale Set (VMSS) you must pick an orchestration mode that determines how the scale set manages its instances. The decision affects VM size homogeneity, support for Spot or low‑priority VMs, scaling granularity, and availability‑zone redundancy. Choose the mode before deployment because it cannot be changed later without deleting and recreating the scale set.

Key constraints to consider

• VM size homogeneity – Uniform mode requires every instance to use the exact same SKU; Flexible mode allows a mix of sizes and types within the same scale set.
• Spot/low‑priority usage – Only Flexible mode can allocate Spot or low‑priority VMs; Uniform mode treats all VMs as regular.
• Scaling granularity – Uniform mode scales the entire set as a single unit; Flexible mode can add or remove individual VMs, enabling per‑VM scale rules.
• Availability zones – Uniform mode supports zone‑redundant deployments across 1‑3 zones; Flexible mode does not have zone support.
• Maximum instance count – Uniform mode scales up to 1 000 VMs; Flexible mode is limited to 200 VMs.

Comparison of Uniform vs. Flexible orchestration modes

Feature	Uniform mode	Flexible mode
VM size uniformity	All instances identical SKU	Mixed SKUs allowed
Spot/low‑priority VMs	Not supported	Supported
Scaling granularity	Scale‑in/out applies to whole set	Per‑VM add/remove possible
Availability zones	Supported (zone‑redundant)	Not supported
Maximum instances	Up to 1 000	Up to 200
Typical use cases	Stateless web tiers, large homogeneous workloads	Mixed workloads, dev/test, Spot‑based batch jobs

Trade‑offs

Uniform mode simplifies management because every VM behaves the same; you can apply a single autoscale rule and rely on zone redundancy for high availability. The trade‑off is limited workload heterogeneity – you cannot run a combination of, say, Dv3 and Ev3 sizes in the same set, and you cannot leverage Spot VMs to reduce cost.

Flexible mode enables cost savings through Spot or low‑priority VMs and lets you tailor VM sizes to specific workloads (e.g., larger VMs for database nodes, smaller for front‑end). However, you lose zone redundancy, the maximum scale is lower, and you must manage more complex scaling policies because each VM can be treated individually.

Concrete implementation

The following example creates a Flexible VMSS that mixes a regular D2s_v3 VM and a Spot D2s_v3 VM, then verifies the orchestration mode.

Prerequisites

• Azure CLI version 2.30+
• Contributor or higher role on the target resource group
• A virtual network and subnet already created (replace and with your values)

Deploy via Azure CLI

az group create --name MyRG --location eastus
az vmss create \
  --resource-group MyRG \
  --name MyFlexVMSS \
  --image UbuntuLTS \
  --orchestration-mode Flexible \
  --instance-count 2 \
  --vm-sku Standard_D2s_v3 \
  --priority Spot Regular \
  --vnet-name  \
  --subnet  \
  --admin-username azureuser \
  --generate-ssh-keys

The --priority Spot Regular flag tells Azure to create the first instance as Spot and the second as regular; you can adjust the ratio as needed.

Validate the orchestration mode

After the deployment finishes, run:

az vmss show \
  --resource-group MyRG \
  --name MyFlexVMSS \
  --query orchestrationMode -o tsv

The command should return Flexible. In the Azure Portal, open the VMSS resource, select Properties, and confirm that the Orchestration mode field reads Flexible.

Limitations and rollback considerations

Because the orchestration mode is immutable, changing from Uniform to Flexible (or vice‑versa) requires deleting the existing scale set and creating a new one with the desired mode. This operation will destroy all VMs and attached data disks unless you have backed up the data or used ephemeral OS disks. Before deleting, ensure you have:

• Exported any required configuration (e.g., custom scripts, extensions)
• Drained or migrated workloads to another set
• Verified that backups or snapshots exist for persistent disks

If zone redundancy is a requirement, Uniform mode is the only viable option; Flexible mode cannot be used in that scenario.

Verification checklist

1. Confirm the VMSS was created with the intended orchestration mode via CLI or Portal.
2. Check that Spot VMs are present (if Flexible mode was chosen) by running az vmss list-instances --query "[?priority=='Spot']".
3. Validate that scaling operations behave as expected: add an instance and observe that only the target count changes, not the entire set size (Flexible) or that the whole set scales (Uniform).
4. If using Uniform mode, verify zone distribution with az vmss list-instances --query "[].zones".