DynamoDB Global Tables provide a fully managed, multi-Region, multi-active database solution for globally distributed applications. This chapter covers the architecture, replication mechanism, conflict resolution, and performance characteristics of Global Tables, which are essential for designing resilient, low-latency systems that require data access across multiple AWS Regions. In the SAA-C03 exam, approximately 5-8% of questions touch on DynamoDB topics, with Global Tables appearing in scenarios involving disaster recovery, active-active architectures, and cross-Region data synchronization. Understanding Global Tables is critical for the Resilient Architectures domain (Objective 2.3) and for choosing the correct data replication strategy on exam questions.
Jump to a section
Imagine a team of five engineers in New York, London, Tokyo, Sydney, and São Paulo who must maintain a shared design notebook. Each engineer has a personal copy of the notebook. When any engineer writes a new design or corrects an error, they immediately update their own notebook and simultaneously send a photo of the change to a central office. The central office instantly broadcasts that photo to all other engineers, who paste it into the correct page. If two engineers edit the same page at the exact same moment, the central office uses a timestamp to decide which edit is newer and keeps that one, discarding the older edit. Each engineer can read from their own notebook at any time with zero latency, and writes are acknowledged locally as soon as they finish writing—no need to wait for the photo to reach the others. The notebooks are always eventually identical, usually within a second. This is exactly how DynamoDB Global Tables work: each AWS Region holds a replica table, writes are accepted locally and then propagated asynchronously to all other replicas, with conflict resolution based on last-writer-wins using a timestamp vector.
What Are DynamoDB Global Tables?
DynamoDB Global Tables is a fully managed, multi-Region, multi-master (active-active) database replication service. It allows you to create a single DynamoDB table that is automatically replicated across multiple AWS Regions of your choice. Each Region holds a replica table that can be read from and written to independently. Writes are accepted in any Region and are asynchronously replicated to all other replicas within seconds. This is ideal for globally distributed applications that require low-latency data access for users worldwide and need to survive a Regional outage.
How Global Tables Work Internally
Global Tables use a stream-based replication mechanism built on top of DynamoDB Streams. When you enable DynamoDB Streams on a table, every modification (PutItem, UpdateItem, DeleteItem) generates a stream record containing the changed item's old and new images, along with a sequence number and a timestamp. Global Tables extends this by adding a replication-specific attribute: the aws:rep:deleting and aws:rep:updatetime fields, which are used to track replication status and prevent infinite loops.
The replication process works as follows: 1. A write occurs in Region A. The write is committed locally and a stream record is generated. 2. A replication process in Region A reads the stream record and sends it to a replication queue in a central AWS-managed service (the Global Tables replication infrastructure). 3. The replication infrastructure delivers the write to the replica table in Region B by applying the change via the DynamoDB API. The write in Region B is tagged with special replication metadata to distinguish it from a local write. 4. Region B's stream also generates a record for this replicated write, but the replication process in Region B ignores it (it checks the metadata to avoid re-replicating back to Region A).
This ensures that each write is propagated exactly once to every other replica, with no infinite loops.
Conflict Resolution: Last Writer Wins (LWW)
Because Global Tables is an active-active system, concurrent writes to the same item in different Regions can occur. DynamoDB resolves conflicts using a last-writer-wins (LWW) strategy based on a timestamp vector. Each DynamoDB item in a global table includes a hidden attribute aws:rep:updatetime which stores a timestamp generated by the Region where the write originated. When a conflict is detected (two writes to the same key arrive at a replica within a short window), the write with the most recent timestamp wins. If timestamps are identical (which is extremely rare due to nanosecond precision), the write with the largest Region ID (lexicographically) wins.
This approach is simple and fast but means that data can be lost if two users update the same item nearly simultaneously in different Regions. For applications that need more sophisticated conflict resolution (e.g., merge strategies), you must implement application-level logic, as DynamoDB does not provide custom conflict resolution hooks.
Key Components and Defaults
Replica Regions: You can add up to 25 replica Regions per global table. Each replica must be in a different AWS Region. Adding a replica creates a new table in that Region with the same schema and provisioned capacity (or on-demand mode).
Replication Latency: Typically under one second, but can be higher under heavy load or during Regional network issues. AWS SLA states that replication is 'typically within seconds.'
Consistency: Global Tables offer eventual consistency for replicas. Reads from a replica are eventually consistent by default; strongly consistent reads are only supported for the local Region where the write occurred. If you write to Region A and immediately read from Region B, you might not see the write. For strongly consistent reads across Regions, you must read from the Region where the write happened.
Capacity Management: Each replica can have its own provisioned read/write capacity. You can set different capacity for each Region to match local demand. If using on-demand capacity, each replica is billed independently.
Streams: DynamoDB Streams must be enabled on the table to use Global Tables. Streams are used for replication, but you can also consume the stream for your own purposes (e.g., triggering Lambda functions).
TTL: Time-to-Live (TTL) is supported and works independently per replica. Expired items are deleted in each Region separately, which can lead to temporary inconsistencies if TTL deletes happen at different times.
Configuration and Verification
To create a global table, you first create a regular DynamoDB table in one Region. Then you use the DynamoDB console, CLI, or SDK to add replica Regions. The AWS CLI command to add a replica:
aws dynamodb update-table \
--table-name my-table \
--replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'To verify replication status:
aws dynamodb describe-table --table-name my-tableLook for the Replicas field in the output, which shows the status of each replica (ACTIVE, CREATING, DELETING, UPDATING).
To check replication latency, you can use CloudWatch metrics: ReplicationLatency (the age of the most recent replicated record) and PendingReplicationCount (number of records waiting to be replicated).
Interactions with Related Technologies
AWS Global Accelerator: Not directly related, but can be used to route user traffic to the nearest Region for lower latency reads/writes.
DynamoDB Accelerator (DAX): DAX is a caching layer for a single Region. It does not cache data from other Regions. If you use Global Tables, DAX in each Region caches only the local replica data.
AWS Backup: You can back up a single-Region table or a global table. Backups are taken independently per Region, and you must restore each Region separately.
AWS CloudFormation: You can define a global table using the AWS::DynamoDB::GlobalTable resource type, which manages the entire global table as a single resource, including adding/removing replicas.
AWS Lambda: You can trigger Lambda functions on DynamoDB Streams from any replica. Be aware that replicated writes will also trigger Lambda functions in the destination Region unless you filter them out using the aws:rep:updatetime attribute.
Create base table in primary Region
Begin by creating a standard DynamoDB table in one AWS Region, which will serve as the first replica. You must define the table name, primary key (partition key and optional sort key), and choose capacity mode (provisioned or on-demand). Enable DynamoDB Streams with either 'New image', 'Old image', or 'New and old images' — at least 'New image' is required for Global Tables. The table must not already be a replica of another global table. This initial table becomes the first member of the global table group.
Add replica Regions via console or CLI
Once the base table is active, you add replica Regions. In the DynamoDB console, navigate to the 'Global Tables' tab and click 'Add replica'. Select a Region and optionally configure its provisioned capacity separately. The CLI command `update-table` with `--replica-updates` triggers the creation of a new table in the target Region with identical schema and stream settings. The process is asynchronous; the replica status shows as 'CREATING' until the table is fully provisioned and replication begins.
Replication stream propagation begins
After a replica is added, DynamoDB automatically starts replicating existing data from the source table to the new replica. This initial sync copies all items using a snapshot of the source table. During this phase, writes to the source are still replicated to the new replica via streams, but the initial sync ensures that pre-existing data is copied. The time for initial sync depends on the table size and the capacity allocated. After the initial sync, ongoing changes are replicated via streams with sub-second latency.
Application writes to any replica
Once all replicas are active (status 'ACTIVE'), applications can write to any replica. Each write is committed locally and immediately acknowledged to the client with a successful response. The write is then asynchronously propagated to all other replicas. Because writes are acknowledged locally, write latency is determined by the local Region's DynamoDB performance, not by cross-Region network latency. This is a key advantage for globally distributed applications.
Conflict detection and resolution via LWW
If two writes to the same item key occur in different Regions at nearly the same time, a conflict arises when the second write arrives at a replica that already received the first write. DynamoDB's replication infrastructure detects the conflict by comparing the `aws:rep:updatetime` attribute. The write with the later timestamp wins; the losing write is discarded. The losing write's data is lost — there is no versioning or merge. Applications requiring conflict handling must implement logic to detect and resolve conflicts (e.g., using conditional writes or custom reconciliation).
Enterprise Scenario 1: Global Gaming Leaderboard
A mobile gaming company with millions of users worldwide uses DynamoDB Global Tables to maintain a real-time leaderboard. Players in North America, Europe, and Asia must see their scores updated instantly. The company deploys replicas in us-east-1, eu-west-1, and ap-southeast-1. Each player's device writes scores to the nearest Region, achieving sub-10ms write latency. However, the leaderboard is eventually consistent: a player in Europe may not immediately see a score from a player in Asia. The company accepts this because the leaderboard refreshes every 30 seconds. A common misconfiguration is not setting sufficient write capacity on the replica in ap-southeast-1 during peak hours, causing throttling and increased replication lag. Monitoring PendingReplicationCount helps detect backlogs.
Enterprise Scenario 2: Multi-Region Disaster Recovery for E-Commerce
An e-commerce platform uses DynamoDB Global Tables for its shopping cart and user profile data. The primary Region is us-east-1, with a replica in us-west-2 for disaster recovery. Normally, all writes go to us-east-1. During a Regional outage, the application fails over to us-west-2 and writes there. When us-east-1 recovers, the writes from us-west-2 replicate back. A pitfall: if both Regions are written to during the outage (split-brain scenario), conflicts can occur. For example, a user updates their shipping address in both Regions. The last write wins, potentially losing an address update. To mitigate, the company uses conditional writes with version numbers and a custom reconciliation Lambda that runs on streams to detect and log conflicts.
Enterprise Scenario 3: SaaS Application with Data Residency Requirements
A SaaS provider must keep European user data within the EU. They deploy a DynamoDB global table with replicas in eu-west-1 (Ireland) and eu-central-1 (Frankfurt). They use a write sharding strategy: users are assigned a home Region based on their location, and the application writes only to that Region. Reads can come from any Region. This avoids cross-Region writes for data that must stay local. The company must ensure that replication does not violate data residency: even though data is replicated to the other EU Region, it remains within the EU. They use AWS Organizations and Service Control Policies to prevent adding replicas outside the EU. A common mistake is enabling Global Tables on a table that already contains sensitive data without first verifying that all replica Regions are compliant.
SAA-C03 Exam Focus: DynamoDB Global Tables
The SAA-C03 exam tests Global Tables primarily within the context of designing resilient, multi-Region architectures (Objective 2.3). Expect scenario-based questions where you must choose the correct replication strategy for disaster recovery, low-latency global access, or active-active applications.
Common Wrong Answers and Why Candidates Choose Them
Choosing DynamoDB Cross-Region Replication (CRR) instead of Global Tables: CRR is a feature of DynamoDB Streams + Lambda or Kinesis, but it is not a managed service. Candidates mistakenly think CRR is simpler, but Global Tables is the managed, multi-master solution. The exam expects you to recognize that Global Tables is the correct choice for active-active or automatic multi-Region replication.
Selecting strongly consistent reads across Regions: Strong consistency is only available within the Region where the write occurred. A question might ask for read-your-write consistency globally; the correct answer is to use DynamoDB's global tables with application-level session affinity (e.g., route reads to the write Region) or use DAX with write-through, not strongly consistent reads.
Assuming Global Tables supports custom conflict resolution: Candidates often think you can write custom merge logic. DynamoDB only offers last-writer-wins. If a question asks about handling concurrent updates to the same item from different Regions, the answer is to implement application-level conflict resolution, not to configure DynamoDB.
Mixing up replication latency: Candidates may think Global Tables provides synchronous replication. The exam emphasizes that replication is asynchronous and eventually consistent. Questions about data loss during Regional failure should consider that recent writes may not be replicated.
Specific Numbers and Terms That Appear Verbatim
Up to 25 replica Regions.
Replication latency: 'typically under one second.'
Conflict resolution: 'last writer wins' based on aws:rep:updatetime.
Streams must be enabled with 'New image'.
Each replica can have its own provisioned capacity.
Edge Cases and Exceptions
Adding a replica to an existing table: The table must have streams enabled. If you disable streams on a replica, replication breaks.
Deleting a replica: You can remove a replica, but the data in that Region is deleted permanently.
TTL and Global Tables: TTL deletes are not replicated. Each Region deletes expired items independently, so the same item may be deleted at different times in different Regions.
Backup and restore: When restoring a backup of a global table, you get a single-Region table. You must manually add replicas.
How to Eliminate Wrong Answers
If the question mentions 'active-active' or 'multi-master,' Global Tables is likely correct.
If the question mentions 'strongly consistent reads across Regions,' eliminate that option — not possible.
If the question mentions 'custom conflict resolution,' eliminate Global Tables unless the answer includes application-level logic.
If the question mentions 'synchronous replication,' eliminate Global Tables — it is asynchronous.
Look for keywords: 'globally distributed users,' 'low-latency writes,' 'disaster recovery across Regions.'
Global Tables provide multi-Region, multi-master replication with asynchronous propagation.
Writes are accepted locally and replicated to all replicas within seconds.
Conflict resolution uses last-writer-wins based on a timestamp vector.
Each replica can have independent provisioned capacity and on-demand mode.
DynamoDB Streams must be enabled on the table with 'New image'.
Strongly consistent reads are only supported in the Region where the write occurred.
Global Tables support up to 25 replica Regions.
TTL deletes are not replicated; each Region handles TTL independently.
These come up on the exam all the time. Here's how to tell them apart.
DynamoDB Global Tables
Multi-Region, multi-master active-active replication.
Asynchronous replication with sub-second latency.
Supports up to 25 replicas.
Conflict resolution: last-writer-wins (LWW).
Best for NoSQL workloads with simple key-value access.
Aurora Global Database
Multi-Region, single-master (primary-writer) with up to 5 read replicas.
Asynchronous replication with typical latency under 1 second.
Supports only one primary Region for writes.
No conflict resolution needed (single writer).
Best for relational workloads requiring ACID transactions.
Mistake
Global Tables provide strongly consistent reads across all Regions.
Correct
Global Tables only offer eventual consistency for reads from replicas. Strongly consistent reads are only supported for the local Region where the write occurred. To achieve read-your-write consistency globally, you must read from the Region that processed the write.
Mistake
Global Tables replicate data synchronously, so no data loss occurs during a Regional failure.
Correct
Replication is asynchronous. Writes are acknowledged locally before being propagated. If a Region fails before replication completes, recent writes may be lost. The typical replication latency is under one second, but it is not guaranteed.
Mistake
You can have custom conflict resolution logic in Global Tables.
Correct
DynamoDB Global Tables use a fixed last-writer-wins (LWW) strategy based on timestamps. There is no way to plug in custom conflict resolution. Applications must implement their own logic (e.g., using conditional writes or separate conflict tables).
Mistake
Global Tables automatically scale capacity across all replicas uniformly.
Correct
Each replica has its own provisioned capacity settings (read and write capacity units) or can use on-demand mode independently. You must configure capacity per Region based on local traffic patterns.
Mistake
You can use Global Tables with tables that have secondary indexes.
Correct
Yes, Global Tables support local secondary indexes (LSIs) and global secondary indexes (GSIs). However, LSIs must be defined when the table is created and cannot be added later. GSIs can be added after creation, but the replica must be in ACTIVE state before adding a GSI to it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
DynamoDB Global Tables is a fully managed service that automatically replicates data across Regions with conflict resolution. Cross-Region replication using Lambda requires you to write custom code to consume DynamoDB Streams, write to another Region's table, and handle conflicts yourself. Global Tables is simpler, more reliable, and recommended for most use cases. Lambda-based replication gives you more control but adds operational overhead.
Yes, each replica can be configured independently with on-demand capacity mode. On-demand automatically scales to handle traffic spikes. However, you pay per request per Region, so costs can be higher than provisioned capacity for predictable workloads.
DynamoDB automatically resolves conflicts using last-writer-wins. If you need custom conflict resolution, you must implement it at the application level. One approach is to use conditional writes with version numbers and a separate 'conflict' table to log conflicts, then run a reconciliation process.
Disabling streams breaks replication. Writes to that replica will not be propagated to other replicas, and changes from other replicas will not be applied to that replica. The table will become out of sync. You must re-enable streams to restore replication.
Yes. When you add a new replica, DynamoDB performs an initial sync that copies all existing data from one of the existing replicas to the new one. During this sync, ongoing writes continue and are replicated via streams. The new replica becomes fully active after the initial sync completes.
DynamoDB transactions (transactGetItems, transactWriteItems) are supported within a single Region. However, transactions are not atomic across Regions in a global table. A transaction in one Region may succeed, but the individual writes within that transaction are replicated as separate stream records. If a conflict occurs on one of those writes in another Region, it could be overwritten by a concurrent write.
Use CloudWatch metrics: `ReplicationLatency` (age of the most recent replicated record in milliseconds) and `PendingReplicationCount` (number of records waiting to be replicated). Set alarms to detect high latency or backlogs.
You've just covered DynamoDB Global Tables — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?