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:
This option implements DynamoDB Accelerator (DAX) for in-memory caching, which can significantly improve read performance for DynamoDB. It also sets up an Auto Scaling group for EC2 instances and an Application Load Balancer (ALB) to distribute incoming traffic, improving availability and handling increased loads. Scheduled scaling ensures the application scales before content updates, addressing the load issue effectively.
While this option sets up ElastiCache for Redis, which is a good caching solution, it creates a CloudFront distribution instead of an ALB. CloudFront is primarily for caching and delivering content closer to users but may not handle the load balancing of EC2 instances directly. Manual scaling of EC2 instances does not provide the proactive response needed for content updates.
This option proposes using ElastiCache for Memcached, which is suitable for caching but not as widely used as Redis for such applications. It also suggests an ALB and an Auto Scaling group, which is good, but the routing policy to Route 53 is not optimal as it does not include scaling before content updates, making it less effective in addressing high load during those periods.
Although this option also sets up DAX for caching and an Auto Scaling group, it incorrectly proposes using CloudFront as an origin for the EC2 instances. This configuration is not ideal for balancing the load directly among the instances. Additionally, the reliance on manual scaling does not ensure timely responsiveness to the anticipated load increases.
I plot that 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.