Scale sets held above their real demand
A server group kept larger than its traffic needs
Why it happens
Someone set a floor during a busy period and it stayed. Traffic dropped, the floor did not.
A scale set gets a floor set during an incident and nobody lowers it afterwards. The capacity is paid for continuously.
Paste this into Resource Graph Explorer in the Azure portal.
resources
| where type =~ 'microsoft.compute/virtualmachinescalesets'
// Scope below matches CloudFinOpsPro policy DEFAULTS: exclusions.protectTag, environment.tagKeys,
// environment.allowedTagValues, and allowUntagged false so an untagged resource counts as production.
// If your policy.yaml differs, edit the three lines below or this will disagree with your own agent.
| where tolower(tostring(coalesce(tags['cfop:protect'], ''))) !in ('true', 'yes', '1')
| extend cfopEnv = tolower(trim(' ', tostring(coalesce(tags['Environment'], tags['environment'], tags['env'], ''))))
| where cfopEnv in ('dev', 'development', 'test', 'qa', 'sandbox', 'nonprod', 'non-prod', 'staging')
| project name, resourceGroup, location,
size = tostring(sku.name),
capacity = toint(sku.capacity)
| order by capacity descCompare capacity against the Percentage CPU metric across the set. Keep headroom for the observed peak, not the average.
Applies to microsoft.compute/virtualmachinescalesetsWhat the agent does about it
A scale set whose sustained load fits comfortably below its configured minimum or fixed capacity.
It will not fix this one
It reports this and takes no action. A check only earns the right to change something once the action behind it can re-read live state before it fires and knows the way back.
Related checks
Idle virtual machine
A running VM whose CPU and network have been near zero for the whole window.
Oversized virtual machine
A running VM whose sustained peak fits comfortably inside the next size down.
Unattached managed disk
A managed disk attached to nothing, billing its full provisioned size every month.