DynamoDB for spiky traffic: capacity mode under bursty load

Quick answer

On-demand DynamoDB charges $1.25 per million write request units and $0.25 per million read request units. Provisioned capacity charges $0.00065 per WCU-hour and $0.00013 per RCU-hour, which works out to about $0.18 per million writes and $0.018 per million eventually consistent reads only at 100 percent utilization. The break-even sits near 15 percent utilization for both. Spiky workloads often fall below it: provisioning for a peak that is more than about 7 times the average puts you under 15 percent utilization, and on-demand becomes cheaper. Auto scaling helps but reacts in minutes, so the sharper the spike, the more on-demand wins.

The DynamoDB capacity mode decision is usually presented as a volume question: small workloads take on-demand, large workloads take provisioned. That is the wrong axis. The right axis is utilization, and utilization is determined by how spiky your traffic is. A 100 million request per month table with flat traffic and a 100 million request per month table with a daily 10x spike have opposite answers.

The two rate cards

Mode	Write	Read (eventually consistent)
On-demand	$1.25 per million WRUs	$0.25 per million RRUs
Provisioned	$0.00065 per WCU-hour	$0.00013 per RCU-hour
Provisioned, fully used	~$0.18 per million writes	~$0.018 per million reads
Storage, both modes	$0.25 per GB-month

One WCU sustains one write per second, which is 3,600 writes per hour, so $0.00065 per hour is $0.18 per million writes at perfect utilization. Accounting for the fact that DynamoDB tables are rarely driven to 100 percent of provisioned throughput without throttling, a practical ceiling is around 70 to 80 percent, which puts the realistic provisioned write cost closer to $0.23 to $0.26 per million. Even so, provisioned stays cheaper per unit whenever average utilization holds above roughly 15 to 20 percent.

What spikiness does to the math

If you provision for peak, utilization equals average divided by peak. Consider a table averaging 200 writes per second with different burst shapes.

Peak-to-average	WCUs to provision	Provisioned monthly	On-demand monthly
1.2 to 1	240	$112	$648
3 to 1	600	$281	$648
5 to 1	1,000	$468	$648
10 to 1	2,000	$936	$648
20 to 1	4,000	$1,872	$648

On-demand cost is fixed at 200 writes per second average, about 518 million writes a month, at $1.25 per million. Provisioned cost rises linearly with the peak you must cover. The crossover sits close to 7 to 1, and it moves toward on-demand once you account for the safety margin most teams add.

Auto scaling closes some of the gap

Application Auto Scaling adjusts provisioned capacity toward a target utilization, commonly 70 percent. For predictable daily cycles this works well: a table that runs high for 10 hours and low for 14 can track the shape and cut provisioned cost by half or more. The limits matter, though. Scaling reacts to CloudWatch metrics, which means a response measured in minutes, and scale-down is deliberately slower than scale-up. A spike that arrives in 30 seconds is absorbed by burst capacity or throttled, not by auto scaling.

DynamoDB does retain unused capacity as burst credits for up to 300 seconds, which covers short blips. Anything longer than a five minute burst at multiples of provisioned capacity will throttle, and throttled requests mean retries, which mean more Lambda duration and eventually failed user requests. The reliability cost of under-provisioning is real and is usually worth more than the savings.

What a throttle actually costs

Under-provisioning is not free, and the cost does not appear on the DynamoDB line. A throttled request returns an error that the AWS SDK retries with exponential backoff, which extends the calling function's billed duration. A Lambda that would have finished in 60 ms can spend 2 seconds retrying a throttled write, a 33-fold increase in duration cost for that invocation. If the retries exhaust and the invocation fails, an asynchronous path retries the whole thing twice more. During a spike, thousands of functions do this simultaneously, and concurrency climbs because each invocation lives longer, which can push the account toward its concurrency limit and start failing unrelated workloads. Saving $200 a month on capacity is a bad trade against that.

Practical decision rules

Traffic pattern	Better mode
Flat, predictable, high volume	Provisioned with reserved capacity
Daily business-hours cycle	Provisioned with scheduled auto scaling
Sharp unpredictable spikes	On-demand
New workload, unknown pattern	On-demand for the first months
Development and test tables	On-demand, near zero when idle

A useful hybrid exists: you can switch capacity mode once every 24 hours. Some teams run provisioned during known steady periods and switch to on-demand ahead of an expected event such as a sale or a launch. Reserved capacity, which commits to a WCU and RCU level for one or three years at a substantial discount, only makes sense for the flat portion of demand, so buy it against the trough rather than the peak.

Finally, remember that indexes multiply everything. Each global secondary index consumes its own capacity on every relevant write, so a table with three GSIs sees roughly four times the write cost in either mode, which shifts absolute numbers but not the utilization break-even. Compare against thecapacity planning detail and price the table, indexes included, against the resource catalog before you choose a mode.

FAQ

At what utilization does provisioned DynamoDB beat on-demand?

Around 15 percent. On-demand costs $1.25 per million writes, while provisioned at $0.00065 per WCU-hour works out to about $0.18 per million writes at 100 percent utilization. Dividing those gives roughly 14.4 percent, and the same ratio holds for reads. Allowing for a realistic 70 to 80 percent operating ceiling, treat 15 to 20 percent average utilization as the practical line.

Does spiky traffic favour on-demand DynamoDB?

Yes. If you provision for peak, utilization equals average divided by peak. A table averaging 200 writes per second costs about $648 a month on-demand regardless of shape, while provisioned cost rises with the peak: about $468 at a 5 to 1 ratio, $936 at 10 to 1, and $1,872 at 20 to 1. The crossover sits close to a 7 to 1 peak-to-average ratio.

Can auto scaling make provisioned capacity work for bursts?

Partly. Application Auto Scaling tracks a target utilization, typically 70 percent, and handles predictable daily cycles well, often halving provisioned cost. But it reacts to CloudWatch metrics over minutes and scales down deliberately slowly, so a spike arriving in 30 seconds is absorbed by burst credits or throttled rather than met with new capacity.

How long does DynamoDB burst capacity last?

DynamoDB retains unused capacity as burst credits for up to 300 seconds, which covers short blips above provisioned throughput. Sustained bursts longer than five minutes at multiples of provisioned capacity will throttle, causing retries that add Lambda duration and can surface as failed user requests, which usually costs more than the capacity would have.

Should I buy DynamoDB reserved capacity for a spiky table?

Only against the trough, not the peak. Reserved capacity commits to a WCU and RCU level for one or three years at a substantial discount, which suits the flat baseline portion of demand. Buying reservations sized for peak on a bursty table locks in payment for capacity that sits unused most of the time.

How does C3X help with DynamoDB capacity mode?

C3X prices DynamoDB tables and their indexes from Terraform, so switching between on-demand and provisioned capacity, or changing provisioned levels, shows its monthly cost in the pull request. Because global secondary indexes multiply write capacity consumption, seeing the table and indexes priced together catches designs whose write cost is four times what the primary table suggests.

What to do next

Choose a capacity mode on burst shape, not guesswork. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.