Global and Cross-Region Design
Explore the principles of designing global and cross-region Amazon DocumentDB clusters to improve availability and reduce read latency. Learn how to configure primary and secondary regions, manage replication lag, and handle failover scenarios. This lesson helps you implement a resilient multi-region document database architecture that supports geographically distributed applications and disaster recovery strategies.
Once data flows are established within a single AWS Region through change streams and event-driven patterns, the next architectural question becomes unavoidable: How do you extend availability and read performance when your users, applications, and compliance requirements span multiple continents? A single-region Amazon DocumentDB cluster, no matter how many read replicas it contains, cannot survive a full AWS Region outage or serve low-latency reads to users thousands of kilometers away. The AWS-native answer for multi-region document database needs is a
A global cluster follows a strict architecture. One region holds the primary cluster, which is the only cluster that accepts write operations. Up to 10 additional regions each hold a secondary cluster that serves read traffic from locally replicated data. This is fundamentally different from a single-region cluster that relies solely on local replicas within one set of Availability Zones.
Two motivations drive this design. The first is low-latency local reads for geographically distributed applications, where a user in Frankfurt reads from a European secondary rather than crossing the Atlantic to a US-based primary. The second is disaster recovery, because if the primary region becomes entirely unavailable, a secondary region can be promoted to take over the write role.
Attention: DocumentDB global clusters are frequently confused with Aurora Global Database and DynamoDB global tables. Aurora Global Database uses a similar read-local, write-primary model, but it applies to...