DynamoDB On-Demand vs Provisioned

Model both capacity modes on your real traffic shape. Provisioned is ~3.5x cheaper per request and bills every hour whether traffic arrives or not — so the decision turns on how peaky your traffic is, not how large it is.

Prices verified 4 Aug 2026
On-demand is cheaper for this table
$306.69/mo
$492.75 on-demand against $799.44 provisioned, for throughput. Storage adds $43.75 either way.
On-demand throughput329M writes and 1.3B reads a month$492.75
Provisioned throughput1,404 WCU and 1,404 RCU, sized for peak at 70.0% utilisation$799.44
StorageIdentical under both modes$43.75
Cheapest total$536.50

Why, in one number

Your effective utilisation
17.5%
Average traffic against the capacity provisioned for peak.
Break-even utilisation
100.0%
Above this, provisioned wins. Below it, on-demand does.
Capacity per write / read
2 / 0.5
At 2 KB items, eventually consistent reads.

Provisioned capacity is roughly 3.5x cheaper per request than on-demand — but you pay for it every hour whether traffic arrives or not. That is why the decision turns on the shape of your traffic rather than its volume. A table doing a billion requests a month in two daily spikes belongs on on-demand; a table doing a tenth of that at a flat rate belongs on provisioned.

What this model assumes

  • Provisioned capacity is sized for peak, not average. That is what makes the comparison meaningful. A model that provisions for average traffic is describing a table that throttles.
  • Auto-scaling does not reach 100%. It reacts on a delay and needs headroom for the gap, so a well-tuned provisioned table lands near 70%. The default reflects that; raise it if your traffic is genuinely smooth.
  • Capacity units round up per operation. A 1.2 KB write consumes two write units, not 1.2 — so item size matters in steps, and shaving an item from 1.1 KB to 0.9 KB halves its write cost.
  • Reserved capacity is not modelled. It exists for provisioned tables and discounts further, which makes provisioned look better than shown for genuinely steady workloads. It also cannot be applied to on-demand at all.
  • Not included: global tables and replicated writes, streams, backups (on-demand $0.1/GB-month, point-in-time recovery $0.2), data transfer, or DAX.
Rates used
  • DynamoDB capacity, requests and storage source, read 4 Aug 2026

US East (N. Virginia) list prices, excluding any negotiated or committed-use discount. Your effective rate is lower if you have one.

Frequently asked questions

Is DynamoDB on-demand or provisioned cheaper?

It depends on the shape of your traffic, not its volume. Provisioned capacity is about 3.5x cheaper per request but bills every hour whether traffic arrives or not. Below roughly 15-20% sustained utilisation the wasted capacity exceeds the discount and on-demand wins at any scale. A table doing a billion requests a month in two daily spikes belongs on on-demand; a table doing a tenth of that at a flat rate belongs on provisioned.

How much does DynamoDB cost?

On-demand: $0.625 per million write request units and $0.125 per million read request units in US East (N. Virginia). Provisioned: $0.00065 per write-capacity-unit-hour and $0.00013 per read-capacity-unit-hour. Storage is $0.25 per GB-month after the first 25 GB, which is free permanently.

What is a DynamoDB capacity unit?

One write capacity unit covers one write of up to 1 KB per second. One read capacity unit covers one strongly consistent read of up to 4 KB per second, or two eventually consistent reads. Both round up per operation, so a 1.2 KB write consumes two write units — which is why shaving an item under 1 KB halves its write cost.

Does DynamoDB auto-scaling reach full utilisation?

No. It reacts on a delay and needs headroom to cover the gap, so a well-tuned provisioned table typically lands near 70% utilisation rather than 100%. Assuming perfect utilisation is the most common way a provisioned estimate comes in too low, and this calculator exposes the assumption as an input.

Is the DynamoDB Infrequent Access table class worth it?

It cuts storage from $0.25 to $0.10 per GB-month and raises throughput rates by about a quarter, so it wins on tables that store a lot and are read rarely — archives, audit logs, event history. It loses on hot tables. You can switch table class twice per 30 days.

One table modelled. Most estates have hundreds.

Finitizer reads real consumed-capacity metrics per table, finds the ones on the wrong capacity mode, and catches the provisioned tables whose traffic shape changed after someone set them up two years ago.