Q58 — AWS SAA-C03 Ch.14

Question 58 of 100 | ← Chapter 14

Q1058. A company has a three-tier web application that processes orders from customers. The web tier consists of Amazon EC2 instances behind an Application Load Balancer. The processing tier consists of EC2 instances. The company decoupled the web tier and processing tier by using Amazon Simple Queue Service (Amazon SQS). The storage layer uses Amazon DynamoDB.At peak times, some users report order processing delays and halls. The company has noticed that during these delays, the EC2 instances are running at 100% CPU usage, and the SQS queue fills up. The peak times are variable and unpredictable.The company needs to improve the performance of the application.Which solution will meet these requirements?

• A. 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.
• B. Use Amazon ElastiCache for Redis in front of the DynamoDB backend tier. Use target utilization as a metric to determine when to scale.
• C. Add an Amazon CloudFront distribution to cache the responses for the web tier. Use HTTP latency as a metric to determine when to scale.
• D. 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. ✓

Correct Answer: D. 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.

Explanation

To improve the performance of the application and address the order processing delays and high CPU usage during peak times, the best solution is:D. 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.Explanation:\1. Auto Scaling Target Tracking Policy: - A target tracking scaling policy automatically adjusts the number of EC2 instances in the Auto Scaling group based on real-time metrics. This ensures that the processing tier can scale out when demand increases.\2. Using ApproximateNumberOfMessages: - By using the ApproximateNumberOfMessages attribute from the SQS queue, the Auto Scaling policy can effectively scale out the processing tier whenever the number of messages in the queue exceeds a predefined threshold. This directly addresses the issue of backlog in the SQS queue and helps manage order processing more efficiently.\3. Dynamic Scaling: - Given that peak times are variable and unpredictable, this approach allows for dynamic scaling based on actual workload rather than relying on scheduled scaling, which may not align with real-time demand.Evaluation of Other Options:A. Use scheduled scaling for Amazon EC2 Auto Scaling: - Scheduled scaling is not suitable for unpredictable peak times. It would not respond quickly to sudden spikes in demand, leading to potential delays.B. Use Amazon ElastiCache for Redis: - While caching can improve performance, it does not directly address the CPU utilization of the processing tier or the backlog in the SQS queue. Furthermore, it adds complexity to the architecture without solving the immediate issue.C. Add an Amazon CloudFront distribution: - CloudFront is primarily used for caching static content and reducing latency for web applications. It does not directly address the order processing capacity issues within the processing tier.Conclusion:Option D provides a robust solution to dynamically scale the processing tier based on actual demand, effectively addressing the performance issues during peak times while managing SQS queue backlogs.