Skip to main content

AWS Solutions Library

Guidance for Resilient Data Applications Using Amazon DynamoDB

Improve application resiliency to guard against disruptions and outages

Go to sample code

Overview

This Guidance demonstrates how to architect a resilient, multi-Region application using AWS services, such as Amazon DynamoDB global tables. It illustrates best practices for detecting and responding to Region-scoped outages, providing high availability and minimizing downtime for mission-critical applications. This Guidance helps you achieve application resiliency by dynamically routing traffic away from affected Regions and leveraging global data replication.

How it works

Primary

This architecture diagram shows how to set up and build a resilient, multi-Region application. For cross-Region failover and failback, open the other tab.

Download the architecture diagram
Architecture diagram showing a resilient data application using Amazon DynamoDB global tables, AWS Lambda, Amazon API Gateway, Route 53 Application Recovery Controller, and canaries across multiple AWS regions, including us-east-1, us-west-2, and us-east-2 (Observer Region). The diagram illustrates the use of synthetic metrics, regional endpoint metrics, component level metrics, and application recovery controller readiness checks for high availability and disaster recovery.

Cross-Region Failover and Failback

This architecture diagram shows how to perform cross-Region failover and failback in the event of an outage. For setup of the primary Region, open the other tab.

Download the architecture diagram
Architecture diagram illustrating AWS DynamoDB cross-region failover and failback setup. The diagram shows regions us-east-1, us-east-2 (observer), and us-west-2, utilizing Amazon API Gateway, AWS Lambda, and global tables for DynamoDB. It includes canary deployments, Route 53 Application Recovery Controller, Amazon Route 53, and synthetic metrics to support application recovery, endpoint health, and component-level monitoring.

Well-Architected Pillars

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.

Amazon CloudWatch monitors the application's health through metrics from DynamoDB, Lambda, API Gateway, and Route 53. During incidents, metrics help assess user impact for evacuation decisions. CloudWatch Synthetics canaries simulate customer interactions, verifying user experience even without traffic. Canaries complement component metrics by revealing customer-facing issues. CloudWatch dashboards provide a unified view of performance for operations staff. Route 53 ARC checks application readiness. Post-failover, dashboards monitor the failover Region.

Read the Operational Excellence whitepaper 

API Gateway HTTPS endpoints encrypt all communications. AWS Identity and Access Management (IAM) implements the principle of least privilege, granting only the necessary permissions for services to function. DynamoDB encrypts data at rest and in transit, while CloudWatch logs are also encrypted, safeguarding your sensitive information. Adopting these security-focused AWS services mitigates the risk of data breaches and strengthens the overall security posture of your application.

Read the Security whitepaper 

DynamoDB global tables replicate your data across multiple AWS Regions. Automated failover with Route 53 routing and Route 53 ARC helps your application seamlessly continue operating in the event of a disruption. Lambda provides a scalable application layer, decoupling your services from provisioned compute resources. Real-time monitoring with CloudWatch and CloudWatch Synthetics canaries provide the information your team needs to make informed decisions during critical events. These AWS services help you build a robust and highly available application that can withstand unexpected failures.

Read the Reliability whitepaper 

Fully managed, serverless AWS services automatically scale to match your workload. DynamoDB, Lambda, API Gateway, and Route 53 dynamically allocate resources so your application can handle traffic surges and fluctuations without compromising the user experience. CloudWatch monitors your application's metrics, enabling you to identify and address performance bottlenecks. Route 53 automatically distributes traffic to the lowest latency Regions, improving responsiveness for your users.

Read the Performance Efficiency whitepaper 

AWS services automatically scale resources to match your application's needs. Lambda and DynamoDB only charge for the compute and storage resources you consume, eliminating the need for overprovisioning. API Gateway and Lambda work in tandem to launch your application logic only when valid API requests are received, so you pay only for the resources you use.

Read the Cost Optimization whitepaper 

The serverless architecture diagram optimizes resource allocation, reducing the need for provisioned hardware and enabling efficient energy usage. API Gateway and Lambda launch only for valid requests, minimizing compute consumption. DynamoDB allocates storage as needed, preventing waste. Resources scale up during traffic spikes and failovers, then scale down when demand decreases. This automated, precise matching of supply to demand maximizes energy efficiency and reduces energy consumption.

Read the Sustainability whitepaper 

Deploy with confidence

Ready to deploy? Review the sample code on GitHub for detailed deployment instructions to deploy as-is or customize to fit your needs. 

Go to sample code

Related Content

Blog

Build resilient applications with Amazon DynamoDB global tables: Part 4

This blog post discusses the operational concerns for a multi-Region deployment, including observability, deployment pipelines, and runbooks.

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.