DynamoDB on-demand vs provisioned: the 29% utilization threshold

Published September 18, 2026

When AWS launched DynamoDB on-demand capacity in 2018, it solved one of the most frustrating operational problems in managed databases: guessing how many read and write capacity units to provision before traffic arrived. On-demand mode handles spikes without manual scaling policies, absorbs traffic dips to zero, and charges only for the requests you actually execute.

That flexibility comes with a steep premium. In us-east-1, on-demand capacity bills at $0.625 per million write request units and $0.125 per million read request units. Provisioned capacity bills at $0.00065 per WCU-hour and $0.00013 per RCU-hour.

Translate those hourly rates into monthly request volume and a clear rule emerges: if your application averages more than 28.89% utilization of its provisioned capacity across the month, on-demand costs more than provisioned. The gap widens as utilization drops. At full utilization on-demand is a 246% markup; at 50% utilization it is 592%.

The unit math

Both capacity modes measure work using the same base request definitions:

• 1 Write Capacity Unit (WCU) or 1 Write Request Unit (WRU) covers one standard write up to 1 KB of data.
• 1 Read Capacity Unit (RCU) or 1 Read Request Unit (RRU) covers one strongly consistent read up to 4 KB of data, or two eventually consistent reads up to 4 KB each.
• Transactional operations consume 2 units per write or read.

The divergence is how AWS meters and bills those units:

One provisioned WCU delivers one 1 KB write every second. Using the 730-hour month this site standardizes on (see methodology), a month contains 2,628,000 seconds. A single WCU running all month can process up to 2,628,000 writes for a flat cost of $0.4745.

To process that identical volume of 2,628,000 writes on on-demand mode:

2,628,000 writes × $0.000000625 = $1.64

The crossover point where provisioned and on-demand spend meet:

Breakeven utilization = $0.4745 ÷ $1.64 = 28.89%

The arithmetic for reads works out to the same ratio:

• 1 RCU for 730 hours = $0.0949
• 2,628,000 reads on on-demand = 2,628,000 × $0.000000125 = $0.33
• Breakeven utilization = $0.0949 ÷ $0.33 = 28.89%

If your traffic profile consumes more than 29% of the provisioned ceiling over the billing period, provisioned capacity is cheaper. If average utilization sits below 29%, on-demand saves money.

Monthly cost comparison at scale

To see how that 29% threshold operates in practice, consider a table sustaining an average of 500 writes per second and 2,500 reads per second (strongly consistent), with a peak of 1,000 writes/sec and 5,000 reads/sec.

Over 30 days at 730 hours, that table handles 1.31 billion writes and 6.57 billion reads.

Even with static provisioning sized permanently to handle the peak, a setup with 50% idle capacity, provisioned mode saves $693.50 per month, a 42% reduction.

With standard Application Auto Scaling targeting 70% utilization, total request fees drop from $1,642.50 to $677.86 per month, cutting the bill by 59%.

Why teams stay on on-demand

If provisioned capacity saves 40% to 70% on predictable workloads, why do so many production tables remain on on-demand?

Three technical constraints drive this behavior:

1. Spiky traffic and auto-scaling lag

DynamoDB auto-scaling relies on CloudWatch metrics and alarm evaluation periods. When a burst of traffic arrives, auto-scaling typically takes 10 to 15 minutes to adjust provisioned capacity upwards. If the spike is sudden (such as a flash sale, push notification blast, or batch job trigger), requests exceed provisioned limits and DynamoDB returns ProvisionedThroughputExceededException. On-demand mode handles instant traffic surges up to double the previous peak with zero delay and no throttling.

2. The partition throttling problem

Provisioned throughput is divided evenly across all underlying physical partitions in the table. If a table has 10 partitions and 1,000 provisioned WCUs, each partition receives 100 WCUs. A hot partition key exceeding 100 writes per second can throttle even when overall table utilization sits at 15%. On-demand mode adapts more forgivingly to hot partitions because partition allocation adapts dynamically to instantaneous demand.

