Auto Scaling groups pinned at MinSize equal to DesiredCapacity, so scaling policies can never scale in
What does ZopNight detect here?
ZopNight flags EC2 Auto Scaling groups where `MinSize` equals `DesiredCapacity` and is above 1, and at least one scaling policy exists. Because desired capacity can never drop below the minimum, the policy cannot scale in. ZopNight prices an off-hours schedule that lowers the minimum from the group's measured idle hours.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-054 |
| Category | schedule |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | MinSize = DesiredCapacity > 1 with a scaling policy |
| Source | ZopNight |
| Permissions used | autoscaling:DescribeAutoScalingGroups · autoscaling:DescribePolicies · autoscaling:DescribeScheduledActions |
Where it applies
A minimum at the desired size disables scale-in
The scaling limits documentation says desired capacity must be equal to or greater than the minimum group size. So if a group’s minimum is 6 and its desired capacity is 6, a target tracking or step policy can add instances when load rises but can never remove any below 6. The group runs its full floor at 3 a.m. on a Sunday, and every instance in it keeps billing.
This usually happens when someone raises the minimum during a launch or incident and forgets it.
Finding pinned groups
aws autoscaling describe-auto-scaling-groups \ --query 'AutoScalingGroups[?MinSize==DesiredCapacity && MinSize>`1`].[AutoScalingGroupName,MinSize,DesiredCapacity,MaxSize]' \ --output table
aws autoscaling describe-policies --auto-scaling-group-name web-asg \ --query 'ScalingPolicies[].[PolicyName,PolicyType]'What makes a group a candidate
- ZopNight’s inventory shows the minimum equal to desired capacity, with a minimum above 1.
- The group has at least one scaling policy. Without one, lowering the minimum changes nothing, because no policy would act on the lower floor.
- ZopNight can read the pinned minimum size so the recommendation can state it.
- A measured off-hours usage pattern exists for the group, with an idle share above zero.
- The group has a known monthly cost.
Groups that get no finding
A group with no scaling policy, an unreadable minimum or no priced cost is skipped. So is one where ZopNight has no measured usage pattern: the rule never assumes a standard nights-and-weekends split. The rule does not suggest deleting instances or the group.
Idle share of the group’s cost
saving = monthly group cost x measured off-hours idle shareThe lever is recurring: the minimum drops for the idle window and returns before the busy one, and the scaling policy does the actual scale-in.
Letting the group scale in off-hours
- Review the suggested start, stop and time zone in the recommendation, and apply it from ZopNight.
- To do it yourself, add two recurring scheduled actions. As the scheduled scaling docs note, a scheduled action can set a new minimum as well as desired capacity:
aws autoscaling put-scheduled-update-group-action --auto-scaling-group-name web-asg \ --scheduled-action-name offhours-floor --recurrence "0 20 * * 1-5" \ --min-size 1 --time-zone "Europe/London"
aws autoscaling put-scheduled-update-group-action --auto-scaling-group-name web-asg \ --scheduled-action-name workday-floor --recurrence "0 7 * * 1-5" \ --min-size 6 --time-zone "Europe/London"- Confirm the scaling policy actually scales in during the first quiet window.