Which set of actions should the team take?
Create RDS MySQL read replicas. Deploy the application to multiple AWS Regions. Use a Route 53 latency-based routing policy to route to the application.
Configure the DB instance as Multi-AZ. Deploy the application to two additional EC2 instances in different Availability Zones behind an ALB.
Replace the DB instance with Amazon DynamoDB global tables. Deploy the application in multiple AWS Regions. Use a Route 53 latency-based routing policy to route to the application.
Replace the DB instance with Amazon Aurora with Aurora Replicas. Deploy the application to multiple smaller EC2 instances across multiple Availability Zones in an Auto Scaling group behind an ALB.
Explanations:
Deploying the application to multiple AWS Regions would increase complexity and operational overhead, especially in managing two regions. The use of Route 53 latency-based routing is more appropriate for geographically distributed apps, but it doesn’t address the single RDS instance’s availability or scalability issues.
While configuring the RDS instance as Multi-AZ improves database availability, the EC2 instances are still not in multiple Availability Zones. This limits the application’s fault tolerance and does not fully optimize for high availability.
Replacing the RDS instance with DynamoDB might be viable for NoSQL use cases, but this would require significant changes to the application, and the application is currently using MySQL. Also, deploying in multiple AWS Regions increases complexity unnecessarily for maximum reliability with minimal overhead.
Replacing the RDS instance with Amazon Aurora and using Aurora Replicas provides higher availability and scalability. Deploying the application on smaller EC2 instances across multiple Availability Zones with Auto Scaling behind an ALB ensures fault tolerance and high availability while minimizing operational overhead.