Which steps should the solutions architect take to design an appropriate solution?
Use AWS Elastic Beanstalk to create a new application with a web server environment and an Amazon RDS MySQL Multi-AZ DB instance. The environment should launch a Network Load Balancer (NLB) in front of an Amazon EC2 Auto Scaling group in multiple Availability Zones. Use an Amazon Route 53 alias record to route traffic from the company’s domain to the NLB.
Use AWS CloudFormation to launch a stack containing an Application Load Balancer (ALB) in front of an Amazon EC2 Auto Scaling group spanning three Availability Zones. The stack should launch a Multi-AZ deployment of an Amazon Aurora MySQL DB cluster with a Retain deletion policy. Use an Amazon Route 53 alias record to route traffic from the company’s domain to the ALB.
Use AWS Elastic Beanstalk to create an automatically scaling web server environment that spans two separate Regions with an Application Load Balancer (ALB) in each Region. Create a Multi-AZ deployment of an Amazon Aurora MySQL DB cluster with a cross-Region read replica. Use Amazon Route 53 with a geoproximity routing policy to route traffic between the two Regions.
Use AWS CloudFormation to launch a stack containing an Application Load Balancer (ALB) in front of an Amazon ECS cluster of Spot instances spanning three Availability Zones. The stack should launch an Amazon RDS MySQL DB instance with a Snapshot deletion policy. Use an Amazon Route 53 alias record to route traffic from the company’s domain to the ALB.
Explanations:
AWS Elastic Beanstalk is suitable for deploying .NET applications, but using a Network Load Balancer (NLB) is not ideal for HTTP traffic; Application Load Balancer (ALB) is preferred. Additionally, relying solely on an RDS MySQL Multi-AZ setup does not provide the scalability benefits of Aurora, which is better suited for high traffic.
This option effectively uses AWS CloudFormation for infrastructure as code, creating an ALB for HTTP traffic management and an EC2 Auto Scaling group for handling increased user demand across three Availability Zones. It also incorporates a Multi-AZ Amazon Aurora MySQL DB cluster, which offers better performance and availability than standard MySQL, and the Retain deletion policy ensures data preservation.
While this option emphasizes high availability and disaster recovery by using two separate Regions and a cross-Region read replica, it introduces unnecessary complexity and cost for a transition from an on-premises environment. An application architecture spanning two Regions is typically more suited for specific disaster recovery scenarios rather than standard scaling needs. Additionally, a read replica alone does not suffice for a write-heavy workload.
Using Amazon ECS with Spot instances may lead to potential interruptions, which could impact application availability, especially under high load conditions. Moreover, launching an RDS MySQL instance instead of Aurora limits scalability and performance. While using an ALB is appropriate, the combination of ECS with Spot instances does not align with the need for high availability and scalability for 200,000 daily users.
From my point of view, the answer is:
Use AWS CloudFormation to launch a stack containing an Application Load Balancer (ALB) in front of an Amazon EC2 Auto Scaling group spanning three Availability Zones. The stack should launch a Multi-AZ deployment of an Amazon Aurora MySQL DB cluster with a Retain deletion policy. Use an Amazon Route 53 alias record to route traffic from the company’s domain to the ALB.