DynamoDB cost optimization usually comes down to one question asked too late: should this table run On-Demand or Provisioned capacity? On-Demand is the right default for unpredictable or spiky traffic and for new tables with no load history, because you pay only for the reads and writes you make. Provisioned capacity, especially with auto scaling and reserved capacity, is materially cheaper once traffic is steady and forecastable. Most large DynamoDB bills are tables left on the wrong mode after the workload matured.
This article links up to our complete guide to AWS cost optimization, the pillar for this cluster, and complements RDS cost optimization for the relational side of the AWS data layer. DynamoDB tuning lives in the Cut step of our See, Cut, Lock, Run method.
Start new and spiky tables On-Demand. Once a table's traffic is steady and predictable, model Provisioned with auto scaling. If the table runs at consistent high utilization, Provisioned with reserved capacity is typically the cheapest option by a wide margin.
On-Demand capacity: pay per request, never idle
On-Demand mode charges for each read and write request unit with no capacity to plan or manage. It absorbs sudden spikes instantly and costs nothing when a table is quiet, which makes it ideal for new applications, unpredictable workloads, development and test tables, and anything with sharp, irregular peaks. The trade-off is unit price: each request costs more than the equivalent under well-utilized Provisioned capacity. For a table running steady, high traffic around the clock, On-Demand can cost several times what Provisioned would.
Provisioned capacity: cheaper when load is predictable
Provisioned mode reserves read and write capacity units per second at a lower per-unit price. The catch is utilization: you pay for the capacity whether or not you use it, so a table provisioned for peak and idle most of the day wastes money. Two tools fix that. Auto scaling adjusts provisioned capacity within a target utilization band as traffic moves, so you track demand instead of paying for peak continuously. Reserved capacity then commits to a baseline of capacity units for a one or three year term at a further discount, which suits the steady floor of a mature, high-traffic table.
| Workload | Best fit |
|---|---|
| New table, no traffic history | On-Demand until a pattern emerges |
| Spiky or unpredictable traffic | On-Demand |
| Steady, predictable traffic | Provisioned with auto scaling |
| Consistent high utilization | Provisioned with reserved capacity |
| Dev and test tables | On-Demand, so idle costs nothing |
Want your DynamoDB tables on the right capacity mode?
Our AWS cost audit reads per-table consumption, models On-Demand against Provisioned with auto scaling and reserved capacity, and quantifies the saving before any switch. On the performance model, you pay only from realized savings. No savings, no fee.
Book an AWS cost audit →Beyond capacity mode: storage, indexes and backups
Throughput is only part of the bill. Storage costs accumulate as tables grow, so move cold data you rarely query to the DynamoDB Standard-Infrequent Access table class, which lowers storage cost in exchange for higher request cost, ideal for tables that store a lot but read little. Global Secondary Indexes carry their own capacity and storage charges and quietly double cost when over-provisioned or rarely used, so audit every index and remove the ones queries no longer need. Point-in-time recovery and on-demand backups bill for backup storage, so set retention deliberately rather than keeping everything forever. Global Tables replicate writes across Regions and multiply write cost, so confirm each replica Region is actually needed.
Read and write efficiency
How the application uses the table matters as much as the mode. Use eventually consistent reads where the workload tolerates them, since they cost half of strongly consistent reads. Keep item sizes small, because read and write capacity is metered in fixed-size units and bloated items consume more. Batch and cache hot reads, and use Time to Live to expire stale items automatically so you stop paying to store and index data nobody reads. These habits compound with the right capacity mode rather than replacing it.
DynamoDB capacity modes, table classes and features above reflect AWS offerings as of May 2026. Verify current options and pricing in the DynamoDB console before changing production tables, as features and rates change.
The AWS Cost Optimization Field Guide includes the capacity-mode decision model and the per-table consumption queries we use to make this call. It is the downloadable companion to this guide.
The short version
For DynamoDB cost optimization, run new and spiky tables On-Demand, move steady tables to Provisioned with auto scaling, and add reserved capacity on consistently high-traffic tables. Then trim the rest of the bill: archive cold data to the Standard-IA table class, remove unused indexes, set backup retention deliberately, and use eventually consistent reads and TTL. When you want every table on the cheapest viable mode across the estate, that is what our AWS cost optimization service delivers.