A company processes messages with a worker application running on three EC2 instances in an Auto Scaling group that uses a simple scaling policy. The workers poll messages from an Amazon SQS queue. Sporadic surges in messages are degrading processing performance, and the SysOps administrator must scale the Auto Scaling group to handle higher queue volume. Which approach best satisfies this requirement?

The correct approach is to use CloudWatch metric math to compute the approximate number of visible messages per instance for the SQS queue and create a target-tracking scaling policy based on that. Target tracking policies are ideal for maintaining a specific metric at a desired level. By dividing the ApproximateNumberOfMessagesVisible by the GroupDesiredCapacity (number of instances), you get a per-instance message count. This allows the Auto Scaling group to dynamically adjust its size to ensure each instance handles a consistent workload, effectively addressing sporadic message surges. Using the age of the oldest message (option 1) is less direct for scaling capacity as it indicates a backlog but not the rate of incoming messages. Attaching an Application Load Balancer (options 3 and 4) is unnecessary because the worker application polls messages directly from SQS, not via an ALB. Scheduled scaling (option 4) is not suitable for sporadic, unpredictable surges.