DynamoDB Global Tables

A global table is a DynamoDB table that copies itself across several AWS Regions. Each Region holds a full replica, and every replica accepts both reads and writes. Users in Mumbai, Virginia, and Frankfurt connect to the nearest Region and enjoy fast responses.

The Bank Branch Picture

A bank has branches in three cities. A customer deposits money at any branch, and the other branches update their records within moments. No customer has to travel to a central office. Global tables give your data the same reach. Each Region acts as a branch, and DynamoDB handles the synchronization.

Diagram: Multi-Region Replication

        ┌────────────────────┐
        │  Mumbai replica    │◄──┐
        └────────────────────┘   │
                 ▲ ▼             │
        ┌────────────────────┐   │  Two-way
        │  Virginia replica  │◄──┤  replication
        └────────────────────┘   │
                 ▲ ▼             │
        ┌────────────────────┐   │
        │  Frankfurt replica │◄──┘
        └────────────────────┘

A write in any Region appears in all others, usually within a second.

Why Teams Use Global Tables

• Low latency worldwide: Users read and write in a nearby Region.
• Disaster recovery: Another Region keeps serving traffic when one Region becomes unavailable.
• Multi-Region applications: Application stacks in several Regions share one logical table.

How Replication Works

DynamoDB Streams powers replication behind the scenes. A write lands in the local replica first. DynamoDB sends the change to every other replica. Each replica applies the change to its own copy.

Replication usually completes within about a second, although AWS gives no fixed guarantee. The CloudWatch metric ReplicationLatency tracks the delay.

Conflict Resolution

Two users can update the same item in two Regions at nearly the same moment. DynamoDB settles the conflict with a last writer wins rule. The update with the latest timestamp stays, and the earlier update disappears.

12:00:00.100  Mumbai writes     Status = "PAID"
12:00:00.250  Virginia writes   Status = "CANCELLED"

Result in every Region: Status = "CANCELLED"  (latest timestamp wins)

Design applications to avoid concurrent writes to the same item from different Regions. A common approach assigns each item a home Region that handles its writes.

Read Consistency Across Regions

• Eventually consistent reads see changes from other Regions after replication completes.
• Strongly consistent reads return the latest data written in the same Region only.

DynamoDB also offers a multi-Region strong consistency option for global tables in supported setups. Check the current AWS documentation for the Regions and rules that apply.

Setting Up a Global Table

Step 1: Start with a Table

Create a regular table or use an existing one. Streams turn on automatically for replication.

Step 2: Add a Replica Region

Open the Global Tables tab in the console and choose Add Replica. Select a Region. DynamoDB creates the table in that Region and copies existing data.

Step 3: Repeat for Every Region

Add each additional Region the same way. Every replica uses the same table name and key schema.

aws dynamodb update-table \
  --table-name Orders \
  --replica-updates '[{"Create": {"RegionName": "eu-central-1"}}]'

Capacity and Billing

Each replica needs write capacity for its own writes plus the writes replicated from other Regions. In on-demand mode, DynamoDB scales automatically. In provisioned mode, enable auto scaling on every replica. Replicated writes carry a charge in each destination Region, and data transfer between Regions adds to the bill.

Planning Tips

• Choose Regions close to your users.
• Keep the capacity mode and auto scaling settings consistent across replicas.
• Avoid designs where two Regions write to the same item at the same time.
• Monitor ReplicationLatency with an alarm.
• Test a Regional failover before you need one.

Summary

• A global table replicates one table across multiple Regions with two-way sync.
• Every replica accepts reads and writes.
• Last writer wins settles conflicting updates.
• Strongly consistent reads apply within a single Region.
• Capacity and data transfer costs rise with each added Region.