All cheat sheets
Databasescheat sheet

DynamoDB On-Demand vs Provisioned

DynamoDB On-Demand bills per request and scales instantly with zero capacity planning — nearly 4× cheaper than provisioned on bursty workloads. The break-even: if you'd run provisioned above ~27% utilization consistently, provisioned wins.

Last reviewed: July 14, 2026

TL;DR: DynamoDB On-Demand bills per request — no provisioning, no capacity spreadsheets, and it scales up (and to zero) automatically. On bursty or unpredictable traffic that's quiet most of the day, it's routinely ~4× cheaper than provisioning for peak and removes throttling risk. The break-even is clean: if you'd run provisioned capacity consistently above ~27% utilization, provisioned (especially with reserved capacity) is cheaper. Below that, On-Demand wins.

The numbers

  • On-Demand pricing (us-east-1): $1.25 per million write request units (WRU = 1 write ≤ 1 KB), $0.25 per million read request units (RRU = 1 strongly-consistent read ≤ 4 KB, or 2 eventually-consistent).
  • Break-even ≈ 27% provisioned utilization — bursty workloads almost always sit below it.
  • Worked example — 1M writes + 5M reads/day, bursty: On-Demand = 30M × $1.25/M + 150M × $0.25/M = $75/mo; provisioned for peak (300 WCU + 1,500 RCU 24/7) ≈ $284/mo — On-Demand is nearly 4× cheaper.
  • No throttling within the default 40,000 WRU/RRU-per-second table limits; handles double your previous peak instantly.
  • Mode switch: once per 24 hours per table — enough to flip around a known event.

Do this

  1. Default to On-Demand unless you have a specific reason not to — it kills over-provisioning waste, throttling surprises, and capacity planning in one move.
  2. Measure utilization before choosing provisioned — CloudWatch consumed vs provisioned capacity over 30 days; only go provisioned if you're sustainably above ~27%.
  3. Use the seasonal switch — run provisioned most of the year, flip to On-Demand a few days before a Black Friday-style surge, flip back after.
  4. Go hybrid per table — steady core user table on provisioned (add Reserved Capacity for up to ~76% off), unpredictable promotions/events table on On-Demand.
  5. Pre-request a limit increase if you'll exceed 40K RRU/WRU per second — On-Demand isn't literally unlimited.

Gotchas

  • On-Demand only changes request pricing — storage is $0.25/GB-mo either way, and cold data still bills; tier it with DynamoDB Standard-IA.
  • Global Tables roughly double On-Demand write cost for replicated writes — factor it for globally distributed apps.
  • Batch operations count per item — 25 items in a BatchGetItem/BatchWriteItem = 25 units, not 1.
  • Steady high-volume writes favor provisioned — an IoT platform doing billions of steady writes/month should provision at high utilization and add reserved capacity.

Skip this if

  • Traffic is genuinely steady and predictable at high utilization — provisioned + DynamoDB Reserved Capacity is cheaper; On-Demand's flexibility is a premium you won't use.
  • You've already confirmed sustained utilization well above ~27% — the break-even has passed. For everything variable, bursty, low-volume, or rapidly growing, On-Demand is the default.

Run this audit with your AI assistant

Paste this into Claude, ChatGPT, or any agent that can run the AWS CLI with read-only credentials. It audits your account for exactly the waste this sheet describes — and changes nothing.

You are auditing an AWS account's DynamoDB tables to choose between
On-Demand and Provisioned capacity modes. Use the AWS CLI with READ-ONLY
credentials. Do not create, modify, or delete anything — report findings
and recommended (unapplied) fixes only.

1. Inventory: aws dynamodb list-tables + describe-table — capture
   BillingMode per table, provisioned RCU/WCU where set, and Global Table
   replicas (on-demand replicated writes cost ~2x).
2. Utilization: pull CloudWatch ConsumedRead/WriteCapacityUnits vs
   ProvisionedRead/WriteCapacityUnits over 30 days. Compute average
   utilization. Rule: sustained utilization >~27% => provisioned likely
   cheaper; bursty/low => On-Demand wins.
3. Cost math per table: On-Demand = requests/mo × ($1.25/M writes,
   $0.25/M reads). Provisioned = peak-sized RCU/WCU × hourly rate × 730.
   Show the delta and the break-even.
4. Throttling risk: flag provisioned tables with ThrottledRequests > 0
   (under-provisioned) — On-Demand removes that risk within the 40K
   RRU/WRU-per-second default table limits.

Report a table: table | mode | avg utilization % | est. On-Demand $/mo |
est. provisioned $/mo | recommendation (+ hybrid/RC note). Change
nothing.
Works with any assistant that can run shell commands.

Want the guided version?

The DynamoDB On-Demand vs Provisioned walkthrough covers this topic interactively — it asks about your setup, branches to what’s relevant, and quizzes you on the tricky parts. Free and anonymous.

Start the walkthrough