DynamoDB Global Tables: Multi-Region Active-Active Database

Key Takeaway

DynamoDB Global Tables provide Active-Active replication across multiple AWS regions, allowing reads and writes from any region. It offers 99.999% SLA, higher than single-region's 99.99%, and guarantees low-latency access for global users.

---

1. What are Global Tables?

Concept

DynamoDB Global Tables is a fully managed solution that automatically creates and synchronizes table replicas across selected AWS regions.

┌─────────────────────────────────────────────────────────┐
│           DynamoDB Global Tables Architecture            │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   Seoul Region       Tokyo Region       Virginia Region │
│   ┌──────────┐      ┌──────────┐      ┌────────┐       │
│   │ Replica  │ ◀───▶│ Replica  │ ◀───▶│Replica │       │
│   │ (Active) │Bidir.│ (Active) │Bidir.│(Active)│       │
│   └────┬─────┘ Repl └────┬─────┘ Repl └───┬────┘       │
│        │                 │                │            │
│        ▼                 ▼                ▼            │
│   Korea Users       Japan Users       US Users         │
│   (Local R/W)       (Local R/W)      (Local R/W)       │
│                                                         │
│   Feature: All replicas are Active (read + write)      │
└─────────────────────────────────────────────────────────┘

Key Features

Feature	Description
Active-Active	Read/write possible in all regions
Auto Replication	Automatic data sync between regions
Fully Managed	No replication infrastructure management
Consistency	Eventual Consistency
SLA	99.999% availability

---

2. Why Use Global Tables?

Single Region vs Global Tables

Feature	Single Region	Global Tables
Availability SLA	99.99%	99.999%
Disaster Recovery	Manual backup/restore	Auto replication, instant failover
Latency	High for remote users	Low with local region access
Writable Regions	1	All replica regions

Use Cases

┌─────────────────────────────────────────────────────────┐
│              Global Tables Use Cases                     │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  1️⃣ Global Gaming Services                              │
│     - Low-latency game data for worldwide players       │
│     - Save/load game state from any region              │
│                                                         │
│  2️⃣ Global E-commerce                                   │
│     - Product catalogs, shopping cart data              │
│     - Regional inventory management                     │
│                                                         │
│  3️⃣ Financial Services                                  │
│     - Real-time transaction data                        │
│     - Instant failover on region failure                │
│                                                         │
│  4️⃣ IoT Data Collection                                 │
│     - Collect sensor data globally                      │
│     - Record data in nearest region                     │
└─────────────────────────────────────────────────────────┘

---

3. Setting Up Global Tables

Prerequisites

Requirement	Description
Empty Table	Recommended to start with empty table
DynamoDB Streams	Automatically enabled
Same Table Name	Same name across all regions
Same Key Schema	Identical partition key and sort key

Console Setup

1. DynamoDB Console → Select table
2. Global Tables tab → Create replica
3. Select target regions (e.g., Tokyo, Virginia)
4. Click Create → Automatic replication starts

CLI Setup

# Add global table replica
aws dynamodb update-table \
  --table-name MyGlobalTable \
  --replica-updates '[
    {
      "Create": {
        "RegionName": "ap-northeast-1"
      }
    }
  ]'

Converting Existing Tables to Global Tables

Existing tables with data can be converted to global tables:

Conversion Process:
1. Create snapshot of source table
2. Create replica in new region
3. Initialize replica with snapshot
4. Start real-time replication

⚠️ Table remains usable during conversion (no downtime)

---

4. Data Consistency and Conflict Resolution

Eventual Consistency

Global Tables use an eventual consistency model. There's a slight delay before data written in one region is replicated to others.

┌─────────────────────────────────────────────────────────┐
│                 Replication Latency                      │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  Write in Seoul:  T = 0ms                               │
│       │                                                 │
│       ▼                                                 │
│  Read in Seoul:   T = 0ms (immediate)                   │
│  Read in Tokyo:   T = ~1 second (after replication)     │
│                                                         │
│  Typical replication delay: Under 1 second              │
│  (varies with network conditions)                       │
└─────────────────────────────────────────────────────────┘

Conflict Resolution: Last Writer Wins

When the same item is modified simultaneously in multiple regions, conflicts can occur.

┌─────────────────────────────────────────────────────────┐
│           Conflict Resolution: Last Writer Wins          │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  Time    Seoul Region            Tokyo Region           │
│  ─────────────────────────────────────────────────────  │
│  T1      Item.name = "A"        (pending replication)   │
│  T2      (pending replication)  Item.name = "B"         │
│  T3      Replication complete   Replication complete    │
│          └──────────────────────────────────────┘       │
│                      Result: "B" (T2 > T1)              │
│                                                         │
│  Rule: Write with later timestamp becomes final value   │
└─────────────────────────────────────────────────────────┘

---

5. Multi-Region Strong Consistency (MRSC)

