AWS Systems Architect Professional

Amazon DynamoDB Global Tables: Multi-Region Active-Active Design – SAP-C02 Study Guide

Learn how DynamoDB Global Tables provide asynchronous multi-Region replication, active-active reads and writes, and rapid disaster recovery for SAP-C02 scenarios.

AWS Systems Architect ProfessionalAWS Systems Architect ProfessionalUpdated Sep 1, 2026
Study options
WatchComing later
ListenComing later
ReadAvailable
ReviewComing later

Study guide

Technical reference and lesson notes

Purpose of This Lesson

Amazon DynamoDB Global Tables provide a managed, multi-Region database architecture. They allow applications to read from and write to replica tables in multiple AWS Regions while DynamoDB asynchronously replicates changes between Regions.

This capability is especially relevant for:

  • Multi-Region applications that need local database access.
  • Active-active or multi-active architectures.
  • Disaster recovery designs that must be ready to accept writes in a secondary Region.
  • Applications requiring improved availability and reduced cross-Region latency.

Key Concepts

Multi-Region, Multi-Active Replication

A DynamoDB Global Table consists of replica tables in two or more AWS Regions. Each replica contains the same logical set of data, and an application can use any replica for reads and writes.

This is commonly called an active-active or multi-master database design:

  • Multiple Regions are active at the same time.
  • Each Region can serve application traffic.
  • Applications can read from and write to the local Regional replica.
  • Data changes are replicated asynchronously to the other replicas.

Asynchronous Replication

Global Tables use DynamoDB Streams as part of the replication process. A write made in one Region is propagated to the other replica Regions asynchronously rather than committed synchronously across all Regions before the write succeeds.

Consequences include:

  • Local writes avoid the latency of synchronous cross-Region commits.
  • Replicas may be temporarily inconsistent while changes are propagating.
  • Applications must account for eventual convergence between Regions.
  • Cross-Region replication depends on the underlying DynamoDB Global Tables replication mechanism and its operational health.

Regional Application Failover

An application can be designed to use a preferred Regional endpoint and redirect traffic to another Region if the preferred Region becomes unavailable. Because the alternate replica is already receiving replicated data, the application tier can be moved without first restoring a backup or provisioning a new database.

Failover commonly involves:

  1. Detecting a Regional application or infrastructure failure.
  2. Redirecting users or services to the application stack in another Region.
  3. Pointing the application to the DynamoDB replica in that Region.
  4. Continuing reads and writes using the active replica.

Routing may be implemented with services such as Amazon Route 53, AWS Global Accelerator, or application-level endpoint selection, depending on the architecture.

Data Consistency and Conflicts

Replication is asynchronous, so a write in one Region may not be immediately visible in another. Architectures that allow the same item to be updated concurrently in multiple Regions must account for conflict resolution and application semantics.

For exam scenarios, distinguish between:

  • Read locality: serving reads from a nearby replica.
  • Active-active writes: accepting writes in multiple Regions.
  • Strong global consistency: which is not automatically provided by asynchronous multi-Region replication.

Where possible, applications should assign ownership of an item or user to a preferred Region, reducing concurrent cross-Region updates to the same item.

Exam-Relevant Takeaways

  • DynamoDB Global Tables provide multi-Region, multi-active database replication.
  • Applications can read from and write to any configured replica Region.
  • Replication is asynchronous and uses DynamoDB Streams as part of the replication mechanism.
  • Global Tables are a strong fit for applications that need low-latency Regional database access and rapid Regional failover.
  • They support disaster recovery designs in which the secondary Region is already capable of accepting writes.
  • A design requiring synchronous, globally serialized transactions should not select Global Tables solely because they replicate data across Regions.
  • Failover still requires application and traffic-routing design; creating Global Tables does not automatically fail over the entire application stack.

Architecture Decision Guide

RequirementSuitable approachReasoning
Single-Region DynamoDB with Regional resilienceDynamoDB with built-in availability across Availability ZonesGlobal Tables are unnecessary when the requirement is limited to one Region.
Read access near users in multiple RegionsDynamoDB Global TablesEach Region can have a local replica for low-latency access.
Applications actively writing in multiple RegionsDynamoDB Global TablesThe service supports multi-active reads and writes.
Rapid DR with a database already prepared for writesDynamoDB Global TablesThe secondary replica is continuously populated instead of being restored after failure.
Cross-Region replication with possible temporary divergenceDynamoDB Global TablesReplication is asynchronous, so applications must tolerate propagation delay.
Strongly coordinated, synchronous writes across RegionsA different architecture or coordination mechanismGlobal Tables do not turn asynchronous replication into a global synchronous transaction system.
Database replication only, but no application failover planIncomplete solutionTraffic routing, application deployment, configuration, and operational procedures are also required.

Common Exam Traps

  • Confusing multi-Region with multi-active: A database can have copies in multiple Regions without allowing writes in every Region. Global Tables are specifically associated with multi-active access.
  • Assuming replication is synchronous: A successful local write does not imply that every replica has committed the change at the same instant.
  • Assuming automatic application failover: Global Tables replicate data, but the application tier and client traffic still need a failover mechanism.
  • Treating replicas as independent datasets: Replica tables represent the same logical global table and are intended to converge on the same data.
  • Ignoring write conflicts: Concurrent updates to the same item from different Regions require careful data ownership, conflict handling, and application design.
  • Selecting Global Tables for every DR requirement: For a single-Region workload, backups, point-in-time recovery, or another simpler recovery strategy may be more appropriate depending on the recovery objectives.
  • Assuming immediate cross-Region consistency: Applications should not depend on an immediate read in one Region observing a just-completed write in another Region.

