Scale sets running a fixed instance count with no autoscale setting attached
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-ASC-002 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | vmss_no_autoscale.go |
Where it applies
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
az monitor autoscale list -g <rg> \ --query "[].{name:name, target:targetResourceUri, enabled:enabled}" -o tableA 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.