Capacity & cost calculator
Estimate RCU/WCU and compare on-demand vs provisioned monthly cost.
The capacity calculator turns an item size and a read/write rate into the read and write capacity units DynamoDB needs, and the estimated monthly cost — side by side for on-demand and provisioned billing.
Opening it
Open the calculator from the Calc button in the toolbar or via the command palette (/docs/command-palette/). It’s a standalone panel — it doesn’t read your table, so you can model any scenario, including a table you haven’t created yet.
Inputs
| Input | Meaning |
|---|---|
| Item size (KB) | Average size of one item |
| Consistency | Strong or eventually-consistent reads |
| Reads / sec | Sustained read rate |
| Writes / sec | Sustained write rate |
How the units are computed
The math follows DynamoDB’s unit rules:
- Reads: one read consumes
ceil(size / 4)units (each 4 KB block), with a minimum of 1. Eventually-consistent reads cost half as much as strongly-consistent ones. - Writes: one write consumes
ceil(size / 1)units (each 1 KB block), minimum 1.
Multiplied by your per-second rates, that gives the RCU and WCU you’d provision:
Item 2 KB, eventual reads, 100 reads/s, 20 writes/s
read units/op = ceil(2/4) → 1, halved for eventual → 0.5
write units/op = ceil(2/1) → 2
RCU = 0.5 × 100 = 50 WCU = 2 × 20 = 40The result card shows RCU / WCU rounded up.
On-demand vs. provisioned cost
The panel estimates monthly cost two ways:
- On-demand — priced per million request units (read + write), billed for what you actually consume over the month.
- Provisioned — priced per capacity-unit-hour over 730 hours, assuming 100% duty (no autoscaling, capacity held all month).
A fourth card shows the savings of provisioned versus on-demand for the modelled rate — provisioned tends to win for steady, predictable traffic, while on-demand wins for spiky or unpredictable workloads. Costs use us-east-1 list-price estimates (reflecting the post-November-2024 on-demand price cut).
Every input is live: change the item size, rate, or consistency and all four cards recompute instantly, so you can sweep a range of scenarios — double the traffic, halve the item size, flip to eventual reads — and watch the cost and the on-demand/provisioned crossover move. That makes it quick to find the point where switching billing mode pays off, or to see how much an oversized item is costing you per read.
Reading the result
RCU / WCU 50 / 40
On-demand / month $X.XX
Provisioned / month $Y.YY
Savings NN%Use it to sanity-check a billing-mode choice before creating a table (/docs/create-table/), to size provisioned throughput for a new GSI in the migration wizard, or to estimate what a full-table scan or backfill will cost in read/write units.
Limitations
- Estimates, not a bill. Prices are hard-coded us-east-1 list-price approximations; your region, reserved capacity, free tier, and discounts will change the real number. Treat the output as a planning aid.
- Steady-state model. The provisioned figure assumes constant 100% duty with no autoscaling, and the rates you enter are treated as sustained — real traffic is bursty.
- Single-table, single dimension. It models one average item size and one read/write rate. It doesn’t account for GSI replication writes, transactions, on-demand burst pricing tiers, storage, backups, or streams.
- You supply the inputs. The calculator doesn’t measure your table; for the actual size and shape of your data, the per-entity capacity breakdown lives in the Single-Table Design Studio.