Real-World Engineer Notes

  • Keep application traffic and database traffic Regionally aligned when possible. This reduces latency and limits unnecessary cross-Region data access.
  • Use health checks and a deliberate routing strategy for failover. DNS-based routing can be affected by TTL and client caching; other routing options may provide different control and failover characteristics.
  • Test the entire failover path, not just database replication. Include deployment state, secrets, configuration, queues, caches, observability, permissions, and client behavior.
  • Define how the application handles writes during a network partition or replication delay.
  • Consider assigning users, tenants, or entities to a home Region. This reduces simultaneous writes to the same item in multiple Regions.
  • Validate capacity and cost in every replica Region. Multi-Region availability generally means paying for and operating capacity across multiple Regions.
  • Monitor replication health and latency, and document the expected recovery point and recovery time for the application.

Quick Reference Summary

  • Service: Amazon DynamoDB Global Tables
  • Scope: Multiple AWS Regions
  • Access model: Multi-active; reads and writes can occur in each replica Region
  • Replication: Asynchronous, using DynamoDB Streams as part of the replication mechanism
  • Primary benefit: Regional low-latency access and rapid disaster recovery
  • Important limitation: Replicas are not synchronously consistent at all times
  • DR requirement: The application tier, traffic routing, and operational procedures must also support failover
  • Best fit: Globally distributed applications and active-active or warm-ready multi-Region DR architectures

Flashcards

1. What is DynamoDB Global Tables?

A managed multi-Region DynamoDB configuration with replica tables that support reads and writes in multiple AWS Regions.

2. Are DynamoDB Global Tables active-active?

Yes. Each replica Region can actively serve application reads and writes.

3. Is Global Tables replication synchronous?

No. Replication between Regions is asynchronous.

4. What AWS feature is used as part of Global Tables replication?

DynamoDB Streams.

5. What consistency behavior should applications expect between Regions?

Temporary divergence or eventual convergence because changes replicate asynchronously.

6. Why are Global Tables useful for disaster recovery?

A replica Region is continuously populated and can already be configured to accept application writes, reducing recovery work compared with restoring a database after failure.

7. Do Global Tables automatically fail over application traffic?

No. Traffic routing and application failover must be designed separately.

8. What is a key concern with active-active writes?

Concurrent writes to the same item in different Regions can create conflicts or unexpected application outcomes.

9. When might Global Tables be unnecessary?

When the workload is single-Region and only requires DynamoDB’s Regional resilience or a backup-based recovery strategy.

10. What is the difference between multi-Region and multi-active?

Multi-Region means data or services exist in multiple Regions. Multi-active means multiple Regions can actively process requests, including writes where supported.

Practice Questions

Question 1

A company runs a globally distributed application. Users in Europe and North America must read and write customer preferences with low latency. The company also wants the application to continue operating if one AWS Region fails. Which solution best meets these requirements?

A. A single DynamoDB table in one Region accessed through cross-Region application calls

B. DynamoDB Global Tables with replica tables in the required Regions

C. DynamoDB point-in-time recovery restored manually into another Region during an outage

D. An Amazon RDS Multi-AZ deployment in one Region

Correct answer: B

Explanation: DynamoDB Global Tables provide multi-Region replicas that can serve local reads and writes. They are designed for active-active access and Regional failover. The other options either add cross-Region latency, require recovery-time restoration, or do not provide multi-Region operation.

Question 2

An architect selects DynamoDB Global Tables. The application writes an item in the primary user’s Region and immediately reads that item from a replica in another Region. The replica occasionally returns the previous value. What is the most likely explanation?

A. DynamoDB Global Tables use asynchronous replication

B. DynamoDB Global Tables replicate only during scheduled backup windows

C. DynamoDB replica tables are read-only

D. DynamoDB requires all reads to use the primary Region

Correct answer: A

Explanation: Global Tables replicate changes asynchronously. A short propagation interval can cause a remote replica to temporarily return older data.

Question 3

A company has deployed DynamoDB Global Tables in two Regions but has only one application deployment. During a Regional outage, the company cannot serve requests because clients still connect to the failed Region. What should the architect recommend?

A. Enable DynamoDB point-in-time recovery

B. Add a second application deployment and a tested traffic-routing failover mechanism

C. Convert the Global Table to a single-Region table

D. Increase the DynamoDB item size limit

Correct answer: B

Explanation: Global Tables replicate the database but do not automatically deploy or fail over the application tier. The alternate application stack and routing mechanism must be available and tested.

Question 4

An application allows the same customer record to be updated simultaneously by services in two Regions. The architect is concerned about inconsistent outcomes. Which design improvement is most appropriate?

A. Route all updates for a customer to a designated home Region

B. Use larger DynamoDB items

C. Disable DynamoDB Streams

D. Replace Global Tables with a read-only replica

Correct answer: A

Explanation: Assigning ownership of a customer or item to a home Region reduces concurrent cross-Region writes and simplifies conflict handling. Disabling Streams would undermine replication, and item size is unrelated to write conflicts.

Question 5

A workload runs entirely in one Region and needs protection from instance and Availability Zone failures. It has no requirement for multi-Region reads, writes, or Regional disaster recovery. Which statement is most accurate?

A. DynamoDB Global Tables are mandatory for DynamoDB high availability

B. DynamoDB’s single-Region service architecture may be sufficient; Global Tables add multi-Region capabilities that are not required

C. Global Tables provide synchronous transactions across all Regions

D. A Global Table eliminates the need for application backups

Correct answer: B

Explanation: Global Tables are intended for multi-Region use cases. A single-Region DynamoDB deployment already provides Regional high availability, while backups and point-in-time recovery address data protection requirements.