DynamoDB On-Demand vs Provisioned Auto Scaling for Bursty Reads Under a Cost Ceiling

Question

Goal
Select a DynamoDB capacity mode for a table serving bursty read traffic while staying under a fixed monthly cost ceiling.

On-demand mode bills per request and requires no capacity planning, which fits unpredictable spikes. Provisioned mode with Application Auto Scaling sets read capacity units and a target utilization, usually lowering the cost per request at steady load. However, auto scaling responds to CloudWatch metrics and is not instantaneous, so a sudden burst can exceed provisioned capacity before scaling completes and throttle reads. Adaptive capacity can distribute traffic across partitions but does not remove per-partition limits or guarantee burst absorption. A table uses one capacity mode for all operations, so on-demand and provisioned cannot be mixed per request.

Because on-demand can cost significantly more at high steady throughput, the right mode depends on expected request volume and burst shape. Auto scaling target utilization and cooldown behavior are AWS-managed defaults and may change without notice.

Which capacity mode minimizes throttling risk for bursty reads while remaining under the cost ceiling? Should the table default to on-demand to absorb unpredictable spikes, or provisioned capacity with a conservative target utilization to control steady-state cost?

Wasi · Answer

Direct AnswerDefault to on-demand capacity mode if minimizing throttling risk for bursty reads is the priority and the projected monthly bill fits under your cost ceiling. On-demand has no provisioned capacity to exhaust, so it absorbs sudden spikes without the scale-up lag that affects provisioned tables. Provisioned capacity with Application Auto Scaling can lower costs at steady load, but it does not guarantee burst absorption; reads can still throttle while CloudWatch metrics propagate and new capacity is added.Confirmed Facts vs. Likely ExplanationConfirmed behavior:A DynamoDB table uses exactly one capacity mode. On-demand and provisioned cannot be mixed per request.On-demand bills per request and requires no capacity planning.Provisioned mode requires read capacity units (RCUs). Application Auto Scaling adjusts capacity based on CloudWatch metrics, which introduces a non-instantaneous delay.Adaptive capacity redistributes traffic across partitions, but it does not remove per-partition throughput limits or guarantee instant burst absorption.Likely cost trade-off:Provisioned capacity with auto scaling tends to be cheaper per request at sustained, predictable load.On-demand can cost significantly more at high sustained throughput and may breach a fixed monthly ceiling if volume is large.FactorOn-DemandProvisioned + Auto ScalingThrottling during sudden burstNone from capacity exhaustionPossible during scale-up lagSteady-state costHigher per requestLower per requestPlanning overheadNoneRequires RCU and target utilization tuningPer-partition burst handlingAdaptive capacity still appliesAdaptive capacity still appliesSteps for This CaseInspect current settings. Check the table's capacity mode and any existing Application Auto Scaling policies in the DynamoDB console.Quantify traffic shape. Review CloudWatch metrics ReadThrottleEvents, ConsumedReadCapacityUnits, and ProvisionedReadCapacityUnits to separate sustained baseline from peak burst demand.Model both modes. Estimate monthly cost using historical request counts and average item size. Compare on-demand per-request pricing against provisioned RCU pricing plus auto scaling headroom.Validate with a load test. If the decision is close, run a controlled test that mimics the expected burst shape and observe throttling and cost impact before committing.Decision Input NeededThe recommendation flips based on one diagnostic detail: what is your numeric monthly cost ceiling, and what is the ratio of peak to sustained read throughput? If peak reads are only modestly above baseline and the ceiling allows provisioned headroom, auto scaling may be affordable. If bursts are many times the sustained rate, provisioned capacity would need expensive standby headroom to avoid throttling, making on-demand the safer choice under the ceiling.

DynamoDB On-Demand vs Provisioned Auto Scaling for Bursty Reads Under a Cost Ceiling

Goal

1 answer

Direct Answer

Confirmed Facts vs. Likely Explanation

Steps for This Case

Decision Input Needed

Your perspective belongs here.

0 question comments

Factor	On-Demand	Provisioned + Auto Scaling
Throttling during sudden burst	None from capacity exhaustion	Possible during scale-up lag
Steady-state cost	Higher per request	Lower per request
Planning overhead	None	Requires RCU and target utilization tuning
Per-partition burst handling	Adaptive capacity still applies	Adaptive capacity still applies