Which design should the solutions architect use?
Use AWS CloudFormation StackSets to create the stacks in both Regions with Auto Scaling groups for the web and application tiers. Asynchronously replicate static content between Regions using Amazon S3 cross-Region replication. Use an Amazon Route 53 DNS failover routing policy to direct users to the secondary site in us-west-1 in the event of an outage. Use Amazon DynamoDB global tables for the database tier.
Use AWS CloudFormation StackSets to create the stacks in both Regions with Auto Scaling groups for the web and application tiers. Asynchronously replicate static content between Regions using Amazon S3 cross-Region replication. Use an Amazon Route 53 DNS failover routing policy to direct users to the secondary site in us-west-1 in the event of an outage Deploy an Amazon Aurora global database for the database tier.
Use AWS Service Catalog to deploy the web and application servers in both Regions Asynchronously replicate static content between the two Regions using Amazon S3 cross-Region replication. Use Amazon Route 53 health checks to identify a primary Region failure and update the public DNS entry listing to the secondary Region in the event of an outage. Use Amazon RDS for MySQL with cross-Region replication for the database tier.
Use AWS CloudFormation StackSets to create the stacks in both Regions using Auto Scaling groups for the web and application tiers. Asynchronously replicate static content between Regions using Amazon S3 cross-Region replication. Use Amazon CloudFront with static files in Amazon S3, and multi-Region origins for the front-end web tier. Use Amazon DynamoDB tables in each Region with scheduled backups to Amazon S3.
Explanations:
This option utilizes AWS CloudFormation StackSets for creating stacks in both Regions, ensuring consistent infrastructure. Auto Scaling groups will manage the web and application tiers for high availability. Asynchronous replication of static content via Amazon S3 cross-Region replication allows for disaster recovery. Route 53 DNS failover routing effectively directs traffic to the secondary site during an outage. Using Amazon DynamoDB global tables supports low-latency reads and writes in both Regions, meeting the requirement for minimal failover time and automatic failback.
While this option also uses AWS CloudFormation StackSets and Route 53 for DNS failover, it proposes an Amazon Aurora global database. Aurora is primarily relational and may not be ideal for a NoSQL database design. Additionally, the failover and failback mechanisms may not meet the same low latency and automatic restoration criteria required by the company.
This option uses AWS Service Catalog and Amazon Route 53 health checks for failover, but it relies on Amazon RDS for MySQL, which is a relational database rather than a NoSQL solution. The failover mechanism described may not provide the automatic failback feature requested by the company, and RDS’s cross-Region replication introduces complexity and latency that could hinder recovery time.
Although this option correctly suggests using AWS CloudFormation StackSets and S3 for static content replication, it employs Amazon CloudFront for front-end content delivery and DynamoDB tables with scheduled backups instead of global tables. Scheduled backups do not facilitate real-time failover and could lead to data loss during an outage, and DynamoDB’s scheduled backups do not meet the criteria for immediate disaster recovery and automatic failback.
From my perspective, the answer is:
Use AWS CloudFormation StackSets to create the stacks in both Regions with Auto Scaling groups for the web and application tiers. Asynchronously replicate static content between Regions using Amazon S3 cross-Region replication. Use an Amazon Route 53 DNS failover routing policy to direct users to the secondary site in us-west-1 in the event of an outage. Use Amazon DynamoDB global tables for the database tier.