DynamoDB Multi-Region and Resilience

Once change-driven workflows like Streams and TTL-based expiration are running inside a single region, the natural next question is what happens when your users, compliance requirements, or disaster-recovery goals span multiple regions. A single-region DynamoDB table, no matter how well designed, cannot deliver low-latency reads to users on another continent or survive a full regional outage without external intervention. DynamoDB global tables solve this by turning a single table into a collection of replica tables distributed across chosen AWS Regions, each capable of accepting both reads and writes. This makes global tables genuinely multi-active rather than a traditional primary-secondary replication model.

The current production version is Global Tables version 2019.11.21, and this is the only version learners should study. Legacy global-table documentation describes a different operational model with manual capacity management and different replication mechanics, so encountering references to the older version should be treated as outdated.

Attention: There is no single global DynamoDB endpoint. Every SDK call, every connection string, and every retry path must reference a specific regional endpoint such as dynamodb.us-east-1.amazonaws.com. Assuming a global endpoint exists is one of the most common misconceptions on exams and in production designs.

Global tables expose two consistency modes that fundamentally shape how replication, latency, availability, and conflict handling behave. The default mode is MREC (multi-region eventual consistency)A replication mode where writes are accepted locally and propagated asynchronously to other replica Regions, typically within one second, with no cross-Region acknowledgment required before confirming the write.. The alternative is MRSC (multi-region strong consistency)A replication mode where a write must be acknowledged across a designated set of Regions before it is confirmed to the client, enabling strongly consistent reads of globally replicated data at the cost of higher write latency.. Choosing between these two modes is not a simple toggle. It is the foundational architectural decision that determines replica planning, latency budgets, conflict behavior, and failover runbooks.

The diagram below illustrates how a global table spans regions, how clients connect through regional endpoints, and where traffic steering fits into the architecture.

The sections ahead walk through replica planning, consistency mode mechanics, conflict resolution, traffic steering, and failover operations.

Replica planning and consistency modes