DynamoDB on-demand is one of the easiest "set and forget" AWS choices — and one of the most expensive defaults if you leave it set and forget for long. The break-even point against provisioned capacity with autoscaling sits at a fairly predictable utilisation level, but almost nobody computes it. Then the bill arrives.
How each mode bills
- On-demand — $1.25 per million write request units, $0.25 per million read request units. No floor, no capacity to manage. Pay strictly per request.
- Provisioned — $0.00065 per WCU/hour, $0.00013 per RCU/hour. With autoscaling, capacity tracks demand within configured min/max bounds. You commit to a floor.
The relevant math: 1 WCU sustained for an hour ≈ 3,600 write requests. At $0.00065, that's about $0.18 per million writes — 7× cheaper than on-demand, but only if you actually use the capacity you provisioned.
The crossover rule
Provisioned + autoscaling beats on-demand once sustained utilisation exceeds roughly 14–18% of peak. Below that, on-demand wins because you would pay for capacity that sits idle. Above that, the per-request economics of provisioned compound against you fast.
Most engineering teams who default to on-demand operate above this threshold within weeks of any real product traction.
Six traffic shapes, simulated
| Workload shape | Peak WCU | Avg utilisation | On-demand | Provisioned + autoscale |
|---|---|---|---|---|
| Steady traffic | 500 | 85% | $1,360/mo | $240/mo |
| Daily diurnal | 500 | 45% | $720/mo | $210/mo |
| Weekday-only | 500 | 30% | $480/mo | $170/mo |
| Sparse bursts | 500 | 10% | $160/mo | $190/mo |
| Pure idle + spike | 1,000 | 3% | $96/mo | $280/mo |
| Unpredictable | varies | n/a | matches load | throttles or overpays |
The pattern: provisioned wins whenever utilisation is sustained, even when it's only 30%. On-demand wins for genuinely sparse or unpredictable workloads.
When each mode is the right answer
On-demand wins
Brand-new tables with no traffic profile yet. Cron-driven workloads with deep idle periods. Workloads with unpredictable 10×+ spikes that autoscaling cannot keep up with.
Provisioned wins
Any workload with a recognisable daily pattern. Steady-state product traffic. Anywhere you can confidently set a sensible min capacity that captures the floor.
Migrate often
Re-check the math every quarter. Workloads that started sparse become steady; traffic patterns drift. The "right" mode is not a one-time decision.
Two autoscaling traps to know
- Slow scale-up. Autoscaling responds in minutes, not seconds. If your spike profile is sub-minute, autoscaling will throttle before it catches up. Either pre-scale before known events or accept throttling and design retries for it.
- Min-capacity creep. Teams set a generous floor "for safety" and forget about it. That floor bills 24×7. We routinely find tables paying for 80% utilisation headroom that hasn't been needed since the last product launch.
Drop a DynamoDB node on the pinpole canvas, configure your real read/write pattern, and toggle between on-demand and provisioned with sensible autoscale bounds. The simulator returns both monthly cost numbers side by side. If on-demand is more than 30% more expensive, switch.
Simulating your table
The pinpole canvas exposes both capacity modes as configuration on the DynamoDB node. Set traffic at your peak, choose the traffic pattern (Constant, Ramp, Spike, Wave), and run. The simulator models RCU/WCU consumption per second and returns a live monthly cost. Swap the mode and re-run. The answer rarely takes more than five minutes to surface.
One DynamoDB table on the wrong capacity mode can cost five figures a year.
Run both modes through the simulator with your real traffic shape before the bill makes the decision for you.
Start 14-day free trial →