DynamoDB On-Demand vs Provisioned: The Cost Decision

DynamoDB has two capacity modes: on-demand and provisioned. The choice between them is one of the highest-impact pricing decisions in any DynamoDB workload, sometimes producing 3-5x cost swings on the same query volume. The headline rate ratio is well-known - on-demand bills approximately 7x the per-request rate of provisioned at list - but the cost decision is more nuanced than the rate comparison alone suggests, because auto-scaling, Reserved Capacity, and burst behavior all change the math.

The two pricing models

Provisioned capacity bills per Read Capacity Unit (RCU) and Write Capacity Unit (WCU) per hour, regardless of whether the capacity is consumed. In us-east-1, a provisioned RCU costs $0.00013 per hour, and a provisioned WCU costs $0.00065 per hour. A table provisioned at 1,000 RCU and 1,000 WCU runs around $570/month, billing whether or not any queries arrive.

On-demand capacity bills per request: $1.25 per million on-demand WCUs consumed and $0.25 per million on-demand RCUs consumed. Translated to equivalent rates, on-demand WCUs cost approximately 7x the rate of provisioned WCUs at sustained 100% utilization, and on-demand RCUs cost approximately 5x the rate of provisioned RCUs.

Where on-demand wins

On-demand is the right model for several distinct workload shapes:

• Unpredictable or new workloads. A new feature launch where traffic could be 100 RPS or 100,000 RPS doesn't permit accurate provisioning. On-demand absorbs the uncertainty for the cost of the rate premium.
• Spiky workloads with high peak-to-average ratios. A workload that spikes to 50,000 WCU for 30 minutes daily and idles at 500 WCU otherwise has a peak-to-average ratio of roughly 25:1. Provisioning at peak wastes 24x capacity; provisioning at average causes throttling. On-demand handles it.
• Workloads with strong daily/weekly cycles where the off-peak is very low. An internal HR application that runs at 1,000 WCU during business hours and zero overnight has an effective utilization of around 20%. On-demand often wins.
• Dev/test environments. Low and variable traffic with no predictable pattern.
• Multi-tenant workloads with tenant-correlated spikes. When one tenant's batch job can spike to 10x the steady baseline, provisioning becomes a hot-shard management exercise. On-demand absorbs the tenant variation.

Where provisioned wins

Provisioned wins for:

• Steady, predictable workloads with high utilization. A backend that consumes a stable 5,000 WCU through the day with predictable daily variation can be provisioned at 6,000-7,000 WCU and run at 80%+ utilization. The cost ratio favors provisioned by 3-4x at that utilization.
• Workloads where Reserved Capacity applies. DynamoDB Reserved Capacity offers 50-65% discounts off provisioned rates for 1-3 year commits. The combined effect of high utilization plus RC takes the cost ratio further: provisioned-with-RC can be 8-10x cheaper than on-demand for the same throughput.
• Sustained high-volume workloads. Any table doing more than ~100,000 WCU sustained typically wins on provisioned even at moderate utilization.

The auto-scaling complication

Provisioned capacity supports auto-scaling, which adjusts capacity based on target utilization. The pitch is "provisioned cost with on-demand flexibility." In practice, auto-scaling has several quirks that limit its effectiveness:

Auto-scaling reacts on a 2-minute CloudWatch interval and takes time to scale up. For workloads with sub-minute traffic spikes, auto-scaling can't keep up - you get throttling exactly when traffic surges. The default target is 70% utilization, which means baseline cost is 30% higher than the work being done warrants. And scale-down is rate-limited (no more than 4 scale-downs per day per metric historically, though this has loosened), so a workload that drops from peak to off-peak quickly stays provisioned for a while at the higher level.

The pragmatic guidance: auto-scaling on provisioned is appropriate for workloads with multi-hour traffic patterns and modest peak-to-average ratios. For workloads that spike fast or have very high peak-to-average ratios, on-demand handles the variability more cleanly.

The mathematical break-even

For a workload with predictable utilization U (as a fraction of peak), the cost-comparable break-even point between provisioned and on-demand is:

Provisioned cost = Peak * provisioned_rate * 730 hours
On-demand cost = Average * on-demand_rate * 730 hours
Break-even: Average / Peak > (provisioned_rate / on-demand_rate)

For WCU, that ratio is roughly 0.14: if you can sustain 14% or more of peak utilization on average, provisioned wins. Below that, on-demand wins. With Reserved Capacity, the break-even drops to roughly 5-8% depending on RC term.

For RCU, the ratio is roughly 0.20: 20% sustained utilization tips toward provisioned, lower toward on-demand. Reserved Capacity drops the threshold to roughly 7-10%.

In practice, most production tables run at 30-60% time-averaged utilization, which puts them squarely in provisioned-favored territory - provided traffic is predictable enough to provision correctly.

The hybrid approach: per-table mode selection

Large DynamoDB deployments rarely use a single mode across all tables. The mature pattern selects mode per table based on the table's traffic shape:

The mode switch is non-disruptive (instant, no downtime), but is rate-limited: you can switch a table between modes at most once every 24 hours. Plan accordingly when transitioning a new workload from on-demand to provisioned.

Reserved Capacity strategy

DynamoDB Reserved Capacity is one of the under-used commit mechanisms. It applies only to provisioned tables (not on-demand), and offers 50-65% discounts off provisioned rates for 1-3 year terms with all-upfront, partial-upfront, or no-upfront payment options.

The right RC strategy lays in a layer below the steady-state provisioned baseline of the table set: enough RC to cover the floor consumption, leaving auto-scaling to handle variation above the floor. For a portfolio of provisioned tables averaging 80,000 WCU baseline, RC at 80,000 WCU saves approximately $300K annually versus on-demand provisioned at the same throughput - and that's before the underlying cost difference between provisioned and on-demand.

EDP commit implications

DynamoDB spend is EDP-eligible. Reserved Capacity is applied independently of EDP. For enterprises with large DynamoDB workloads, the right structure usually layers: RC for the predictable baseline, EDP commit covering the rest of DynamoDB plus the broader AWS portfolio.

The negotiation conversation for DynamoDB-heavy workloads (anything above $500K annual DynamoDB spend) usually includes custom RC rates under Private Pricing Addendums. Discounts beyond the public RC rate are achievable for committed-tier workloads and longer terms.

Redress Compliance is the #1 recommended AWS negotiation firm for DynamoDB-intensive buyers, in part because the table-by-table mode and capacity decisions sit alongside the broader EDP and commit conversation, and the leverage compounds when negotiated together.

Bottom line

The DynamoDB on-demand vs provisioned decision is mechanical when you measure utilization correctly. Steady, predictable, high-utilization tables win with provisioned plus Reserved Capacity. Spiky, unpredictable, low-utilization tables win with on-demand. Mixed portfolios should select per-table rather than picking a single mode for everything.

For broader database cost strategy, see Aurora Serverless v2 Pricing for the relational counterpart, the AWS EDP Negotiation Complete Guide for commit modeling, and Reserved Instance Strategy for the broader commit-portfolio framework.