Provisioned vs On-Demand Capacity

DynamoDB measures throughput in Read Capacity Units (RCUs) and Write Capacity Units (WCUs). One RCU allows one strongly consistent read per second (or two eventually consistent reads) for items up to 4 KB. One WCU allows one write per second for items up to 1 KB.

For larger items, the cost scales proportionally: a 10 KB write costs 10 WCUs; a 10 KB strongly consistent read costs 3 RCUs (ceil(10/4) = 3). Understanding capacity units is essential for estimating cost and diagnosing ProvisionedThroughputExceededException throttling errors.

In Provisioned Capacity mode, you specify the exact number of RCUs and WCUs your table should support. DynamoDB reserves that throughput and charges you for it whether or not you use it. If your application exceeds the provisioned capacity, requests are throttled and return a ProvisionedThroughputExceededException.

Provisioned mode is ideal for workloads with predictable, stable traffic. The per-unit cost is lower than On-Demand mode, and you can further reduce cost by purchasing DynamoDB Reserved Capacity (1-year or 3-year commitments at up to 76% discount).

In On-Demand mode, DynamoDB automatically scales to accommodate any traffic level without any capacity planning. You pay per request: per RRU (read request unit) and per WRU (write request unit) actually consumed. There is no provisioned capacity to manage or throttling due to provisioned limits.

On-Demand mode is ideal for: unpredictable or spiky workloads, new tables where traffic is unknown, and development/test environments with infrequent access. The per-request cost is higher than provisioned, so for stable high-throughput workloads provisioned mode is more economical.

You can switch a table between Provisioned and On-Demand mode at any time using the console or CLI. However, you can only switch modes once every 24 hours. After switching to On-Demand, the table retains the previous peak provisioned capacity as its initial throughput level, protecting against immediate throttling if traffic is already high.

A common strategy is to use On-Demand during initial launch when traffic patterns are unknown, then switch to Provisioned with Auto Scaling once traffic becomes predictable, reducing cost.

DynamoDB Auto Scaling automatically adjusts your provisioned RCUs and WCUs in response to actual traffic. You define a target utilisation percentage (e.g., 70%) and a min/max capacity range. An Application Auto Scaling policy monitors the table's consumed capacity and adjusts provisioned capacity to maintain the target utilisation.

Auto Scaling reacts to sustained traffic changes and can take a few minutes to scale up. It does not handle sudden traffic spikes well—for those, either pre-warm capacity manually or use On-Demand mode instead.

DynamoDB retains up to 5 minutes of unused provisioned capacity as burst capacity. When your table's traffic briefly exceeds the provisioned level, DynamoDB draws from the burst pool to serve the extra requests without throttling. Once the burst pool is depleted, subsequent excess requests are throttled.

Burst capacity is a short-term buffer and not a substitute for correct capacity planning. Monitor ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits CloudWatch metrics to detect when your workload is consistently consuming burst capacity and adjust provisioned throughput accordingly.

When provisioned capacity is exceeded (and burst is exhausted), DynamoDB returns ProvisionedThroughputExceededException. The AWS SDKs include built-in retry logic with exponential backoff and jitter that automatically retries throttled requests.

To diagnose throttling, check the SystemErrors and ThrottledRequests CloudWatch metrics. If specific partition keys are being throttled while overall table utilisation is low, you have a hot partition problem—redesign the partition key, add a sort key, or use write sharding.

To estimate capacity for Provisioned mode:

• Calculate peak writes per second × average item size / 1 KB (rounded up) = WCUs needed
• Calculate peak reads per second × average item size / 4 KB (rounded up) = RCUs needed (strongly consistent); halve for eventually consistent
• Add 20–30% headroom above peak to absorb spikes before burst is consumed

Example: 1,000 writes/s of 2 KB items = 2,000 WCUs. 5,000 reads/s of 8 KB items (eventually consistent) = ceil(8/4) × 5,000 / 2 = 5,000 RCUs.

DynamoDB Reserved Capacity allows you to purchase a fixed number of RCUs and WCUs for a 1-year or 3-year term, paying upfront for a significant discount (up to 76%) over On-Demand pricing. Reserved capacity applies across all provisioned tables in a Region and is automatically applied to your hourly charges.

Reserved Capacity only applies to Provisioned mode—you cannot use it with On-Demand mode. It is the best cost-saving option for stable, predictable workloads that you can confidently forecast over 1–3 years.

Use this decision guide for SAA-C03 capacity mode questions:

• On-Demand: unpredictable traffic, new application, infrequent access, bursty workload, when you want zero capacity management
• Provisioned: consistent predictable traffic, cost-sensitive, willing to manage capacity, eligibility for Reserved Capacity discounts
• Provisioned + Auto Scaling: predictable baseline with some variability, want automatic adjustment without manual changes

On the exam, keywords like 'spiky', 'unpredictable', or 'minimal operational overhead' signal On-Demand; 'steady traffic' or 'cost optimisation' signal Provisioned.

DynamoDB Adaptive Capacity automatically redistributes throughput from cold partitions to hot partitions in real time. If one partition key is receiving more traffic than its allocated share, adaptive capacity borrows throughput from under-utilised partitions to accommodate the hot one—as long as total table capacity is not exceeded.

Adaptive capacity is always enabled and requires no configuration. It reduces hot partition throttling for moderately uneven access patterns. For severely skewed workloads (e.g., one partition key receives 90% of traffic), adaptive capacity is not sufficient—you must redesign the partition key or use write sharding.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Provisioned mode sets fixed RCUs/WCUs for predictable workloads at lower cost, On-Demand mode scales automatically for unpredictable traffic at a higher per-request price, and Auto Scaling adjusts provisioned capacity based on target utilisation percentages. Next up we explore Global Secondary Indexes and Local Secondary Indexes for alternate query patterns.