Which solution will meet these requirements?
Set up DynamoDB Accelerator (DAX) as in-memory cache. Update the application to use DAX. Create an Auto Scaling group for the EC2 instances. Create an Application Load Balancer (ALB). Set the Auto Scaling group as a target for the ALB. Update the Route 53 record to use a simple routing policy that targets the ALB’s DNS alias. Configure scheduled scaling for the EC2 instances before the content updates.
Set up Amazon ElastiCache for Redis. Update the application to use ElastiCache. Create an Auto Scaling group for the EC2 instances. Create an Amazon CloudFront distribution, and set the Auto Scaling group as an origin for the distribution. Update the Route 53 record to use a simple routing policy that targets the CloudFront distribution’s DNS alias. Manually scale up EC2 instances before the content updates.
Set up Amazon ElastiCache for Memcached. Update the application to use ElastiCache Create an Auto Scaling group for the EC2 instances. Create an Application Load Balancer (ALB). Set the Auto Scaling group as a target for the ALB. Update the Route 53 record to use a simple routing policy that targets the ALB’s DNS alias. Configure scheduled scaling for the application before the content updates.
Set up DynamoDB Accelerator (DAX) as in-memory cache. Update the application to use DAX. Create an Auto Scaling group for the EC2 instances. Create an Amazon CloudFront distribution, and set the Auto Scaling group as an origin for the distribution. Update the Route 53 record to use a simple routing policy that targets the CloudFront distribution’s DNS alias. Manually scale up EC2 instances before the content updates.
Explanations:
Setting up DynamoDB Accelerator (DAX) provides an in-memory caching solution that can handle increased read loads during content updates. Creating an Auto Scaling group for the EC2 instances and using an Application Load Balancer (ALB) allows for dynamic scaling and load distribution, enhancing availability. Updating Route 53 to point to the ALB allows for efficient traffic management. Scheduled scaling ensures that resources are increased before peak loads.
While setting up ElastiCache for Redis and creating an Auto Scaling group is beneficial, using CloudFront as the origin for the EC2 instances is unnecessary and does not address the caching issues effectively during content updates. Also, manually scaling up EC2 instances may not adequately prepare for sudden load increases, risking downtime.
Setting up ElastiCache for Memcached is viable but less suitable compared to Redis for caching use cases with complex data types. The suggestion to create an Auto Scaling group and an ALB is good, but using a simple routing policy with Route 53 targeting the ALB does not provide optimized cache management or scaling ahead of updates effectively.
Although DAX and an Auto Scaling group are beneficial, creating a CloudFront distribution with EC2 as an origin does not provide the best caching solution during content updates. Manually scaling EC2 instances is not a proactive solution and does not ensure availability under load, especially compared to the scheduled scaling proposed in option A.
As I see it, the answer is:
Set up DynamoDB Accelerator (DAX) as in-memory cache. Update the application to use DAX. Create an Auto Scaling group for the EC2 instances. Create an Application Load Balancer (ALB). Set the Auto Scaling group as a target for the ALB. Update the Route 53 record to use a simple routing policy that targets the ALB’s DNS alias. Configure scheduled scaling for the EC2 instances before the content updates.