# VMSS Autoscale Setting Not Configured

> RC-ASC-002 flags an Azure VM Scale Set only when the discoverer's join against microsoft.insights/autoscalesettings proves no enabled setting targets it, stamping autoscale_configured false. A fixed-count VMSS pays for peak capacity 24/7. The finding ships a ready default policy (scale out above 70% CPU with a 5-minute cooldown) while claiming $0 savings.

Source: https://zop.dev/integrations/azure/recommendations/vmss-autoscale-setting-not-configured
Updated: 2026-08-19

---

## Elastic infrastructure pinned at a fixed size

The entire premise of a scale set is elasticity, and an autoscale setting is the component
that delivers it. Without one, the VMSS holds whatever instance count it was last set to:
sized for peak load, billing for peak load at 3 a.m., and conversely unable to grow when
traffic exceeds the guess. The rule treats this as configuration hygiene on a running
scale set (provisioning state Succeeded, or running), not as a quantified cost leak.

## Authoritative evidence from a resource-graph join

Detection rides on a deliberate join in the discoverer: Azure Resource Graph queries
`microsoft.insights/autoscalesettings`, keeps enabled settings, and matches each setting's
`targetResourceUri` against VMSS ARM IDs. Every scale set then gets `autoscale_configured`
stamped `"true"` or `"false"` from membership in that result set. When the pre-query is
skipped (credential gap or query error), the key is left absent and the rule abstains,
because the earlier design showed what happens otherwise: a gate on a never-produced
`autoscaler` tag fired on literally every VMSS in the fleet.

## The honest $0 on a cost-shaped problem

Under ZopNight's concrete-or-abstain policy, a cost recommendation must carry a measured
dollar figure. Quantifying what autoscale would save requires scale-down history that a
never-autoscaled VMSS cannot have, so this rule deliberately stays in the compliance
category with SavingsUSD at zero: a $0-with-action hygiene finding, which the category
permits. The cost-quantified lever lives in the sibling rule RC-ASC-005, which fires when
an autoscale setting exists but its floor is set too high.

## Check whether any setting targets your VMSS

```bash
az monitor autoscale list -g <rg> \
  --query "[].{name:name, target:targetResourceUri, enabled:enabled}" -o table
```

A scale set whose ARM ID appears in no enabled row is exactly what this rule reports.

## A starting policy that will not flap

The finding's attached payload encodes a sane opening move: scale out by 1 instance when
average CPU exceeds 70%, with a PT5M cooldown. Add the matching scale-in rule (for example
CPU below 30% for 10 minutes), set explicit minimum, maximum, and default counts, and watch
the first week of scaling events in the activity log before tightening. Reader reproduces the
detection; configuring autoscale through ZopNight's remediation path uses the Zopnight Write
Access custom role's autoscale-settings permissions.