highIntermediateSymptom-first#autoscaling#asg#scaling#load

Auto Scaling group not scaling out under load

Load climbs but instance count stays flat

Likely source:scalingperformance

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Load climbs but instance count stays flat
  • No scaling activities in the console despite high CPU
  • DesiredCapacity pinned below what the app needs

If you have to set desired-capacity by hand, the automation is broken — treat the manual bump as the emergency stopgap and fix the policy afterwards.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • ASG parameters

    aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names <ASG-NAME> --query 'AutoScalingGroups[0].{Min:MinSize,Max:MaxSize,Desired:DesiredCapacity,Processes:SuspendedProcesses}'

  • Recent scaling activities

    aws autoscaling describe-scaling-activities --auto-scaling-group-name <ASG-NAME> --max-items 10

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • DesiredCapacity == MaxSize
  • Activities show 'terminating' or nothing while max is hit

Confirm before fixing

aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names <ASG-NAME> --query 'AutoScalingGroups[0].{Min:MinSize,Max:MaxSize,Desired:DesiredCapacity}'
READ

Capacity bounds

Fix

aws autoscaling update-auto-scaling-group --auto-scaling-group-name <ASG-NAME> --max-size <NEW-MAX>
CHANGE

Raise the ceiling after confirming resource limits

Expected: max-size updated

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names <ASG-NAME> --query 'AutoScalingGroups[0].{Min:MinSize,Max:MaxSize,Desired:DesiredCapacity,Suspended:SuspendedProcesses}'
READ

Baseline capacity bounds and suspensions

2
aws autoscaling describe-scaling-activities --auto-scaling-group-name <ASG-NAME> --max-items 10
READ

Read the activity trail

3
aws autoscaling update-auto-scaling-group --auto-scaling-group-name <ASG-NAME> --max-size <NEW-MAX>
CHANGE

Raise max when it caps demand

4
aws autoscaling set-desired-capacity --auto-scaling-group-name <ASG-NAME> --desired-capacity <N>
CHANGE

Manual surge to restore capacity immediately

Prevention

  • Use target-tracking policies on a signal that correlates with your bottleneck.
  • Alert on ASG 'MaxSize reached' — it means you are silently out of headroom.
  • Review Min/Desired/Max in every release and load-test the scale-out path.

Related runbooks

Same stack, same failure family — worth a skim.

New ASG instances failing to launch — quotas and AMIcritical

ASG scale-out spins up instances that immediately terminate

AWSProduction3 causes
Open runbook
InsufficientInstanceCapacity — unable to launch or scalehigh

ec2 run-instances returns InsufficientInstanceCapacity

AWSProduction2 causes
Open runbook
Subnet exhausted — no more IP addresses to launchhigh

run-instances fails: There aren't enough IP addresses available in subnet

AWSProductionUSE3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.