DynamoDB Global Tables: MREC, MRSC and Setup

DynamoDB global tables replicate a table across AWS Regions so applications can read and write through regional replicas. Choose multi-Region eventual consistency (MREC) for asynchronous replication or multi-Region strong consistency (MRSC) when reads must reflect the latest successful write across replicas. The consistency mode is chosen at creation and cannot be changed afterward.

Choose a consistency mode

A witness supports the MRSC quorum but cannot serve application reads or writes. Region availability differs between modes; check the current global-table documentation before choosing a topology. A strongly consistent read request does not make an MREC table globally strongly consistent.

When should you use global tables?

Use global tables when users need a nearby regional database, when an application must continue through a regional outage, or when multiple regional services share the same operational data. Every replica is writable. You can nevertheless route all writes for a particular customer to one Region to simplify conflict handling.

Replication copies the table, not a selection of rows. Check data residency requirements before creating a replica. A global table also does not replace backups: an accidental delete replicates just like an intentional one. Keep point-in-time recovery configured in the Regions where you need recovery.

The examples below create current-version MREC tables. Do not use the legacy create-global-table API for a new deployment; current global tables use CreateTable and UpdateTable replica settings.

Create a global table in the AWS console

1. Choose the first Region, such as US East (N. Virginia), and open DynamoDB → Tables → Create table.
2. Name the table Orders. Use string attributes pk and sk as its partition and sort keys. Select on-demand capacity for this example and create the table.
3. When it is active, open the table's Global tables tab and choose Create replica.
4. Select Europe (Ireland) as the replica Region and eventual consistency for this example. Review the creation details and confirm.
5. Wait for the replica to become active. Switch the console to Ireland and verify that the table and a test item are present.

DynamoDB enables the stream needed for MREC replication. You do not create or connect a Lambda function to copy the writes. The AWS global-table tutorial also covers the MRSC console workflow, where you choose the complete topology at creation.

Create a global table with the AWS CLI

Use AWS CLI v2 with credentials authorized to create the table and its replica. These commands create the initial table and then add the second Region:

aws dynamodb create-table \
  --region us-east-1 \
  --table-name Orders \
  --attribute-definitions AttributeName=pk,AttributeType=S AttributeName=sk,AttributeType=S \
  --key-schema AttributeName=pk,KeyType=HASH AttributeName=sk,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST \
  --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

aws dynamodb wait table-exists --region us-east-1 --table-name Orders

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

aws dynamodb describe-table \
  --region us-east-1 \
  --table-name Orders \
  --query 'Table.{Version:GlobalTableVersion,Replicas:Replicas}'
aws dynamodb create-table \
  --region us-east-1 \
  --table-name Orders \
  --attribute-definitions AttributeName=pk,AttributeType=S AttributeName=sk,AttributeType=S \
  --key-schema AttributeName=pk,KeyType=HASH AttributeName=sk,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST \
  --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

aws dynamodb wait table-exists --region us-east-1 --table-name Orders

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

aws dynamodb describe-table \
  --region us-east-1 \
  --table-name Orders \
  --query 'Table.{Version:GlobalTableVersion,Replicas:Replicas}'

Replica creation is asynchronous. Inspect ReplicaStatus and wait until the new replica is active before routing requests there. Then write a test item in one Region and read it in the other. On MREC, an immediate read can precede replication even if you request a strongly consistent local read.

Add a replica to an existing table

For an existing MREC table, use the same update-table --replica-updates command. The source can already contain data; DynamoDB backfills the new replica while maintaining replication. Do not create an unrelated table with the same name in the destination first. Check permissions, encryption access and regional throughput quotas before starting.

If CloudFormation or CDK owns the table, add the replica in that configuration instead of making an unmanaged console change. Make one replica change at a time and wait for completion. Adding a replica has restore and transfer charges, covered below. This procedure does not convert a populated table into MRSC.

Create an MREC global table with CloudFormation

Use the native AWS::DynamoDB::GlobalTable resource. A Lambda-backed custom resource is no longer necessary for this setup. Deploy this resource from one stack in one of its replica Regions, not once per Region:

AWSTemplateFormatVersion: "2010-09-09"
Resources:
  Orders:
    Type: AWS::DynamoDB::GlobalTable
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: pk
          AttributeType: S
        - AttributeName: sk
          AttributeType: S
      KeySchema:
        - AttributeName: pk
          KeyType: HASH
        - AttributeName: sk
          KeyType: RANGE
      StreamSpecification:
        StreamViewType: NEW_AND_OLD_IMAGES
      Replicas:
        - Region: us-east-1
        - Region: eu-west-1
