VM scale sets that scale out when average CPU is still under 30%

A scale-out trigger set so low the fleet never shrinks

Autoscale compares a metric with a threshold and adds instances when the rule’s condition holds. The autoscale settings schema shows each rule as a metric trigger (metric, threshold, time window, aggregation) paired with a scale action. Put the CPU threshold at 20 and the set adds VMs whenever average CPU passes 20%, which for most services is barely warm.

The effect is a fleet that settles at several times the size its load needs. Every extra instance bills at the full VM rate while running at a fraction of its capacity.

Reading the scale-out threshold on a scale set

az monitor autoscale list --resource-group my-rg \
  --query "[].{name:name, target:targetResourceUri}" -o table

az monitor autoscale show --resource-group my-rg --name my-autoscale \
  --query "profiles[].rules[?metricTrigger.metricName=='Percentage CPU' && scaleAction.direction=='Increase'].metricTrigger.threshold" \
  -o tsv

A value below 30 is what this rule reports.

Target value and cost conditions

1. The scale set is provisioned successfully or running.
2. ZopNight has read the Percentage CPU scale-out threshold from the autoscale setting that targets the scale set, and it is a number from 0 up to, but not including, 30.
3. The scale set has a monthly cost in ZopNight’s cost data. The saving is attributed to the scale set itself, so it is not counted a second time on its instances.

Scale sets left out

A scale set whose threshold is missing, unreadable, or 30 and above gets no finding, as does one without cost data. The opposite problem, a threshold so high that capacity arrives too late, is Scaling Target Too High. A set with no autoscale setting at all is covered by VMSS Autoscale Setting Not Configured.

Headroom arithmetic behind the estimate

Raising the target from T% to 70% shrinks the steady-state instance count by roughly T/70, so the over-provisioned share of the bill is what remains:

monthly saving = scale set monthly cost x (1 - current threshold / 70)

A set triggering at 20% would show about 71% of its cost as saving. Treat it as an estimate: real fleets also respect their minimum instance count and scale-in rules.

Raising the threshold to 70%

1. Open the scale set’s autoscale setting in the portal (the scale set, then Scaling), or export it with az monitor autoscale show.
2. Recreate the CPU scale-out rule at 70, for example az monitor autoscale rule create --resource-group my-rg --autoscale-name my-autoscale --condition "Percentage CPU > 70 avg 5m" --scale out 1, and delete the old rule.
3. Move the scale-in threshold up too, keeping a clear gap below 70 on the same metric so the set does not flap.
4. Watch response times and instance counts for a few days after the change.