AWS DynamoDB global tables cost: you replicate writes and storage
Global tables replicate a DynamoDB table across regions, so you pay replicated write capacity, storage in every region, and cross-region replication transfer. The multiplier is the number of regions. Here is when multi-region is worth it.
Quick answer
DynamoDB global tables replicate a table across regions, so you pay for replicated writes (each write is applied in every region, billed as replicated write capacity), storage in every region, and cross-region replication data transfer. Cost scales with the number of regions, so multi-region is worth it for genuine global low-latency access or regional failover, not by default.
DynamoDB global tables give you a multi-region, multi-active table with local read and write latency in each region. That capability is powerful and multiplies cost: every write is applied in every region, and the data is stored in every region, so a table replicated to three regions costs close to three times a single-region table on the write and storage lines.
What replication multiplies
| Cost | Effect of adding a region |
|---|---|
| Writes | Each write replicated to the region (replicated write capacity) |
| Storage | Full copy of the data in the region |
| Replication transfer | Cross-region data transfer for replication |
| Reads | Billed where they occur (local reads in each region) |
Writes are the key multiplier: a write in one region is replicated to all others, and you pay replicated write capacity for each. Storage is a full copy per region. Cross-region replication traffic is billed as data transfer. Reads are billed where they happen, so distributing read traffic does not add cost the way writes do.
When multi-region is worth it
Global tables earn their multiplied cost when you genuinely need local low-latency access for users in multiple regions, or multi-region failover for availability a single region cannot provide. For a single-region user base, or where read latency is the only concern, a single-region table with a CDN or caching in front is far cheaper.
Controlling global tables cost
Replicate to only the regions you actually serve, not everywhere by default, since each region adds write and storage cost. Use on-demand or right-sized provisioned capacity in each region, and remember that reducing writes (batching, avoiding unnecessary updates) saves across every region at once because each write is multiplied. The multi-region cost-versus-benefit is the same as the broader multi-region tradeoff.
FAQ
How do DynamoDB global tables affect cost?
They replicate the table across regions, so you pay replicated write capacity (each write applied in every region), storage in every region, and cross-region replication data transfer. Cost scales with the number of regions, roughly multiplying the write and storage lines by the region count.
Why are writes the main cost in global tables?
Because every write in one region is replicated to all other regions, and you pay replicated write capacity for each. A table in three regions bills three times the write capacity of a single-region table for the same write volume. Reads, by contrast, are billed where they occur.
When are DynamoDB global tables worth the cost?
When you genuinely need local low-latency access for users in multiple regions or multi-region failover for availability a single region cannot provide. For a single-region user base or read-latency-only concerns, a single-region table with a CDN or caching is far cheaper.
How do I reduce global tables cost?
Replicate to only the regions you actually serve rather than everywhere, right-size or use on-demand capacity per region, and reduce writes through batching and avoiding unnecessary updates, since each write is multiplied across regions so write reductions save everywhere at once.
Do reads cost extra in global tables?
Reads are billed where they occur, so distributing read traffic across regions does not multiply cost the way writes do. Each region serves and bills its local reads. The multiplication is on writes (replicated to all regions) and storage (a copy per region).
Does C3X estimate DynamoDB cost?
C3X prices DynamoDB tables from your Terraform, including capacity mode. For global tables, replicated write capacity and per-region storage depend on region count and write volume, which you provide as usage assumptions to estimate the multi-region cost.
What to do next
Model multi-region before you enable it. C3X reads your Terraform and prices DynamoDB and the rest of your stack against a live catalog. Start with the quickstart.
Pricing references
Related posts
- DynamoDB GSI cost explained: the index that quietly doubles writes
A DynamoDB Global Secondary Index has its own throughput and storage, and every write to the base table that touches indexed attributes is also billed against the GSI. Here is how GSI cost works, why projections matter, and how a few indexes can double your write bill.
- AWS Timestream cost: writes, tiered storage, and queries scanned
Timestream bills writes per million, storage in a fast memory tier (per GB-hour) and a cheap magnetic tier (per GB-month), and queries per GB scanned. Tuning retention between tiers and scanning less are the levers. Here is the model.
- DynamoDB backup and restore cost: on-demand, PITR, and exports compared
DynamoDB offers on-demand backups, point-in-time recovery, and S3 exports, each priced differently. Here is what each costs per GB, when continuous backup is worth double the on-demand rate, and how restores and exports are billed.
- DynamoDB DAX cost: is the in-memory cache worth it?
DynamoDB Accelerator (DAX) is a managed in-memory cache that can cut read latency to microseconds and read cost on hot data, but it runs on always-on nodes with a three-node minimum for production. Here is what DAX costs and the read volume where it starts to pay for itself.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.