AWSTemplateFormatVersion: "2010-09-09"
Resources:
  Orders:
    Type: AWS::DynamoDB::GlobalTable
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: pk
          AttributeType: S
        - AttributeName: sk
          AttributeType: S
      KeySchema:
        - AttributeName: pk
          KeyType: HASH
        - AttributeName: sk
          KeyType: RANGE
      StreamSpecification:
        StreamViewType: NEW_AND_OLD_IMAGES
      Replicas:
        - Region: us-east-1
        - Region: eu-west-1

This creates a new table with an automatically generated name. Retrieve that name from CloudFormation before configuring the application. Replica creation is asynchronous: wait for completion and verify both Regions before sending traffic.

Do not change an existing CloudFormation resource from AWS::DynamoDB::Table to AWS::DynamoDB::GlobalTable as a migration shortcut. AWS warns that this can delete the existing table. Follow the resource's migration and management guidance.

Create a global table with AWS CDK

CDK v2's TableV2 uses the native CloudFormation global-table resource. The stack Region is the first replica; replicas lists the additional Regions. This example is an alternative to the CLI and CloudFormation examples, not another deployment of the same named table:

import { App, Stack, RemovalPolicy } from "aws-cdk-lib";
import { AttributeType, Billing, TableV2 } from "aws-cdk-lib/aws-dynamodb";

const app = new App();
const stack = new Stack(app, "OrdersGlobalStack", {
  env: { region: "us-east-1" },
});

new TableV2(stack, "Orders", {
  partitionKey: { name: "pk", type: AttributeType.STRING },
  sortKey: { name: "sk", type: AttributeType.STRING },
  billing: Billing.onDemand(),
  removalPolicy: RemovalPolicy.RETAIN,
  replicas: [{ region: "eu-west-1" }],
});
import { App, Stack, RemovalPolicy } from "aws-cdk-lib";
import { AttributeType, Billing, TableV2 } from "aws-cdk-lib/aws-dynamodb";

const app = new App();
const stack = new Stack(app, "OrdersGlobalStack", {
  env: { region: "us-east-1" },
});

new TableV2(stack, "Orders", {
  partitionKey: { name: "pk", type: AttributeType.STRING },
  sortKey: { name: "sk", type: AttributeType.STRING },
  billing: Billing.onDemand(),
  removalPolicy: RemovalPolicy.RETAIN,
  replicas: [{ region: "eu-west-1" }],
});

Synthesize and review the generated template before deploying. Use a single controlling stack. The TableV2 reference documents per-replica settings and the separate multiRegionConsistency and witnessRegion options for an MRSC topology. A retention policy on stack deletion is not a substitute for checking the behavior of an individual replica removal.

Route the application to a replica

Use the same table name and key schema, but configure the SDK client for the replica Region. In Node.js with SDK v3:

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, GetCommand } from "@aws-sdk/lib-dynamodb";

const ddb = DynamoDBDocumentClient.from(
  new DynamoDBClient({ region: "eu-west-1" })
);
const { Item } = await ddb.send(new GetCommand({
  TableName: process.env.ORDERS_TABLE,
  Key: { pk: "CUSTOMER#123", sk: "ORDER#001" },
  ConsistentRead: true,
}));
console.log(Item);
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, GetCommand } from "@aws-sdk/lib-dynamodb";

const ddb = DynamoDBDocumentClient.from(
  new DynamoDBClient({ region: "eu-west-1" })
);
const { Item } = await ddb.send(new GetCommand({
  TableName: process.env.ORDERS_TABLE,
  Key: { pk: "CUSTOMER#123", sk: "ORDER#001" },
  ConsistentRead: true,
}));
console.log(Item);

Failover routing belongs in your application or deployment architecture. DynamoDB does not redirect an SDK client configured for an unavailable Region to a different replica automatically. Test a routing change, credentials, permissions and downstream dependencies before relying on it during an incident.

How does conflict resolution work?

MREC uses last-writer-wins reconciliation per item. Suppose the same order starts with status=PENDING. A writer in Virginia changes it to SHIPPED, while a writer in Ireland changes its address using an older local copy. Both requests can succeed locally. When they meet, DynamoDB resolves the competing item versions using its internal timestamps; the application must not assume that every independent attribute edit survives.

