Introduction

Target tracking scaling should react automatically when a metric such as CPU or request count rises above the desired target. When it does not scale out, the issue is usually not that Auto Scaling is broken. It is that one of the prerequisites is wrong: the group already sits at max size, the chosen metric is not reflecting pressure correctly, or warm-up and cooldown settings suppress new scale-out decisions.

Symptoms

  • Load rises, but the Auto Scaling group stays at the same size
  • The target tracking policy is attached and enabled, yet no instances launch
  • Recent scaling activities show cancellations, no-op behavior, or no activity at all
  • CPU, request count, or custom metric data looks inconsistent with real traffic pressure

Common Causes

  • MaxSize already equals the current desired capacity
  • The target tracking metric or statistic does not represent the workload correctly
  • Instance warm-up is too long or misaligned with application startup
  • Missing or delayed CloudWatch metric data prevents the policy from evaluating correctly

Step-by-Step Fix

  1. 1.Check group min, desired, and max capacity first
  2. 2.If the group is already at max size, no target tracking policy can scale it further.
bash
aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names my-asg
  1. 1.Inspect recent scaling activities
  2. 2.Activity history often shows whether scale-out attempts were blocked, cancelled, or never triggered.
bash
aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name my-asg \
  --max-items 10
  1. 1.Verify the CloudWatch metric the policy uses
  2. 2.Target tracking is only as good as the metric feeding it. Missing, delayed, or misleading metrics cause non-obvious scaling failures.
bash
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=AutoScalingGroupName,Value=my-asg \
  --start-time 2026-04-10T07:30:00Z \
  --end-time 2026-04-10T08:30:00Z \
  --period 60 \
  --statistics Average
  1. 1.Tune warm-up and policy settings to match reality
  2. 2.If instances become ready quickly, a long warm-up can delay valid scale-out decisions. If they need more boot time, too-short warm-up can create unstable policy behavior.

Prevention

  • Keep MaxSize comfortably above expected peak load
  • Choose target tracking metrics that actually correlate with pressure
  • Review instance warm-up after application startup or AMI changes
  • Monitor desired capacity, in-service capacity, and target tracking activity together