3. Idle development and testing environments

For staging environments, internal tools, and secondary microservices where traffic drops to zero overnight or over weekends, average utilization rarely reaches 5%. Paying $0.4745 per WCU and $0.0949 per RCU every month for idle tables produces unnecessary waste. On-demand mode drops table costs to pure storage ($0.25 per GB-month).

Standard vs Standard-IA: the storage trade-off

Table spend is not just requests; storage plays an equally large role once datasets grow beyond a few hundred gigabytes.

In our DynamoDB pricing data, AWS offers two table classes:

• DynamoDB Standard: $0.25 per GB-month storage
• DynamoDB Standard-Infrequent Access (Standard-IA): $0.10 per GB-month storage (a 60% discount)

Standard-IA reduces storage costs by $0.15 per GB-month, but it increases throughput pricing by roughly 25%:

The decision to switch a table to Standard-IA depends on the ratio of storage spend to throughput spend.

Monthly storage savings = Table size in GB × $0.15
Throughput surcharge = Current throughput spend × 0.25

Standard-IA breaks even when:

Table size in GB × $0.15 > Current throughput spend × 0.25

Simplifying that inequality:

Monthly throughput spend < Table size in GB × $0.60

Consider a 5 TB table (5,000 GB) storing audit logs or historical order data:

• Standard storage cost: 5,000 × $0.25 = $1,250.00/month
• Standard-IA storage cost: 5,000 × $0.10 = $500.00/month
• Monthly storage savings: $750.00/month

That 5 TB table saves money on Standard-IA as long as its monthly throughput spend stays below $3,000. For logging tables, event stores, and user archive profiles with low read/write frequencies, Standard-IA gives an immediate 40% to 55% cut in total DynamoDB costs.

Reserved capacity and the 29% threshold

For provisioned workloads running year-round, DynamoDB offers 1-year and 3-year Reserved Capacity. Unlike EC2 Reserved Instances, which apply to whole virtual machines, DynamoDB reservations apply directly to provisioned capacity units, in blocks of 100 WCUs or 100 RCUs.

Reserved rates are not in our dataset. The DynamoDB pricing data we publish covers on-demand and provisioned consumption only, because that is what the AWS Price List API returns for the DynamoDB offer file. AWS currently advertises 1-year reservations at roughly 50% off on-demand capacity rates and 3-year reservations at around 70% off, but treat those as figures to confirm against your own AWS quote rather than numbers we have verified.

If you do hold a 1-year reservation, the breakeven shifts down by the same proportion. At a 50% discount a WCU costs $0.237 a month, so:

Reserved breakeven utilization = $0.237 ÷ $1.64 = 14.5%

That is the one number worth carrying: reservations do not change the shape of the decision, they move the threshold. A workload at 20% utilization is on the wrong side of on-demand today, and crosses to provisioned once you commit a year.

Practical rules for capacity selection

Use this checklist when evaluating your tables:

1. New services with unknown traffic: Start on on-demand. Observe the CloudWatch ConsumedWriteCapacityUnits and ConsumedReadCapacityUnits metrics for 30 to 60 days to map the baseline and peak ratio.
2. Steady workloads with average utilization over 30%: Switch to provisioned capacity with Application Auto Scaling set to 70% target utilization. Configure minimum capacity to handle baseline traffic and maximum capacity to cover expected daily peaks.
3. Spiky workloads with sharp 10x spikes in seconds: Stay on on-demand, or use provisioned capacity with a generous base plus auto-scaling and pre-warming scripts if peaks are scheduled.
4. Storage-heavy tables where storage exceeds 50% of the bill: Switch the table class from DynamoDB Standard to DynamoDB Standard-IA.
5. High-scale core tables running year-round: If a table’s utilization sits near or below the threshold and you can commit, price a 1-year reservation against your own quote. Reservations move the breakeven point down proportionally without changing which mode is right.