Is DynamoDB multi-region?

It can be. A standard DynamoDB table lives in one Region, but global tables make it multi-Region and multi-active, replicating automatically across your chosen Regions so you can read and write in any of them. Global tables offer up to 99.999% availability, with eventual or opt-in strong multi-Region consistency.

Standard tables vs global tables

By default a table exists in a single Region. Turn on global tables to add replica tables in other Regions; DynamoDB then keeps them in sync automatically.

Multi-active replication

Every replica accepts both reads and writes. A write to any Region propagates to the others — there is no primary Region and no failover step if one Region becomes unavailable.

Consistency choices

Multi-Region eventual consistency (MREC) — the default: writes replicate asynchronously, typically within a second. Conflicts resolve last-writer-wins.
Multi-Region strong consistency (MRSC) — chosen at creation: each write replicates synchronously to at least one other Region before returning, so strongly consistent reads on any replica return the latest item. MRSC tables are deployed in exactly three Regions (three replicas, or two replicas plus a witness) and do not support TTL, LSIs, or the transaction APIs.

What a third Region costs

Each replica holds a complete copy of the table, so storage is billed in every Region at that Region's own rate. Those rates are not equal, so the multiplier is never a round 3x.

Take 100 GB, priced from our synced AWS table:

Region	Storage, 100 GB / month
us-east-1 (N. Virginia)	$25.00
eu-west-1 (Ireland)	$28.30
sa-east-1 (Sao Paulo)	$37.50
Three-Region global table	$90.80

That is 3.63x the single-Region bill for three replicas, and the Region mix is what moves it. Swap Sao Paulo for Tokyo (ap-northeast-1, $28.50) and the same three copies cost $81.80.

Writes carry their own multiplier. AWS bills them as "replicated write request units (rWRU) for on-demand capacity and replicated write capacity units (rWCUs) for provisioned capacity", so one logical write is charged in every replica Region.

You cannot rehearse this locally

DynamoDB Local implements most of the data plane, but not replication. Adding a replica is accepted as a no-op rather than rejected as unsupported, which is the more dangerous failure:

UpdateTable with ReplicaUpdates:
ValidationException: Nothing to update

CreateGlobalTable:
UnknownOperationException: An unknown operation was requested.

So a local integration test can pass while your replication assumptions are never exercised. Conflict resolution, replication lag and MRSC's Region rules only show up against real Regions.

Why use it

Low-latency local access for globally distributed users, plus resilience and business continuity.

Go deeper

Read the DynamoDB global tables guide. Download DynoTable to work across your replica Regions.

References

Last verified 2026-07-13 against the official AWS documentation linked above; the replicated-write billing wording was re-checked 2026-07-28.

Storage figures computed 2026-07-28 from our synced AWS pricing table. The emulator responses were reproduced the same day against DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 and are verbatim.