On-Demand vs Provisioned Capacity

~8 min read

Pay-per-request versus committing to a baseline throughput, and how Auto Scaling bridges the gap.

On-Demand capacity mode charges per actual read/write request with no capacity planning required at all — DynamoDB scales instantly to handle traffic, making it ideal for new applications with unknown traffic patterns, highly variable/spiky workloads, or teams that simply want to avoid capacity planning entirely. The tradeoff is a higher per-request cost compared to well-utilized Provisioned capacity.

Provisioned capacity mode requires you to specify Read Capacity Units (RCUs) and Write Capacity Units (WCUs) representing the throughput you're committing to and paying for, regardless of whether you fully use it — cheaper per-request if your traffic is stable and predictable enough to size accurately, but requests exceeding provisioned capacity are throttled unless Auto Scaling (which adjusts provisioned capacity within configured min/max bounds based on actual utilization) is enabled.

The general guidance: start with On-Demand for new or unpredictable workloads, and consider switching to Provisioned with Auto Scaling once traffic patterns are well understood and stable enough that the cost savings from accurate capacity commitment outweigh the operational simplicity of On-Demand.

💬 Deep Dive with AI

Key points

  • On-Demand: pay per request, zero capacity planning, higher per-request cost, best for new/unpredictable workloads
  • Provisioned: commit to RCU/WCU throughput, cheaper if well-utilized, requests beyond capacity are throttled without Auto Scaling
  • Auto Scaling adjusts Provisioned capacity automatically within configured bounds based on utilization
  • Switching between modes is limited to once per 24 hours — plan ahead rather than reactively