A company runs a three-tier web application that processes customer orders. The web tier uses Amazon EC2 instances behind an Application Load Balancer. The processing tier uses EC2 instances. The company decoupled the web and processing tiers using Amazon Simple Queue Service (Amazon SQS). The storage layer is Amazon DynamoDB. During peak times some users report order processing delays. During these delays, the EC2 instances are at 100% CPU and the SQS queue backs up. Peaks are variable and unpredictable. The company needs to improve application performance. Which solution meets these requirements?

The correct solution is to use an Amazon EC2 Auto Scaling target tracking policy to scale out the processing tier instances, using the ApproximateNumberOfMessages attribute to determine when to scale. This directly addresses the bottleneck: the SQS queue backing up and the processing tier instances being at 100% CPU. By scaling based on the number of messages in the queue, Auto Scaling can proactively add more processing instances when demand increases, ensuring messages are processed promptly. ApproximateNumberOfMessages is a direct indicator of pending work. Scheduled scaling for Auto Scaling is not ideal because peak times are variable and unpredictable, making fixed schedules ineffective. Amazon ElastiCache for Redis would improve DynamoDB read performance but doesn't address the SQS queue backup or CPU bottleneck in the processing tier. Amazon CloudFront caches web content, which might reduce load on the web tier but won't solve the processing tier's inability to keep up with SQS messages.