Which solution will meet these requirements with the LEAST operational overhead?
Create an EC2 Spot Fleet. Attach the Spot Fleet to a Network Load Balancer (NLB) in each Region. Create an AWS Global Accelerator IP address that points to the NLB. Create an Amazon Route 53 latency-based routing entry for the Global Accelerator IP address. Save the game metadata to an Amazon RDS for MySQL DB instance in each Region. Set up a read replica in the other Regions.
Create an Auto Scaling group for the EC2 instances Attach the Auto Scaling group to a Network Load Balancer (NLB) in each Region. For each Region, create an Amazon Route 53 entry that uses geoproximity routing and points to the NLB in that Region. Save the game metadata to MySQL databases on EC2 instances in each Region. Set up replication between the database EC2 instances in each Region.
Create an Auto Scaling group for the EC2 instances. Attach the Auto Scaling group to a Network Load Balancer (NLB) in each Region. For each Region, create an Amazon Route 53 entry that uses latency-based routing and points to the NLB in that Region. Save the game metadata to an Amazon DynamoDB global table.
Use EC2 Global View. Deploy the EC2 instances to each Region. Attach the instances to a Network Load Balancer (NLB). Deploy a DNS server on an EC2 instance in each Region. Set up custom logic on each DNS server to redirect the user to the Region that provides the lowest latency. Save the game metadata to an Amazon Aurora global database.
Explanations:
While using Global Accelerator and NLB provides global availability and low latency routing, using Amazon RDS for MySQL across multiple Regions with read replicas introduces higher operational overhead and complexity. RDS doesn’t provide seamless multi-region replication for MySQL in all cases and might not scale efficiently compared to DynamoDB.
This solution uses EC2 instances and a Network Load Balancer (NLB), but setting up MySQL on EC2 instances across multiple Regions with replication increases complexity and management overhead. The geoproximity routing is also less ideal compared to latency-based routing.
This solution uses Auto Scaling, NLB, and latency-based routing through Route 53, which ensures low latency and scalability. The use of Amazon DynamoDB global tables ensures that the game metadata is highly available and automatically replicated across Regions, minimizing operational overhead and complexity.
EC2 Global View and custom DNS logic introduce unnecessary complexity and operational overhead. Deploying DNS servers in each Region and manually handling latency-based routing is more error-prone and difficult to maintain. Additionally, using Aurora global databases requires more management compared to DynamoDB global tables for this use case.
From my point of view, the answer is:
Create an Auto Scaling group for the EC2 instances. Attach the Auto Scaling group to a Network Load Balancer (NLB) in each Region. For each Region, create an Amazon Route 53 entry that uses latency-based routing and points to the NLB in that Region. Save the game metadata to an Amazon DynamoDB global table.