How should this application be redesigned to be scalable and allow for automatic failover at the lowest cost?
Use Amazon Route 53 failover routing with geolocation-based routing. Host the website on automatically scaled Amazon EC2 instances behind an Application Load Balancer with an additional Application Load Balancer and EC2 instances for the application layer in each region. Use a Multi-AZ deployment with MySQL as the data layer.
Use Amazon Route 53 round robin routing to distribute the load evenly to several regions with health checks. Host the website on automatically scaled Amazon ECS with AWS Fargate technology containers behind a Network Load Balancer, with an additional Network Load Balancer and Fargate containers for the application layer in each region. Use Amazon Aurora replicas for the data layer.
Use Amazon Route 53 latency-based routing to route to the nearest region with health checks. Host the website in Amazon S3 in each region and use Amazon API Gateway with AWS Lambda for the application layer. Use Amazon DynamoDB global tables as the data layer with Amazon DynamoDB Accelerator (DAX) for caching.
Use Amazon Route 53 geolocation-based routing. Host the website on automatically scaled AWS Fargate containers behind a Network Load Balancer with an additional Network Load Balancer and Fargate containers for the application layer in each region. Use Amazon Aurora Multi-Master for Aurora MySQL as the data layer.
Explanations:
While using Amazon Route 53 failover routing with geolocation-based routing and hosting on EC2 instances can provide some level of scalability, it does not offer the best failover or latency optimization compared to other options. Multi-AZ MySQL deployments also have limitations in terms of performance during high concurrency, making this option less suitable for a dynamic, mission-critical application.
Amazon Route 53 round robin routing is not optimal for latency-sensitive applications, as it does not account for the health or performance of each region. Although hosting the application on ECS with AWS Fargate provides scalability and cost efficiency, using Aurora replicas may introduce additional latency during peak loads and not meet the stringent SLA requirements.
Amazon Route 53 latency-based routing ensures users are directed to the nearest region, reducing latency. Hosting the application in Amazon S3 with API Gateway and AWS Lambda provides excellent scalability and low cost. Using DynamoDB global tables with DAX allows for high throughput and low latency, making this option the best fit for meeting the SLA of 99.99% in a highly concurrent environment.
While Amazon Route 53 geolocation-based routing can be useful for directing traffic, hosting on Fargate containers behind a Network Load Balancer may not provide the same scalability and low latency as using serverless architectures like Lambda. Additionally, Aurora Multi-Master can be complex and may not significantly reduce latency or cost compared to the simpler architecture proposed in option C.
As I recall, the answer is:
Use Amazon Route 53 latency-based routing to route to the nearest region with health checks. Host the website in Amazon S3 in each region and use Amazon API Gateway with AWS Lambda for the application layer. Use Amazon DynamoDB global tables as the data layer with Amazon DynamoDB Accelerator (DAX) for caching.