An application timestamp such as updatedAt does not configure this conflict algorithm. Nor does a condition on a local MREC replica enforce a global lock: the condition sees that Region's state. For an inventory reservation or another invariant that cannot tolerate conflicting accepted writes, consider MRSC, or route the item's writes through one authoritative Region with a tested ownership-transfer procedure.

Useful MREC designs include immutable event items, assigning each customer a home Region, and separating independently edited entities into different items. Do not treat replicated atomic increments as a globally serialized counter. Transactions remain atomic within their originating Region, but another replica can temporarily see only part of the transaction. AWS does not expose a CloudWatch or CloudTrail log of MREC reconciliation conflicts.

MRSC requirements and limitations

MRSC is suitable when a successful write must survive regional failover without a replication-loss window and strong reads in another replica must see it. Request strong consistency explicitly on supported read APIs; an eventually consistent read or a GSI query does not acquire strong semantics merely because the table uses MRSC.

Plan the topology and feature requirements before creating it:

• Start with an empty table and configure exactly three Regions: three full replicas, or two replicas and a witness.
• A witness participates in replication but cannot answer application reads or writes. It has no storage or write charge.
• The consistency mode cannot be changed later. You cannot add more MRSC replicas later or independently remove a replica or witness.
• MRSC does not support TTL, local secondary indexes or DynamoDB transaction APIs. Global secondary indexes are supported but remain eventually consistent.
• All MRSC replicas must be in the same AWS account. Multi-account support applies to MREC.
• Concurrent writes to the same item can return ReplicatedWriteConflictException; retry with backoff and preserve application idempotency.

As of September 23, 2026, MRSC supports combinations of three Regions from its 15 supported Regions, including across continents. The older requirement to stay within a fixed Region set no longer applies. Check the current Region list in the MRSC expansion announcement and measure cross-Region write and strong-read latency for your application.

How much do global tables cost?

Global tables charge replicated writes in every Region receiving a write, including the originating Region. Reads are billed where they run, and each full replica has its own storage and index costs. The following rates are for US East (N. Virginia), Standard table class, before discounts:

For illustration, one million writes of up to 1 KB replicated across two Regions with the same $0.625/M rate cost $1.25 in base replicated-write requests. This calculation excludes index writes, reads, storage, transfer and backups. Larger items consume more units, and the destination Region's price can differ.

The November 2024 price cut reduced on-demand replicated-write prices by 67% and provisioned replicated-write prices by 33%, effective November 1. Estimates using the former $1.875/M Standard rWRU rate in us-east-1 are outdated. MRSC uses standard global-table pricing; its witness is not a third billable full replica.

TTL deletes on MREC are free in the Region performing expiration, but their replication consumes billed write units in other Regions. Adding an index adds regional write and storage costs too. See the AWS pricing page and DynamoDB pricing calculator when building a complete estimate.

Monitor replication and practice failover

Monitor MREC ReplicationLatency for each source and destination Region pair. It measures the delay between a change appearing in the source replica's stream and reaching the destination replica. Typical replication is within a second, but that is not a latency SLA. Alarm on sustained deviation from your application's recovery objective, alongside throttling, errors and replica status. MRSC does not publish this metric.

A replica with inadequate write capacity or a restrictive throughput setting can fall behind. Inspect the table and its GSIs in every Region, and check KMS access if a replica becomes inaccessible. For capacity and request diagnosis, use the metrics described in DynamoDB logging and monitoring.

Test failover end to end: switch the regional SDK endpoint, confirm IAM and KMS permissions, verify dependent services, and observe the application's behavior with stale MREC reads or MRSC retries. Set PITR, deletion protection, alarms and access policies deliberately in each Region; these settings are not all copied automatically. Review the SLA conditions separately from your own recovery objectives.

Multi-account replicas and removing a replica safely

Current-version MREC global tables support replicas across AWS accounts, available since February 3, 2026. This can separate regional ownership or security boundaries while preserving managed replication. Configure the documented cross-account permissions and coordinate control of replicated settings; a replica in another account is still part of the same replicated dataset.

Since October 20, 2026, you can disassociate an MREC replica and keep it as a standalone table. It retains its name, ARN and settings, but stops exchanging future changes with the other replicas. This applies to same-account and multi-account current-version MREC tables, not MRSC or legacy global tables. See the replica disassociation announcement.

Choose disassociation explicitly when you need to preserve the data. Do not assume that an ordinary delete operation has the same behavior. Before separating a replica, stop or redirect its writers, verify replication has caught up, and plan how independently changing copies will be used afterward.