Which solution will meet these requirements?
Use scheduled scaling for Amazon EC2 Auto Scaling to scale out the processing tier instances for the duration of peak usage times. Use the CPU Utilization metric to determine when to scale.
Use Amazon ElastiCache for Redis in front of the DynamoDB backend tier. Use target utilization as a metric to determine when to scale.
Add an Amazon CloudFront distribution to cache the responses for the web tier. Use HTTP latency as a metric to determine when to scale.
Use an Amazon EC2 Auto Scaling target tracking policy to scale out the processing tier instances. Use the ApproximateNumberOfMessages attribute to determine when to scale.
Explanations:
Scheduled scaling is not ideal for unpredictable peak times, as it lacks the flexibility to respond to sudden spikes in demand. Using CPU Utilization as a sole metric may not reflect the real-time demand on the queue, leading to delays in scaling out instances.
While adding Amazon ElastiCache can improve read performance for DynamoDB, it does not directly address the issue of high CPU usage and SQS queue filling up. Additionally, scaling based on target utilization for caching may not effectively manage unpredictable load on the processing tier.
Implementing CloudFront would help cache responses for the web tier but does not address the underlying processing tier bottlenecks. HTTP latency is not a suitable metric for scaling the processing tier, as it focuses on web response times rather than processing delays caused by high CPU usage.
Using an Amazon EC2 Auto Scaling target tracking policy with the ApproximateNumberOfMessages attribute directly addresses the scaling needs of the processing tier based on the number of messages in the SQS queue. This allows for dynamic scaling in response to the queue length, helping to alleviate CPU strain and reduce processing delays effectively during unpredictable peak times.
I design that the answer is:
Use an Amazon EC2 Auto Scaling target tracking policy to scale out the processing tier instances. Use the ApproximateNumberOfMessages attribute to determine when to scale.