VM scale sets with no Azure Monitor autoscale setting, stuck at a fixed instance count

What a scale set does without autoscale

A virtual machine scale set only changes size when something tells it to. Azure Monitor autoscale is the usual “something”: it adds resources when load rises and removes them when load falls, which Microsoft notes is what lowers your costs, always inside a minimum and maximum you set.

With no autoscale setting, the instance count is whatever someone last typed. Sized for peak, every quiet hour is paid for at peak. Sized for average, the first busy hour runs hot with nothing to add capacity. Either way the scale set is a fixed pool of VMs that happens to use scale-set tooling.

Finding scale sets that no autoscale setting targets

Each autoscale setting records the resource it controls in targetResourceUri. Compare that list with your scale sets:

az monitor autoscale list --query "[].targetResourceUri" -o tsv | tr 'A-Z' 'a-z' | sort > targets.txt
az vmss list --query "[].id" -o tsv | tr 'A-Z' 'a-z' | sort > vmss.txt
comm -13 targets.txt vmss.txt

Every ID printed by comm is a scale set with no autoscale setting. Both lists are lowercased first so a difference in letter case cannot hide a match.

How ZopNight decides a scale set has no setting

ZopNight looks up the autoscale settings in your subscriptions and joins them to each scale set by its resource ID. It raises the finding when:

1. The scale set is provisioned successfully or running.
2. The lookup ran and found no autoscale setting targeting that scale set.

There is no metric window or utilization threshold here; this is a configuration read made on every evaluation.

When ZopNight cannot tell, it says nothing

If the autoscale lookup was skipped, for example because the connected identity cannot read Microsoft.Insights/AutoscaleSettings, the result is unknown rather than “not configured”, and the scale set gets no finding. Scale sets that do have a setting move on to the tuning checks: Scaling Target Too High, Scaling Target Too Low and Scaling Cooldown Too Short.

Why no saving is attached

The finding carries no dollar amount. Working out what autoscale would save needs a record of how far the set could have scaled in, and a scale set that has never autoscaled has no such history. ZopNight therefore reports it as a configuration gap rather than inventing a figure. Once a setting exists, the scale-in history it produces is what the tuning checks above can reason about.

Adding an autoscale setting to the scale set

1. Create the setting with instance limits that bound cost and protect availability: az monitor autoscale create --resource-group my-rg --resource my-vmss --resource-type Microsoft.Compute/virtualMachineScaleSets --name my-vmss-autoscale --min-count 2 --max-count 10 --count 2.
2. Add a scale-out rule, for example az monitor autoscale rule create --resource-group my-rg --autoscale-name my-vmss-autoscale --condition "Percentage CPU > 70 avg 5m" --scale out 1.
3. Add the matching scale-in rule on the same metric, for example --condition "Percentage CPU < 30 avg 5m" --scale in 1.
4. Keep the minimum and maximum apart. Microsoft’s best practices point out that a setting with minimum and maximum both at 2 can never scale.
5. Review scale actions in the activity log after the first busy and quiet periods.