Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 37 discussion

Agree with B. Not A: we will not use NLB for web app Not C: Beanstalk is region service. It CANNOT "automatically scaling web server environment that spans two separate Regions" Not D: spot instances cant meet 'highly available'

B is correct. The solution architect should 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. This solution provides scalability and high availability for the web application by using an Application Load Balancer and an Auto Scaling group in multiple availability zones, which can automatically scale in and out based on traffic demand. The use of a Multi-AZ Amazon Aurora MySQL DB cluster provides high availability for the database layer and the Retain deletion policy ensures the data is retained even if the DB instance is deleted. Additionally, the use of Route 53 with an alias record ensures traffic is routed to the correct location.

B. 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.

B, for sure. Elastic Beanstalk is region specific. The "Retain" deletion policy in AWS Aurora ensures that when you delete a database cluster, the automated backups and snapshots of the cluster are retained. This means that even though the database cluster itself is deleted, the backups and snapshots remain, allowing you to restore the cluster from those backups at a later time.

B, for sure. Elastic Beanstalk environments are typically created within a single AWS region.

Option C: The only AWS documentation I found that support .NET application migration is for Elastic Beanstalk, it said " EB is the fastest and simplest way to deploy .NET applications on AWS" Many suggestion is selection option "B", the question is not asking about cost or least operational overhead, just scalable and highly available for the migration for a .NET application. Also, I can see why so many people are selecting option "B". https://docs.aws.amazon.com/whitepapers/latest/develop-deploy-dotnet-apps-on-aws/aws-elastic-beanstalk.html https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts.concepts.design.html

B however is not a highly available solution IMO because it is restricted to a region. By any chance if the region goes down, the webapp goes down as well. A is out of the picture because it involves an NLB. D is out of the picture because it involves spot instances which is not the choice for HA requirements. C, everything is good except the mention of "Elastic Beanstalk environment that spans across regions". This is wrong. EB environments are a region construct. You can's have them spanning cross region. You can however have EB in multiple regions.

Guessing the question designer prefers B. But it is wrong. When talking about R53 Alias record, it is wrong. Cause Alias record points to IP address while ALB endpoint is not an IP address. A has flaw. The question says 3-tier web application. AWS question designers often mess up the definition of 3-tier application, which means there isn’t a very clear definition of 3 tier: browser/application server/database is one definition, another one is WebServer/Application Server/database. Looks like A means the latter. Then, if the Elastic Beanstalk is hosting a web server, what are the ASG hosting? And why the R53 is pointing to the NLB which is pointing to the ASG? C is wrong, cause Elastic Beanstalk cannot span regions. D is wrong because spot instance is not HA. Weighting the flaws of different answers, B has the least flaw.

Not C as we do not need to span multiple Region (DR, global reach, ...), also cross-Region read replica does not fail-over automatically (you need to promote it to primary). Finally from the wording it seems that this imply having a single environment that spans two separate Regions which is not supported (you need two separate environments) Not D as we have a single RDS DB instance, no HA Both A and B does the job, but B provides better scalability as it make use of Aurora Multi-AZ that allows secondary (reader) instance(s) to be accessed for reads, while RDS Multi-AZ instance does not allow standby instance endpoint to be accessed. This could be circumvented by using Multi-AZ DB cluster deployment that provides 2 readable standby instance

Answer is C The best way to migrate a .NET application to AWS is via Beanstalk (see: https://docs.aws.amazon.com/whitepapers/latest/develop-deploy-dotnet-apps-on-aws/aws-elastic-beanstalk.html) I think that the question regarding spanning a deployment across two regions has triggered some to reject based on the multi-region but if you continue you will notice the separate regional deployments based on two ALBs etc. Just my two pennie :)

B is the correct,

Answer B

B is good

Here's why Option B is the best choice: High Availability: The use of an Application Load Balancer (ALB) and Amazon Aurora Multi-AZ deployment ensures high availability and fault tolerance for the web application and the MySQL database. The Multi-AZ setup for Aurora provides automatic failover. Scalability: Using an EC2 Auto Scaling group across multiple Availability Zones allows the application to automatically scale to meet traffic demands. This is crucial for handling the surge in traffic from 200,000 daily users. Deletion Policy: The Retain deletion policy for the Aurora MySQL DB cluster ensures that even if the CloudFormation stack is deleted, the database is retained, which is important for data preservation and recovery. Route 53 Routing: Route 53 with an alias record provides efficient DNS routing, directing traffic to the ALB, which then distributes it to the EC2 instances. This ensures that users can access the application reliably.

The question required to “design a scalable and highly available solution”. Cause the different between Beanstalk and CloudFormation is, Beanstalk is PaaS (platform as a service) while CloudFormation is IaC (infrastructure as code). So I go for Answer B, as it is related to infrastructure.

"web server environment" doesn't require a single instance to spawns multiple regions, multiple AWS Beanstalks for each region are also feasible. With geoproximity routing it is guaranteed the requests are routed to the same region. In addition the requirement is "highly available", which can be achieve with a multi region architecture

A. I do not quite understand the choice of NLB for this, but Multi-AZ DB instance, EC2 auto-scaling in multiple AZ sure sounds good. C. Elastic Beanstalk does not "span multiple regions". Geoproximity routing does not sound right for a disaster recovery scenario. B. I like CloudFormation, and I like the Retain deletion policy. In order to switch to the other region, one will need to update the Route 53 alias... D. I do not like the Snapshot deletion policy... The DB is not Multi-AZ, nor has a read-replica in the fail-over region. Spot instance is not great for HA.