# Scaling Target Too Low

> Flags VM scale sets whose Percentage CPU scale-out threshold is under 30% and recommends raising it to 70%.

Source: https://zop.dev/integrations/azure/recommendations/scaling-target-too-low

---

## 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](https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-understanding-settings)
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

```bash
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
<a href="https://zop.dev/integrations/azure/recommendations/scaling-target-too-high">Scaling Target Too High</a>.
A set with no autoscale setting at all is covered by
<a href="https://zop.dev/integrations/azure/recommendations/vmss-autoscale-setting-not-configured">VMSS Autoscale Setting Not Configured</a>.

## 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:

```text
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.