Replicate Data Across AWS Regions (2026)

Replication across AWS regions isn’t about copying files; it’s about building a distributed system that can tolerate entire data centers vanishing.

Let’s say you’re running an e-commerce site and need to keep your product catalog and order data available even if the entire US East (N. Virginia) region goes offline. You’d typically use something like Amazon RDS with cross-region read replicas, or DynamoDB Global Tables.

Here’s a simplified look at how DynamoDB Global Tables work, focusing on a single table replicated between us-east-1 and eu-west-1.

Imagine this Products table:

{
  "TableName": "Products",
  "KeySchema": [
    {
      "AttributeName": "ProductID",
      "KeyType": "HASH"
    }
  ],
  "AttributeDefinitions": [
    {
      "AttributeName": "ProductID",
      "AttributeType": "S"
    }
  ],
  "ProvisionedThroughput": {
    "ReadCapacityUnits": 5,
    "WriteCapacityUnits": 5
  }
}

When you enable Global Tables, DynamoDB automatically provisions a replica of this table in the other region.

us-east-1 (Primary Region)

Write: A user updates a product price. The write request hits the Products table in us-east-1.

aws dynamodb put-item \
    --table-name Products \
    --item '{
        "ProductID": {"S": "PROD123"},
        "Price": {"N": "19.99"}
    }' \
    --region us-east-1

DynamoDB processes this write and assigns a version identifier.

Replication: DynamoDB then asynchronously replicates this change to the Products table in eu-west-1. This isn’t a simple copy-paste. DynamoDB uses a conflict resolution mechanism. If the same item is modified concurrently in both regions, the most recent write (based on timestamp) wins.

eu-west-1 (Replica Region)

Read: A user in Europe browses products. Their read request is routed to the Products table in eu-west-1. This read is served locally, providing low latency.
```
aws dynamodb get-item \
    --table-name Products \
    --key '{"ProductID": {"S": "PROD123"}}' \
    --region eu-west-1
```

Write (Concurrent): Simultaneously, a different user in Europe updates the same product’s price. This write request hits the Products table in eu-west-1.

aws dynamodb put-item \
    --table-name Products \
    --item '{
        "ProductID": {"S": "PROD123"},
        "Price": {"N": "20.99"}
    }' \
    --region eu-west-1

Conflict Resolution: Now, DynamoDB has two versions of PROD123 with different prices. Global Tables automatically resolve this. If the us-east-1 write happened at T1 and the eu-west-1 write at T2, and T2 is later than T1, the eu-west-1 price (20.99) will become the authoritative version across both regions. The change from us-east-1 will be overwritten.

Enabling Global Tables:

You don’t enable it on a per-item basis. You enable it at the table level.

aws dynamodb update-table \
    --table-name Products \
    --replica-updates '[
        {
            "Create": {
                "RegionName": "eu-west-1"
            }
        }
    ]' \
    --region us-east-1

After this, you’d repeat the update-table command from eu-west-1 to add us-east-1 as a replica, ensuring bi-directional replication.

Key Levers:

Regions: You choose which AWS regions your table is replicated to.
Capacity: Each region needs its own provisioned throughput (or use on-demand). Writes in one region consume capacity in that region, and replication traffic is handled by DynamoDB.
Conflict Resolution: The default is "last writer wins" based on timestamp. For complex scenarios, you might need to architect your application to handle potential conflicts before they hit DynamoDB, or use conditional writes.

The most surprising thing about DynamoDB Global Tables is how seamlessly they present a single, consistent (eventually) table across disparate geographic locations without you needing to manage any inter-region networking or replication daemons. The underlying mechanism uses DynamoDB Streams and a distributed commit protocol to ensure changes propagate and conflicts are resolved. When a write occurs in one region, it generates a stream event. This event is then processed by the DynamoDB service in the other regions, applying the change to the local replica. The magic is in how DynamoDB’s internal infrastructure handles the fan-out and potential conflicts concurrently.

If you have multiple regions configured and a write occurs in one, a subsequent read in another region might return stale data for a brief period until the replication lag catches up.