New Feature (Released 2024)

Multi-Region Strong Consistency (MRSC) is a new feature providing strong consistency for global tables.

MRSC Features

Feature	Description
Consistency	Strong consistency across regions
RPO	Zero RPO (no data loss)
Regions	Minimum 3 regions required
Configuration	3 replicas or 2 replicas + 1 witness

MRSC Architecture

┌─────────────────────────────────────────────────────────┐
│              MRSC Architecture (3 Regions)               │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   Option 1: 3 Replicas                                  │
│   ┌────────┐     ┌────────┐     ┌────────┐             │
│   │Replica │ ◀──▶│Replica │ ◀──▶│Replica │             │
│   │ Seoul  │     │ Tokyo  │     │Virginia│             │
│   └────────┘     └────────┘     └────────┘             │
│                                                         │
│   Option 2: 2 Replicas + 1 Witness                      │
│   ┌────────┐     ┌────────┐     ┌────────┐             │
│   │Replica │ ◀──▶│Replica │ ◀──▶│Witness │             │
│   │ Seoul  │     │ Tokyo  │     │(No data)│             │
│   └────────┘     └────────┘     └────────┘             │
│                                                         │
│   Witness: Stores change data only, no full table copy  │
└─────────────────────────────────────────────────────────┘

---

6. Cost Considerations

Cost Components

Item	Description
Read/Write Capacity	Charged per region
Replicated Write Capacity	Charged for replication writes (rWCU)
Storage	Charged per region
Data Transfer	Cross-region replication transfer costs

Cost Optimization Tips

1. Select Only Needed Regions
   └── No replicas needed in regions without users

2. On-Demand vs Provisioned
   └── Choose based on traffic patterns

3. Enable Auto Scaling
   └── Independent scaling per region

4. Recent Price Reduction (up to 67%)
   └── Global tables costs significantly reduced

---

7. Design Best Practices

Partition Key Design

Partition key design remains critical for global tables:

Good Partition Keys:
├── High cardinality values (UserID, SessionID)
├── Even data distribution
└── Avoid hot partitions

Patterns to Avoid:
├── Region code as partition key (uneven distribution)
├── Date only (hot partition)
└── Sequential values (write concentration)

Application Design

┌─────────────────────────────────────────────────────────┐
│           Application Design Recommendations             │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  1. Local Region Access                                 │
│     └── Use replica in user's nearest region            │
│                                                         │
│  2. Minimize Conflicts                                  │
│     └── Avoid simultaneous modification in multiple     │
│         regions                                         │
│     └── Consider assigning users to specific regions    │
│                                                         │
│  3. Consider Eventual Consistency                       │
│     └── Design logic accounting for replication delay   │
│     └── Be careful with read-after-write patterns       │
│                                                         │
│  4. Failover Testing                                    │
│     └── Regularly test region failover                  │
└─────────────────────────────────────────────────────────┘

---

8. Global Tables vs Other Replication Options

Comparison

Feature	Global Tables	DynamoDB Streams + Lambda	Manual Replication
Management	Fully managed	Semi-automatic	Manual
Active-Active	✅	Possible (complex)	Possible (very complex)
Conflict Resolution	Automatic	Manual implementation	Manual implementation
Latency	Under ~1 second	Several seconds	Variable
Cost	rWCU charges	Lambda + transfer costs	Variable

---

Exam Focus Points

Common Question Types

1. Scenario-based Selection

   • "Low-latency database for global users?" → Global Tables
   • "99.999% availability needed?" → Global Tables
   • "Multi-region Active-Active writes?" → Global Tables

2. Consistency Related

   • "Global Tables consistency model?" → Eventual consistency (default)
   • "Conflict resolution method?" → Last Writer Wins

3. Setup Related

   • "Downtime when converting to global tables?" → None
   • "DynamoDB Streams required?" → Automatically enabled

---

FAQ

Q1: Are global table replicas read-only?

No. All global table replicas support both reads and writes (Active-Active). Different from RDS read replicas.

Q2: What is the replication latency?

Typically under 1 second. However, it can vary depending on network conditions and data size.

Q3: Can I allow writes only in specific regions?

DynamoDB itself doesn't support this. You can route write traffic to specific regions only using Route 53 at the application level.

Q4: Can I convert existing tables with data to global tables?

Yes. You can convert existing tables to global tables without downtime. DynamoDB automatically creates snapshots and initializes new replicas.

Q5: Are GSIs replicated in global tables?

Yes. Global Secondary Indexes (GSI) are automatically created and synchronized across all replicas.

---

Summary

DynamoDB Global Tables are the optimal choice when you need a global-scale Active-Active database:

• 99.999% availability for highest resilience
• Low-latency local region access
• Fully managed for minimal operational burden

For exams, remember keywords "multi-region Active-Active" and "global low-latency database" point to Global Tables.