This Guidance helps customers design a resilient three-tier web application with a React front end, API/AWS Lambda middle tier, and Amazon Aurora global database back end. The application is deployed across two AWS Regions for automated failover and failback from one Region to another, achieving active and warm standby disaster recovery patterns. Additionally, Amazon CloudWatch supports observability instrumentation for this multi-Region architecture by obtaining insights from application stacks and aggregating them with relevant infrastructure metrics, which can help customers decide when to failover the application to another Region. Amazon Route53 Application Recovery Controller routes traffic between multiple Regions and automates failover through integration with AWS Systems Manager documents.
Architecture Diagram
-
Application Running in Primary Region
-
Cross Region Failover
-
Application Running in Primary Region
-
Click to enlarge
Step 1
The user opens the browser and enters the UI domain name system (DNS) endpoint hosted on Amazon Route 53.
Step 2
The request is routed to the Amazon CloudFront instance. The data plane for CloudFront is globally available.
Step 3
CloudFront delivers static content stored in Amazon Simple Storage Service (Amazon S3) buckets in the primary region (or, if it is not available, the secondary region in failover mode).
Step 4
CloudFront is protected by AWS WAF, which is configured with standard rules to protect against common web exploits.
Step 5
The UI is authenticated by an Amazon Cognito user pool configured in the primary region. Amazon Cognito is a regional service. If there is degradation or an outage in the Amazon Cognito service in the primary region, this may impact application failover.
Step 6
The Route 53 DNS-hosted zone is powered by Route 53 Application Recovery Controller (ARC), which contains an ARC control for the primary and secondary regions. The ARC controls the respective health checks, which power the respective DNS records in a Route 53-hosted zone. Initially, the primary region ARC control is turned on and the secondary region ARC control is turned off.
Step 7
The primary region health check becomes healthy and the secondary region health check becomes unhealthy. Consequently, the Route 53 API DNS endpoint resolves to the API endpoint in the primary region.
Step 8
The API endpoint in the primary region delegates the calls to corresponding AWS Lambda functions running in the primary region.
Step 9
The application uses an Amazon Aurora global database to store application transaction data. Initially, the primary Aurora database cluster is configured as the writer cluster, and the secondary Aurora database cluster is configured as a reader cluster.
The primary Aurora database cluster automatically replicates data to the secondary Aurora database cluster, which enables the application to run from the secondary region (using the data replicated from primary database cluster to secondary database cluster).
Step 1
The user opens the browser and enters the UI domain name system (DNS) endpoint hosted on Amazon Route 53.
Step 2
The request is routed to the Amazon CloudFront instance. The data plane for CloudFront is globally available.
Step 3
CloudFront delivers static content stored in Amazon Simple Storage Service (Amazon S3) buckets in the primary region (or, if it is not available, the secondary region in failover mode).
Step 4
CloudFront is protected by AWS WAF, which is configured with standard rules to protect against common web exploits.
Step 5
The UI is authenticated by an Amazon Cognito user pool configured in the primary region. Amazon Cognito is a regional service. If there is degradation or an outage in the Amazon Cognito service in the primary region, this may impact application failover.
Step 6
The Route 53 DNS-hosted zone is powered by Route 53 Application Recovery Controller (ARC), which contains an ARC control for the primary and secondary regions. The ARC controls the respective health checks, which power the respective DNS records in a Route 53-hosted zone. Initially, the primary region ARC control is turned on and the secondary region ARC control is turned off.
Step 7
The primary region health check becomes healthy and the secondary region health check becomes unhealthy. Consequently, the Route 53 API DNS endpoint resolves to the API endpoint in the primary region.
Step 8
The API endpoint in the primary region delegates the calls to corresponding AWS Lambda functions running in the primary region.
Step 9
The application uses an Amazon Aurora global database to store application transaction data. Initially, the primary Aurora database cluster is configured as the writer cluster, and the secondary Aurora database cluster is configured as a reader cluster.
The primary Aurora database cluster automatically replicates data to the secondary Aurora database cluster, which enables the application to run from the secondary region (using the data replicated from primary database cluster to secondary database cluster).
-
Cross Region Failover
-
Click to enlarge
Step 1
The user clicks the “Failover” button in the UI, which invokes the failover API endpoint hosted on Route 53.
Step 2
The Route 53 DNS-hosted zone routes to the API endpoint in the primary region based on the state of the Route 53 ARC controls.
Step 3
The primary API endpoint is invoked.
Step 4
The primary API endpoint delegates the invocation to the corresponding Lambda function running in the primary region.Step 5
The Lambda function calls the failover runbook, automated as an AWS Systems Manager Document. The runbook automates the three steps involved with the failover process.
Step 6
The runbook first fails over the Aurora global database from the primary to secondary regions, making the database cluster in the secondary region the writer cluster and the database cluster in the primary region the reader cluster.
Step 7
After failover, the Aurora global cluster is configured to automatically replicate data from the database cluster in the secondary region (writer) to the database cluster in the primary region (reader).
Step 8
The runbook updates the database secret in AWS Secrets Manager with the database endpoint of the Aurora database cluster in the secondary region so that Lambda functions use the new database endpoint to interact with the database.
Step 9
The runbook flips the Route 53 ARC controls, turning the ARC control for the primary region off and turning ARC control for the secondary region on. As a result, the secondary region health check becomes healthy and the primary region health check becomes unhealthy. Route 53 API DNS endpoint resolves to the API endpoint in the secondary region. This completes the failover.
The application will be live in the secondary region, routing API traffic to the secondary region. It invokes Lambda functions in the secondary region, which interacts with the Aurora database cluster in the secondary region.
Step 1
The user clicks the “Failover” button in the UI, which invokes the failover API endpoint hosted on Route 53.
Step 2
The Route 53 DNS-hosted zone routes to the API endpoint in the primary region based on the state of the Route 53 ARC controls.
Step 3
The primary API endpoint is invoked.
Step 4
The primary API endpoint delegates the invocation to the corresponding Lambda function running in the primary region.Step 5
The Lambda function calls the failover runbook, automated as an AWS Systems Manager Document. The runbook automates the three steps involved with the failover process.
Step 6
The runbook first fails over the Aurora global database from the primary to secondary regions, making the database cluster in the secondary region the writer cluster and the database cluster in the primary region the reader cluster.
Step 7
After failover, the Aurora global cluster is configured to automatically replicate data from the database cluster in the secondary region (writer) to the database cluster in the primary region (reader).
Step 8
The runbook updates the database secret in AWS Secrets Manager with the database endpoint of the Aurora database cluster in the secondary region so that Lambda functions use the new database endpoint to interact with the database.
Step 9
The runbook flips the Route 53 ARC controls, turning the ARC control for the primary region off and turning ARC control for the secondary region on. As a result, the secondary region health check becomes healthy and the primary region health check becomes unhealthy. Route 53 API DNS endpoint resolves to the API endpoint in the secondary region. This completes the failover.
The application will be live in the secondary region, routing API traffic to the secondary region. It invokes Lambda functions in the secondary region, which interacts with the Aurora database cluster in the secondary region.
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
This Guidance supports operational excellence by making sure that the business can continue to run business services through failover to a secondary region.
-
SecurityRead the Security whitepaper
Use WAF with CloudFront to protect application from common vulnerabilities and use Amazon Cognito to authenticate UI and API access.
-
ReliabilityRead the Reliability whitepaper
Automate failure monitor workload’s key performance indicators (KPIs) and trigger automated failover when a threshold is breached.
-
Cost OptimizationRead the Cost Optimization whitepaper
Use Amazon API Gateway and Lambda to process transactions in order to avoid provisioned compute resources.
-
SustainabilityRead the Sustainability whitepaper
This Guidance is serverless and minimizes your carbon footprint.
Implementation Resources
The sample code is a starting point. It is industry validated, prescriptive but not definitive, and a peek under the hood to help you begin.
Related Content
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.
References to third-party services or organizations in this Guidance do not imply an endorsement, sponsorship, or affiliation between Amazon or AWS and the third party. Guidance from AWS is a technical starting point, and you can customize your integration with third-party services when you deploy the architecture.