DynamoDB Capacity Modes: On-Demand vs Provisioned

Yuki's team launched a Black Friday promotion on a Friday morning. By 10am, their DynamoDB table was returning ProvisionedThroughputExceededException errors. The marketing campaign was generating 10x the read traffic they had provisioned. By the time someone bumped the capacity, they had lost two hours of orders.

This chapter is about the choice that would have prevented that — DynamoDB's two capacity modes — and how to pick between them.

The Two Modes

Every DynamoDB table runs in one of two billing modes:

• Provisioned capacity — you specify the number of read capacity units (RCUs) and write capacity units (WCUs) the table should support. AWS reserves that throughput and bills you for it, used or not;
• On-demand capacity — AWS scales the table automatically. You pay per request, no reservation required. You can switch between modes, but only once every 24 hours per table.

How Capacity Units Work

In provisioned mode, the math matters:

• 1 RCU = 1 strongly consistent read per second of an item up to 4 KB, or 2 eventually consistent reads;
• 1 WCU = 1 write per second of an item up to 1 KB;
• A transactional read costs 2 RCUs; a transactional write costs 2 WCUs. If your table needs to handle 100 strongly consistent reads per second of items averaging 8 KB, you need 200 RCUs — 100 reads at 2 units each, because the items are larger than 4 KB.

When Provisioned Wins

Provisioned mode is roughly 6.7x cheaper per request than on-demand, AWS's documentation says. It fits when:

• Traffic is predictable and steady (a SaaS app with stable usage);
• You can use auto-scaling to follow predictable daily or weekly cycles;
• You want to commit to reserved capacity for an even bigger discount (up to 50% off);
• The team is comfortable monitoring throttling and adjusting capacity. DynamoDB auto-scaling adjusts provisioned capacity based on a target utilization (default 70%). It's reactive — when traffic spikes, auto-scaling takes a few minutes to respond, which is exactly what burned Yuki's team on Black Friday.

When On-Demand Wins

On-demand mode pays for itself when:

• Traffic is unpredictable, spiky, or has large peaks (Yuki's Black Friday scenario);
• The workload is new and you have no data to size capacity from;
• The table is rarely used, where idle provisioned capacity would be wasted;
• The team prefers operational simplicity over the lowest possible bill. On-demand has no setup, no throttling under normal load (it scales instantly up to your account's table-level limits), and no monitoring overhead.

A Hybrid Pattern

Mature teams often use a hybrid approach:

• Start new tables on on-demand while traffic patterns are unknown;
• Run for a few weeks, study the access patterns in CloudWatch;
• Switch to provisioned with auto-scaling once the patterns stabilize, sized at the observed median utilization;
• Leave low-traffic tables (small lookup tables, configuration data) permanently on on-demand.

The Burst and Adaptive Capacity Helpers

Even in provisioned mode, DynamoDB tries to soften the edges:

• Burst capacity — DynamoDB reserves up to 5 minutes of unused capacity that you can spend during brief spikes;
• Adaptive capacity — when one partition is hot, DynamoDB silently borrows capacity from cooler partitions in the same table. This solves the old "hot partition" problem for most workloads, but not all. Neither helper would have saved Yuki's team — the spike was too large and too sustained. The right answer for that specific workload is on-demand mode or a pre-scaled provisioned capacity ahead of known events.

For the Exam

Two things DVA-C02 tests on capacity modes:

• The numbers — 1 RCU = 1 strongly consistent read of a 4 KB item per second (or 2 eventually consistent); 1 WCU = 1 write of a 1 KB item per second;
• The use cases — unpredictable spikes → on-demand; steady predictable load → provisioned with auto-scaling. If a question mentions Black Friday, flash sales, or "unpredictable spikes," the answer is almost always on-demand.