DevOps Peach| Vertical (scale up/down) | Horizontal (scale out/in) | |
|---|---|---|
| Changes | The size of one VM | The number of VMs |
| How | az vm resize, usually manual, may reboot |
Scale sets, usually automatic |
A Virtual Machine Scale Set (VMSS) creates many identical VMs from the same image and configuration, integrates with Load Balancer/Application Gateway and spreads across zones. Up to 1000 instances (depending on configuration); Spot can carry interruptible load. The default orchestration mode is now Flexible.
flowchart LR
M["Average CPU"] --> AS{"Autoscale as-web<br/>min 2 · default 2 · max 10"}
AS -- "> 70% for 5 min" --> OUT["Scale out +1"]
AS -- "< 30% for 5 min" --> IN["Scale in -1"]
OUT --> V["vmss-web"]
IN --> V
Autoscale
- Profile: minimum, maximum, default (used when metrics are missing).
- Rule: a metric condition (for example
Percentage CPU > 70 avg 5m) → scale out/in by N instances, with a cooldown. - Schedule: profiles for fixed dates/times (business hours, say).
- Always create pairs of out and in rules, otherwise the count only grows.
Traps: confusing scale up (size) with scale out (count); Spot VMs can be evicted at any time.
| Command | Meaning |
|---|---|
az vmss create -g rg-devops-lab -n vmss-web --image Ubuntu2204 --instance-count 2 --admin-username azureuser --generate-ssh-keys |
Create a scale set |
az vmss scale -g rg-devops-lab -n vmss-web --new-capacity 4 |
Scale manually |
az monitor autoscale create -g rg-devops-lab --resource vmss-web --resource-type Microsoft.Compute/virtualMachineScaleSets -n as-web --min-count 2 --max-count 10 --count 2 |
Create autoscale settings |
az monitor autoscale rule create -g rg-devops-lab --autoscale-name as-web --condition "Percentage CPU > 70 avg 5m" --scale out 1 |
Scale-out rule |
Orchestration modes
| Flexible | Uniform | |
|---|---|---|
| VMs | Full VM resources you can manage individually | Identical instances managed only through the scale set |
| Mixing sizes | Possible | No |
| Fault-domain and zone spreading | Yes | Yes |
| Recommended for | New workloads | Existing large stateless fleets |
Upgrading instances
When you change the model (image, extension, configuration), the upgrade policy decides when existing instances get it: Manual (you upgrade them), Automatic (all at once), or Rolling (in batches, pausing if health checks fail). Automatic OS image upgrades roll out new platform images safely using the same rolling mechanism.
Keeping instances healthy
The Application Health extension or a load balancer probe reports whether each instance's app is working. With automatic instance repairs, the scale set replaces instances that stay unhealthy. Instances should be stateless and configured entirely at boot (cloud-init or an image), because any of them can be deleted or recreated.
Controlling scale-in
A scale-in policy chooses which instances to remove: Default (balance across zones and fault domains), NewestVM, or OldestVM. Instance protection marks specific instances so scale-in, or even model upgrades, leave them alone, for example while they finish a long job.
Smarter autoscale
- Predictive autoscale learns daily and weekly CPU patterns and scales out before the load arrives.
- Rules can use custom metrics from Application Insights, such as queue length or requests per second, which often reflect demand better than CPU.
- Autoscale can send notifications by email or webhook every time it scales.
Watch the autoscale run history in the portal to see why a scale action did or did not happen; flapping usually means the scale-out and scale-in thresholds are too close together.