What Are VM Scale Sets?
A Virtual Machine Scale Set (VMSS) is an Azure compute resource that deploys and manages a set of identical, auto-scaling VMs from a single model — defining the VM size, OS image, and configuration once and letting Azure replicate it across as many instances as your scaling rules require. Unlike managing individual VMs by hand, a scale set treats the fleet as a single unit: you update the model and roll the change out, rather than patching servers one at a time, and instances are automatically distributed across fault domains (and Availability Zones, if configured) for resiliency.
Cricket analogy: A VM Scale Set is like an IPL franchise's standardized net-bowling machine setup used across every practice pitch — the same settings are replicated at every net so all batters train under identical conditions instead of one-off configured machines.
Autoscaling
Autoscale rules let a scale set react to real conditions instead of a fixed instance count: you define metrics (like average CPU percentage, memory, or a custom Application Insights metric such as queue length) and thresholds that trigger scale-out (add instances) or scale-in (remove instances) actions, with a cooldown period to prevent rapid oscillation ('flapping'). You can also combine metric-based rules with scheduled rules — for example, scaling out ahead of a known Monday-morning traffic spike — so the fleet is sized correctly before demand arrives, not just reactively after it.
Cricket analogy: Autoscaling is like a captain bringing on extra fielders in the deep only once the opposition starts hitting sixes regularly, and pulling them back into close catching positions once the required rate cools down — reacting to the actual match situation.
Upgrade Policies and Rolling Updates
When you update the scale set model (a new image version, a config change), the upgrade policy controls how that change reaches running instances: Manual requires you to explicitly trigger each instance's upgrade; Automatic applies the change to all instances essentially at once, which can cause a brief availability gap; and Rolling upgrades instances in controlled batches with health checks between batches, pausing or rolling back if a batch's health probe fails, so a bad image doesn't take the whole fleet down at once.
Cricket analogy: A rolling upgrade is like a team resting and testing new players one at a time across a five-match series rather than fielding an entirely new eleven in one game — if a debutant flops, the damage is contained to one slot, not the whole side.
# Create a VM Scale Set (Flexible orchestration) with 2 initial instances
az vmss create \
--resource-group rg-webapp \
--name vmss-web \
--orchestration-mode Flexible \
--image Ubuntu2204 \
--instance-count 2 \
--vm-sku Standard_D2s_v5 \
--zones 1 2 3 \
--load-balancer lb-web
# Add a CPU-based autoscale rule: scale out when avg CPU > 70% for 10 min
az monitor autoscale create \
--resource-group rg-webapp --resource vmss-web \
--resource-type Microsoft.Compute/virtualMachineScaleSets \
--name autoscale-web --min-count 2 --max-count 10 --count 2
az monitor autoscale rule create \
--resource-group rg-webapp --autoscale-name autoscale-web \
--condition "Percentage CPU > 70 avg 10m" --scale out 2Scale sets support both Uniform orchestration (identical instances, numbered 0,1,2...) and Flexible orchestration (mix of VM sizes, closer to individual VM management with Availability Zone spreading). Flexible orchestration is now the recommended mode for most new workloads because it supports up to 1,000 VMs and mixes Spot and standard instances in the same set.
Aggressive autoscale thresholds without a cooldown period can cause 'flapping' — rapidly scaling out and back in — which wastes cost and can destabilize a load balancer's health probes. Always set a cooldown window (typically 5-10 minutes) between scale actions.
Health Monitoring and Instance Repair
Scale sets can be configured with automatic instance repair, which uses an Application Health extension or a load balancer health probe to detect an unhealthy instance and automatically delete and recreate it, restoring the fleet to its desired healthy count without human intervention. This works alongside Application Insights-based custom metrics, letting the scale set react not just to infrastructure health but to application-level signals like elevated error rates or slow response times.
Cricket analogy: Automatic instance repair is like a physio immediately substituting a concussed fielder under the concussion-replacement rule, bringing on a like-for-like player without waiting for the match to pause and be reorganized.
- A VM Scale Set deploys and manages a fleet of VMs from a single model, replicating configuration automatically.
- Autoscale rules react to metrics (CPU, memory, custom Application Insights signals) or schedules to add/remove instances.
- Rolling upgrades apply model changes in batches with health checks, limiting the blast radius of a bad deployment.
- Flexible orchestration mode supports up to 1,000 VMs and mixing Spot with standard instances in the same set.
- Automatic instance repair detects and replaces unhealthy instances without manual intervention.
- A cooldown period between scale actions prevents wasteful and destabilizing 'flapping.'
Practice what you learned
1. What is the primary purpose of a VM Scale Set?
2. What triggers a scale-out action in a metrics-based autoscale rule?
3. Which upgrade policy applies model changes to instances in controlled batches with health checks between batches?
4. Which orchestration mode supports mixing Spot and standard VM instances within the same scale set?
5. What does automatic instance repair do?
Was this page helpful?
You May Also Like
Azure Virtual Machines
Azure Virtual Machines (VMs) provide on-demand, resizable compute as a service, letting you run Windows or Linux workloads in Microsoft's datacenters with full control over the OS.
Azure App Service
Azure App Service is a fully managed Platform-as-a-Service for hosting web apps, REST APIs, and mobile backends without managing the underlying VMs or OS.
Azure Container Instances
Azure Container Instances (ACI) runs individual containers directly in Azure without provisioning VMs or managing a container orchestrator like Kubernetes.