An autoscaling group stays its old size under heavy load and never adds instances — diagnose why
Traffic tripled an hour ago and latency is climbing, but the autoscaling group (ASG) never grew past its original 4 instances. Given the state below, find why it does not scale out and what you would change.
ASG: web-asg min=2 desired=4 max=4
Scaling policy: target tracking on AverageCPUUtilization = 70%
Current AverageCPUUtilization: 34% (requests are I/O-bound, waiting on the DB)
Cooldown: 300s last scaling activity: 3 days ago
Instances: 4/4 healthyExplain the root cause(s) and the fix.
Two things block it. First, max equals desired at 4, so the group cannot add instances even if a policy fires — raise max. Second, the policy tracks CPU at 70%, but requests are I/O-bound and CPU sits at 34%, so it never trips; scale on a demand signal like request count or queue depth. Cooldown is not masking activity.
- ✗Missing that max equals desired, leaving no headroom to scale out
- ✗Scaling on CPU when the workload is I/O-bound, so the target never trips
- ✗Assuming desired can exceed max, or that CPU is the only usable metric
- →Which metric would you target for a queue-worker fleet instead of CPU?
- →How do cooldown or warm-up windows prevent scaling from oscillating?
Solution
Cause 1 — capacity ceiling
min=2 desired=4 max=4 ← desired already pinned at maxThe group has nowhere to grow: desired cannot exceed max. Even if a policy wants to add an instance, the max=4 limit forbids it. Raise max (say, to 12).
Cause 2 — the metric misses the bottleneck
The policy tracks AverageCPUUtilization = 70%, but the load is I/O-bound: requests wait on the DB and CPU stays at 34%. The 70% target is never crossed, so the policy stays quiet. Scale on a signal that reflects real demand: request count per instance, p95 latency, or queue depth.
Check
last scaling activity: 3 days ago confirms cooldown is not the culprit — it is not swallowing events; there simply are none. After fixing max and the metric, the group will scale out under load.
