A company uses an Amazon Simple Queue Service (Amazon SQS) queue and Amazon EC2 instances in an Auto Scaling group with target tracking for a web application. The company collects the…

A custom CloudWatch metric based on SQS alone (without per-instance normalization via metric math) does not account for the current number of running instances, making it an inaccurate signal for target tracking scaling decisions.

CloudWatch metric math can compute the SQS backlog per instance by dividing the ApproximateNumberOfMessagesVisible metric by the number of running instances, creating a dynamic target tracking metric that scales EC2 capacity proportionally to queue depth. This approach is the AWS-recommended pattern for SQS-based autoscaling, ensuring instances scale fast enough to drain the queue during peak periods. By targeting a specific backlog-per-instance value, the Auto Scaling group responds directly to message accumulation rather than an unrelated network metric.

Step scaling with ChangeInCapacity adds a fixed number of instances at defined thresholds, which is less precise and reactive than a target tracking policy driven by the actual per-instance queue backlog metric.

Simple scaling requires a cooldown period after each scaling action before evaluating further alarms, making it too slow to respond to rapidly accumulating SQS messages during peak traffic compared to target tracking with metric math.