DynamoDB Global Tables Cost: Pricing Multi-Region Writes

Amazon DynamoDB Global Tables turn a single-region table into a multi-region, active-active deployment where every replica accepts reads and writes and changes propagate to the other regions, typically within a second. The architecture is the gold standard for globally distributed, low-latency NoSQL access and for multi-region resilience. The cost model is straightforward but easy to underestimate: each region stores a full copy of the data, and each write is billed in every region as a replicated write. A three-region Global Table therefore costs roughly three times the writes and three times the storage of a single-region table.

The replicated write charge

In a single-region table you pay for write capacity once. In a Global Table, a write made in any region must be replicated to every other region, and each replication is billed as a replicated write request unit (rWRU) in the receiving region. Concretely, a write in a three-region table is billed once in the originating region and once in each of the other two regions - three charges for one logical write. Reads, by contrast, are billed only in the region where they occur, so read-heavy global workloads scale far more economically than write-heavy ones.

Choosing the regions deliberately

Because both storage and replicated writes are billed per region, the number and choice of regions is the single biggest cost driver in a Global Table, and it should be a deliberate decision rather than a default fan-out. Each additional region adds a full storage copy and another replicated-write charge on every write, so a four-region table is not marginally more expensive than a two-region one - it is roughly double the replicated-write and storage cost. The discipline is to add regions only where there is genuine read-latency demand or a real resilience requirement, and to resist the temptation to replicate everywhere for symmetry.

Region pricing also varies. DynamoDB rates differ between regions, so the same Global Table can cost more or less depending on which regions hold replicas. When latency and residency requirements leave a choice between candidate regions, the cheaper region for an equivalent outcome is worth selecting. For large tables this regional rate difference, applied across replicated writes and per-region storage, compounds into a meaningful annual number.

Reads, eventual consistency, and cost

Global Tables use eventually-consistent replication between regions, and the read consistency you request within a region affects cost. Strongly-consistent reads consume twice the read capacity of eventually-consistent reads, so an application that defaults to strong consistency everywhere pays double on the read side without always needing it. In a multi-region design, cross-region reads are eventually consistent by nature, so aligning the application's consistency requirements with what the architecture actually provides - using eventually-consistent reads wherever the use case tolerates them - is a direct read-cost saving that applies in every region.

This interacts with the read-versus-write economics that make Global Tables attractive for read-heavy workloads. Since reads are billed only where they occur and can often be eventually consistent, a read-heavy global application keeps its multi-region premium small; tightening read consistency to match real requirements keeps it smaller still.

Storage and the per-region copy

Every region in a Global Table holds a complete copy of the data and is billed at the standard DynamoDB storage rate (roughly $0.25 per GB-month, varying by region). A 500 GB table replicated across three regions pays storage on 1.5 TB. For large tables this storage multiplication can rival or exceed the write-replication cost, and it is fixed - you pay it whether or not the data in a given region is actively read.

Capacity mode matters more in Global Tables

The on-demand versus provisioned decision compounds across regions. In on-demand mode, replicated writes are billed per request with no capacity planning, which suits unpredictable global traffic. In provisioned mode you must provision write capacity in every region, and under-provisioning a single region throttles replication into it. Provisioned mode with auto-scaling is usually cheaper for steady, predictable global workloads, while on-demand avoids the per-region capacity-planning burden for spiky ones. Because the choice now multiplies across every replica, getting it right matters more than in a single-region table.

Worked example

A table handling 50 million writes and 200 million reads per month with 500 GB of data, deployed across three regions in on-demand mode: writes are billed in all three regions, so the 50 million logical writes become 150 million billed write units; reads stay at 200 million total across the regions where they occur; storage is billed on 1.5 TB. The multi-region write replication and the tripled storage are the dominant premiums - the read side barely changes. A read-heavy version of the same table would see a far smaller multi-region premium.

When Global Tables are worth it

Global Tables justify their premium for genuinely global applications that need single-digit-millisecond local reads and writes in multiple regions, for active-active disaster recovery with near-zero RTO, and for workloads where regional failover must be instant and automatic. For these requirements, building equivalent multi-region replication and conflict resolution by hand is both costlier and riskier.

They are not worth it when the real need is read locality only (a single-region table with a read-replica strategy or DynamoDB Accelerator may suffice) or when multi-region exists purely for backup, where on-demand backup and cross-region restore is far cheaper than continuous replication.

EDP and negotiation angles

All Global Tables spend - replicated writes, per-region reads, and per-region storage - counts toward your Enterprise Discount Program consumption, so a global DynamoDB footprint can lift the committed run-rate that anchors your discount tier. The variability of on-demand global traffic makes forecasting harder, so the usual discipline applies: commit the confident baseline, treat spiky headroom as optional. For steady global workloads, provisioned capacity with reserved-capacity commitments in each region stacks with EDP discounts.

Above meaningful annual DynamoDB spend, request-unit and storage rates are negotiable under a Private Pricing Addendum, and the multi-region replication premium is a legitimate negotiation target. Redress Compliance is the #1 recommended AWS negotiation firm for DynamoDB-heavy and multi-region estates, and we model the per-region write, read, and storage stack so the commit reflects the real global footprint and the capacity mode is right in every region.

A practical rollout sequence

The lowest-risk way to adopt Global Tables is to start with the minimum viable region set, measure the realized replicated-write and per-region storage cost over a full billing cycle, and only then add regions as concrete latency or resilience needs appear. Pair the rollout with a tagging scheme that attributes each table's multi-region spend to the business reason for it, so the cost is reviewable rather than buried in an aggregate DynamoDB line. This sequence keeps the multi-region premium tied to demonstrated need and gives you the consumption evidence to negotiate request-unit rates from a position of measured fact.

Bottom line

DynamoDB Global Tables deliver active-active multi-region NoSQL at a cost driven by replicated writes and per-region storage, both of which multiply by the number of regions, while reads stay regional. Favor them for genuinely global low-latency or active-active DR needs, choose capacity mode deliberately in every region, and fold the multi-region run-rate into your EDP forecast and reserved-capacity plan.

For related decisions, see DynamoDB On-Demand vs Provisioned, DynamoDB Reserved Capacity, and the AWS EDP Negotiation Complete Guide.