DynamoDB’s pricing model reads simply on the surface — pay for read and write capacity — but the unit conversion underneath it is where most cost surprises come from. A “read” and a Read Capacity Unit (RCU) are not the same thing, and the gap between them is exactly where over-provisioned tables and unexpectedly large bills come from.
What one capacity unit actually buys
- 1 WCU = one write per second, for an item up to 1 KB.
- 1 RCU = one strongly consistent read per second, for an item up to 4 KB — or two eventually consistent reads per second, same item size.
The item-size ceiling is the part that catches people off guard. A 4.5 KB item doesn’t round down — it consumes capacity for two 4 KB blocks, not one. Write a 10 KB item and you’re billed for 10 WCUs, not 1, because writes always round up to the next whole KB. This is why two tables with identical request-per-second rates can have wildly different costs if one stores small key-value pairs and the other stores medium-sized JSON documents.
Consistency mode changes the bill by 2x
Because eventually consistent reads cost half of what strongly consistent reads cost per RCU, the consistency setting you pick per request directly controls your bill. If your access pattern can tolerate reading slightly stale data (most read-heavy, cache-adjacent workloads can), switching non-critical reads from strongly consistent to eventually consistent is a legitimate 2x cost reduction with no infrastructure change — just a parameter on the read call.
Transactions cost double, silently
TransactWriteItems and TransactGetItems consume 2x the capacity units of the equivalent non-transactional call, because DynamoDB does two underlying operations (prepare and commit) to guarantee atomicity. This cost is easy to miss because it doesn’t show up as a separate line item — it just shows up as your table’s capacity consumption being roughly double what a “requests per second” estimate would suggest, for any workload that leans on transactions for multi-item consistency.
On-demand vs. provisioned: a workload question, not a savings question
On-demand pricing (~$1.25 per million WCU, ~$0.25 per million RCU) charges per request with no capacity planning required, but at roughly 5-7x the per-unit cost of provisioned capacity. Provisioned capacity is cheaper per unit but requires estimating peak throughput correctly — under-provision and you get throttled requests, over-provision and you pay for idle capacity around the clock.
The break-even generally comes down to how spiky your traffic is: steady, predictable workloads favor provisioned capacity (with auto scaling handling gradual drift); bursty or unpredictable workloads — new features, low-traffic tables, anything without traffic history yet — usually favor on-demand until a real usage pattern emerges to provision against.
Modeling it before you provision
Once you’ve worked out your real RCU/WCU numbers using the item-size and consistency-mode rules above, the harder question is usually on-demand vs. provisioned — and that depends on how spiky your traffic actually is, which is hard to eyeball. Our DynamoDB RCU, WCU & Cost Sizing Calculator takes your baseline capacity plus a traffic-spike multiplier and duration, and models the full monthly cost under both pricing modes side by side, so you can see exactly where the cost cliff between them sits for your workload.
If your table’s access pattern relies on a hot partition being offloaded to reads, the Read Replica Sizer and Connection Pool Sizer calculators cover the equivalent capacity-planning questions for relational databases sitting alongside DynamoDB in a mixed architecture.