Over-Provisioned Auto Scaling Group
CostLens flags EC2 Auto Scaling groups running more instances than their load needs — low aggregate CPU on most days with desired capacity above one.
An Auto Scaling group that keeps several instances running while aggregate CPU stays very low is paying per instance-hour for capacity nobody uses. CostLens flags groups that idled on most days of the lookback window and could likely run leaner.
How it works
CostLens lists Auto Scaling groups
Calls autoscaling:DescribeAutoScalingGroups. Groups with zero instances or desired capacity of 1 are skipped.
Aggregates group CPU
Queries CloudWatch CPUUtilization for the group (by AutoScalingGroupName) as a daily average over 14 days.
Flags persistent over-provisioning
Flags groups whose mean CPU was under 10% on ≥10 of 14 days with desired capacity above 1.
Estimates savings
Conservatively assumes the group could drop to one instance: (desired − 1) × instance hourly price × 730 hours. Severity scales with the estimate.
What to do
- Open the recommendation to see the desired capacity, instance type, and idle-day count.
- Decide whether the headroom is intentional (burst traffic, availability) — this check is advisory.
- If safe, lower the group's desired and minimum capacity, or tune the scaling policy, in the AWS console.
Headroom may be intentional
Auto Scaling groups are often sized for burst or multi-AZ availability. Review the scaling policy and traffic pattern before reducing capacity.
Severity levels
| Severity | Estimated monthly savings |
|---|---|
| critical | >$500 |
| high | $100–$500 |
| medium | $20–$100 |
| low | <$20 |
Required IAM permissions
Read-only — covered by the CostLens ReadOnlyAccess policy from AWS Accounts:
autoscaling:DescribeAutoScalingGroups
cloudwatch:GetMetricStatistics
Limitations
- Advisory only — CostLens does not change Auto Scaling capacity automatically.
- Savings assume a reduction to one instance; the right target depends on your availability and burst requirements.