Azure Virtual Machine Scale Sets Explained

How a Scale Set is structured

A Scale Set is a single Azure resource that manages a pool of VM instances. All instances run the same image and configuration. Azure places an Azure Load Balancer (or Application Gateway) in front of the Scale Set to distribute incoming traffic across healthy instances.

The architecture looks like this:

• Scale Set definition — specifies the VM image, size, OS profile, network interface, and extensions
• Instance pool — the individual VMs created from that definition, each with a unique instance ID
• Load balancer — distributes traffic across instances, runs health probes, and removes unhealthy instances from rotation
• Autoscale rules — trigger scale-out (add instances) or scale-in (remove instances) based on metrics or schedules

From the application’s perspective, a Scale Set is transparent. Traffic hits the load balancer, which routes it to a healthy VM instance. The application does not need to know how many instances are running.

Uniform vs Flexible orchestration modes

Scale Sets come in two orchestration modes:

Uniform mode

All instances are identical. The Scale Set manages their lifecycle entirely. You cannot manually add existing VMs to a Uniform Scale Set. This mode is designed for stateless workloads where instances are interchangeable — web servers, API backends, worker processes. Uniform mode supports the original Scale Set autoscaling model and integrates tightly with Azure Load Balancer.

Flexible mode

Instances can be different VM sizes (within constraints), and existing VMs can be added to the Scale Set after creation. Flexible mode offers more control and aligns with Azure’s newer VM management approach. It is the recommended mode for new deployments as of 2023 and supports Availability Zones without the constraints of Uniform mode.

Creating a Scale Set

# Create a Scale Set with 2 initial instances across 2 Availability Zones
az vmss create \
  --resource-group my-rg \
  --name my-scale-set \
  --image Ubuntu2204 \
  --vm-sku Standard_D2s_v5 \
  --instance-count 2 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --zones 1 2 3 \
  --upgrade-policy-mode rolling \
  --lb "" \
  --public-ip-address ""

The —lb "" and —public-ip-address "" flags skip automatic load balancer creation. In practice, you would attach your own Azure Load Balancer or Application Gateway rather than using the one auto-created by this command, so you can configure health probes and backend pool settings precisely.

List the instances in a Scale Set:

az vmss list-instances \
  --resource-group my-rg \
  --name my-scale-set \
  --output table

Manually scale to a specific instance count:

az vmss scale \
  --resource-group my-rg \
  --name my-scale-set \
  --new-capacity 5

Health probes and instance repair

Scale Sets can automatically detect and replace unhealthy instances. Two mechanisms work together:

Load balancer health probes check whether each instance is responding on a configured endpoint. Instances that fail the probe are removed from the load balancer’s backend pool — traffic stops reaching them, but they are not deleted.

Automatic instance repairs go further: if an instance fails the health extension probe for more than a configurable grace period (default 30 minutes), the Scale Set deletes it and creates a new instance in its place. This self-healing behaviour is particularly valuable for worker processes that can fail silently.

Enable automatic repairs on an existing Scale Set:

az vmss update \
  --resource-group my-rg \
  --name my-scale-set \
  --enable-automatic-repairs true \
  --automatic-repairs-grace-period PT30M

Updating the Scale Set image

When you release a new VM image version (for example, a new version in your Azure Compute Gallery), you need to apply it to the Scale Set. The upgrade policy controls how Azure propagates the update:

• Manual: Azure does not update existing instances. You trigger upgrades explicitly with az vmss update-instances. Good for testing before rolling out broadly.
• Rolling: Azure upgrades instances in batches. You control batch size, pause between batches, and whether to pause if health probes start failing. Recommended for production.
• Automatic: Azure upgrades instances as soon as a new image version is published. Less control, but ensures instances are always on the latest image.

# Update the image version used by the Scale Set
az vmss update \
  --resource-group my-rg \
  --name my-scale-set \
  --set virtualMachineProfile.storageProfile.imageReference.version=2.0.0

# With rolling upgrade mode: Azure automatically starts upgrading in batches
# With manual upgrade mode: trigger the upgrade explicitly
az vmss update-instances \
  --resource-group my-rg \
  --name my-scale-set \
  --instance-ids "*"

When to use a Scale Set vs individual VMs

Use a Scale Set when:

• Your application is stateless and can run on any number of identical instances
• You need to scale based on traffic or queue depth without manual intervention
• High availability across Availability Zones is required
• You need consistent configuration across instances without managing them individually

Stick with individual VMs when:

• You have a stateful workload (database, legacy app with local state) that cannot be replicated across instances
• You need instances with different configurations, custom names, or special disk configurations
• You are running a single VM that does not need to scale horizontally

For containerised workloads, Azure Container Apps or AKS often replaces the need for Scale Sets entirely. Scale Sets make most sense when you specifically need full VM-level control at scale — custom kernels, OS-level agents, or workloads that cannot be containerised cleanly.