AWSCostAWS cost · DynamoDB
DynamoDB on-demand vs provisioned: which is cheaper
DynamoDB gives you two ways to pay, and the wrong one can cost several times the right one for identical traffic. On-demand charges per request and asks nothing of you - no capacity planning, no idle waste. Provisioned charges by the hour for a fixed capacity you set, which is cheaper per request but only if you keep it busy. For years the received wisdom was “provision to save,” but AWS halved on-demand pricing in late 2024 and quietly changed the answer for a lot of tables. The decision is worth revisiting.
On-demand DynamoDB charges per request with no capacity to plan; provisioned charges by the hour and is cheaper only when kept highly utilized. AWS cut on-demand pricing 50% in November 2024, so below ~35% utilization on-demand usually wins, and above ~40% provisioned does - with reserved capacity up to 75% off for steady, long-running tables.
Which mode fits which traffic?
Match the billing mode to how steady the table's traffic actually is:
| Traffic pattern | Mode | Why |
|---|---|---|
| Spiky or unpredictable | On-demand | no capacity to plan, no idle waste |
| Low or bursty (under ~35% util) | On-demand | cheaper than paying for idle capacity |
| Steady and high (over ~40% util) | Provisioned | reserved per-request cost is lower |
| Steady, predictable, long-running | Provisioned + reserved | up to 75% off with a commitment |
Why does the wrong mode cost so much more?
Because each mode is efficient only in its own lane. Put a spiky workload on provisioned and you either over-provision for the peak - paying for idle capacity most of the time - or under-provision and get throttled. Put a steady, heavy workload on on-demand and you pay the per-request premium on enormous volume. The waste is not a bad price; it is a good price applied to the wrong traffic. The 2024 on-demand cut widened on-demand's lane, which is why tables set up years ago deserve a second look.
How do I check what my tables are using?
Start with the mode each table is in today, then compare it against how steadily the table is actually used. This shows the billing mode for a table - if a steady, heavy table is on on-demand, or a spiky one is on over-provisioned capacity, that is the mismatch to fix:
# what billing mode is this table on?
aws dynamodb describe-table --table-name my-table \
--query 'Table.{Name:TableName,Mode:BillingModeSummary.BillingMode,RCU:ProvisionedThroughput.ReadCapacityUnits,WCU:ProvisionedThroughput.WriteCapacityUnits}'DynamoDB is often the data layer behind a Lambda function, so the two decisions usually sit on the same bill - worth reviewing together.
Want to know if your DynamoDB tables are on the mode that fits their traffic? Connect your account read-only and see what it is wasting, in real dollars.
The role can only read - Get, Describe, List, nothing else. Read the exact permissions before you deploy it, and delete the stack whenever you want.
Frequently asked questions
Is DynamoDB on-demand or provisioned cheaper?+
It depends on how steadily the table is used. On-demand charges per request with no capacity to plan; provisioned charges per hour for reserved capacity. Below roughly 35% sustained utilization, on-demand is usually cheaper. Above about 40%, provisioned wins - and reserved capacity on top can save up to 75%.
Did DynamoDB on-demand get cheaper?+
Yes. AWS cut on-demand throughput pricing by 50% effective November 2024, which roughly halved the gap between the two modes. Workloads that used to justify provisioned mode at 20 to 35% utilization are now often cheaper on on-demand, and AWS recommends on-demand as the default starting point.
What is the break-even between the two modes?+
Roughly speaking: below about 35% utilization of what you would otherwise provision, on-demand is cheaper; above about 40%, provisioned is. The exact crossover for a single provisioned unit sits near 14 to 15% utilization at list prices, but 35 to 40% is the practical range where the decision flips for real tables.
When should I use provisioned capacity?+
When a table's traffic is steady and predictable enough to keep provisioned capacity highly utilized - think a consistent read/write load rather than sharp spikes. At high utilization the per-request cost of provisioned is lower, and if the load is long-running, reserved capacity discounts it further.
What is DynamoDB reserved capacity?+
A 1 or 3-year commitment to a baseline of provisioned read and write capacity, in exchange for up to 75% off that capacity's rate. It only applies to provisioned mode, and only pays off when utilization is high and steady - the same logic as reserving compute.
Can I switch a DynamoDB table between modes?+
Yes, and you should when the traffic pattern changes. A table can move between on-demand and provisioned, with a cooldown between switches. Start a new or unpredictable table on on-demand, watch its real utilization, and move it to provisioned only once the load proves steady and high.
Related cost breakdowns
Why Athena is expensive: $5 per TB scanned
Athena charges $5 per terabyte scanned, so an unpartitioned CSV table can cost 10 to 100 times more than the same data as partitioned Parquet. Here is where the scan cost comes from and how to cut it.
Why RDS looks expensive - and how to right-size the instance
A low-traffic MySQL database runs fine on db.t4g.small (~$23/month), not the $100+ tier an AI often quotes. Size RDS to your working set, not your row count.
Your dev and staging RDS databases are billing 24/7
A dev database used 8 hours a day still bills for 24. Scheduling stop/start on non-production RDS saves 50 to 80%. Here is how to stop paying for databases nobody is using at night.
Multi-AZ is doubling your RDS bill - do you need it?
Multi-AZ runs a standby replica around the clock, so it roughly doubles the instance cost. Essential for production, wasteful for dev and staging. Here is how to tell, and how to fix it.