Auto Scaling Groups pinned so MinSize blocks every scale-in
What does ZopNight detect here?
An Auto Scaling Group whose MinSize equals its DesiredCapacity, both above 1, can never shed capacity. The floor blocks every scale-in. ZopNight flags these only when a scaling policy exists and a measured idle window backs a schedule, pricing the saving as monthly cost times the measured idle fraction.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-054 |
| Category | schedule |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | asg_floor.go |
Where it applies
Why a floor lock wastes money quietly
When MinSize and DesiredCapacity are set to the same number (say both at 4), the group’s scale-in policy has nowhere to go. Demand drops at night, the policy tries to remove an instance, and the floor refuses. The group holds peak capacity 24/7 while looking, on a dashboard, like autoscaling is working. Nothing errors. Every pinned instance keeps billing at its full on-demand hourly rate, so the bill just never goes down.
The usual origin is a load test or an incident: someone raises MinSize to force capacity, the incident ends, and the setting stays.
The four gates, in order
- The group is floor-locked: MinSize equals DesiredCapacity and both are greater than 1.
- The group has at least one scaling policy. Lowering MinSize on a group with zero policies is inert: nothing would scale it in anyway, so that case abstains (it belongs to a different rule).
- A real monthly cost figure exists for the group. No price, no finding.
- The usage heatmap shows a measured off-hours idle fraction greater than zero.
Miss any gate and the rule says nothing.
Check a group yourself
aws autoscaling describe-auto-scaling-groups \ --query 'AutoScalingGroups[?MinSize==DesiredCapacity && MinSize>`1`].[AutoScalingGroupName,MinSize,DesiredCapacity]' \ --output tableThen confirm each listed group actually has a scale-in policy:
aws autoscaling describe-policies \ --auto-scaling-group-name my-asg \ --query 'ScalingPolicies[].[PolicyName,PolicyType]'What the number means
The saving is monthly cost multiplied by the measured idle percentage from the heatmap, the fraction of the week the group demonstrably sits idle. It is never a flat assumed percentage. The lever is a recurring schedule that lowers MinSize during that window so the existing policy can scale in, then restores it before demand returns. It is not a stop, and not a deletion. The group keeps serving through the whole cycle.
Where it deliberately stays silent
- Groups with no scaling policies, where lowering the floor changes nothing.
- Groups without pricing data, since the rule never reports an unpriced saving.
- Groups with no measured idle window. A floor-locked group that is busy around the clock is correctly pinned, and flagging it would be noise.