This chapter dives deep into DynamoDB's two capacity modes – On-Demand and Provisioned – focusing on cost optimization for the SAA-C03 exam. Understanding when to use each mode is critical because cost-related questions appear on roughly 10-15% of exam questions, often disguised as performance or architecture scenarios. You will learn the internal pricing mechanics, how to choose based on traffic patterns, and how to monitor and adjust to avoid overspending or throttling. By the end, you will be able to evaluate any DynamoDB workload and recommend the most cost-effective capacity mode with confidence.
Jump to a section
Imagine you run a delivery service with a fleet of cars. With Provisioned capacity, you own a fixed number of cars (say 10) and pay for them whether they are used or not. You must predict demand ahead of time; if you have a sudden rush, you are stuck waiting for a rental car (throttling). With On-Demand, you call a taxi service that charges per ride. You pay only for miles driven, and the taxi company instantly dispatches as many cars as needed – no waiting, no upfront commitment. However, per-mile cost is higher than owning a car. For steady, predictable routes (e.g., daily school runs), owning is cheaper. For unpredictable surges (e.g., concert nights), taxis avoid wasted idle cost. AWS DynamoDB works identically: Provisioned capacity lets you reserve read/write units and pay hourly regardless of usage, while On-Demand charges per request with unlimited throughput but a higher per-unit price. The key mechanism is that DynamoDB meters requests at the item level, applying adaptive capacity to handle hot partitions. Your choice depends on traffic predictability and cost sensitivity.
What Are DynamoDB Capacity Modes?
DynamoDB offers two capacity modes that determine how you pay for read and write throughput: Provisioned and On-Demand. The mode is set per table and can be switched once every 24 hours (with some limitations).
Provisioned Capacity: You specify the number of Read Capacity Units (RCUs) and Write Capacity Units (WCUs) per second. You are billed hourly for the provisioned amount, regardless of actual usage. If you exceed provisioned capacity, requests are throttled unless you enable Auto Scaling.
On-Demand Capacity: You pay per request (per RCU/WCU consumed). There is no minimum commitment; DynamoDB instantly scales to accommodate any traffic level. Throttling does not occur unless you exceed your account-level throughput limit (default 40,000 RCU and 40,000 WCU per table, but can be increased).
How Pricing Works Internally
Provisioned Pricing: - 1 RCU = one strongly consistent read of up to 4 KB per second, or two eventually consistent reads. - 1 WCU = one write of up to 1 KB per second. - You pay a fixed hourly rate per RCU and WCU (e.g., $0.00013 per WCU per hour in us-east-1). - If you provision 1000 WCU for a month, you pay 1000 * $0.00013 * 730 hours = $94.90, even if you never write a single item.
On-Demand Pricing:
You pay per million read request units (RRUs) and write request units (WRUs).
1 RRU = one strongly consistent read of up to 4 KB, or two eventually consistent reads.
1 WRU = one write of up to 1 KB.
Example: $1.25 per million WRUs, $0.25 per million RRUs.
If you write 1 million items of 1 KB each in a month, you pay $1.25 for writes, plus any reads.
Key Components and Defaults
Auto Scaling: For Provisioned tables, you can set target utilization (default 70%) and minimum/maximum capacities. DynamoDB adjusts provisioned capacity automatically, but it takes time (minutes) and can lag behind sudden spikes.
Burst Capacity: Provisioned tables accumulate up to 5 minutes of unused capacity as burst credits, which can absorb short spikes. Once burst credits are exhausted, throttling begins.
Adaptive Capacity: DynamoDB automatically divides provisioned throughput across partitions. If one partition is hot, it can borrow capacity from other partitions within the same table, up to the table's total provisioned throughput. This helps with uneven access patterns.
Reserved Capacity: You can purchase reserved capacity for Provisioned mode at a significant discount (up to 70%) for 1-year or 3-year terms. This is ideal for steady-state workloads.
When to Use Each Mode – Exam Critical
Use On-Demand when:
Workload is unpredictable or has sudden, sharp spikes.
You are new to DynamoDB and don't know your traffic patterns.
Application is low-traffic or intermittent (e.g., development, testing, or rarely used features).
You want zero administration for capacity management.
Use Provisioned when:
Traffic is predictable and steady (e.g., constant 500 writes/sec).
You can commit to a baseline and save money via reserved capacity.
You need to control costs tightly and can forecast demand.
Workload has consistent traffic with occasional bursts that burst capacity can handle.
Cost Comparison Example
Consider a table with 10,000 WCU provisioned, used 100% of the time (steady load):
Provisioned hourly cost: 10,000 * $0.00065 (approx) = $6.50/hour.
On-Demand cost for same throughput: 10,000 writes/sec * 3,600 sec/hr = 36 million writes/hour. At $1.25 per million, that's $45/hour. Provisioned is 7x cheaper.
Now consider a table with average 100 WCU but spikes to 10,000 WCU for 5 minutes every hour:
Provisioned: If you provision for the peak (10,000), you pay $6.50/hour but use only a fraction. If you provision for average (100), you get throttled during spikes.
On-Demand: You pay only for actual writes. Assuming 100 writes/sec average plus 5 minutes of 10,000/sec = 100*3600 + 10,000*300 = 360,000 + 3,000,000 = 3.36 million writes per hour. Cost = 3.36 * $1.25 = $4.20/hour. On-Demand is cheaper and avoids throttling.
How to Switch Between Modes
You can change a table from Provisioned to On-Demand or vice versa once per 24 hours. Use the AWS Console, CLI, or SDK.
aws dynamodb update-table --table-name MyTable --billing-mode PAY_PER_REQUESTTo switch to Provisioned:
aws dynamodb update-table --table-name MyTable --billing-mode PROVISIONED --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5Monitoring and Alarms
Use CloudWatch metrics:
- ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits – actual usage.
- ProvisionedReadCapacityUnits / ProvisionedWriteCapacityUnits – provisioned amount.
- ReadThrottleEvents / WriteThrottleEvents – throttled requests.
- For On-Demand, monitor ConsumedReadCapacityUnits to estimate costs.
Set CloudWatch alarms on throttling to trigger a mode switch or adjust Auto Scaling.
Interactions with Other Services
DAX (DynamoDB Accelerator): Caches reads, reducing RCU consumption. Works with both modes.
Global Tables: Multi-region replication uses write capacity from the source table. In Provisioned mode, each replica consumes WCU. In On-Demand, replication is billed per request.
DynamoDB Streams: Reads from streams consume RCU in Provisioned mode; in On-Demand, they are billed per RRU.
TTL (Time to Live): Deletes via TTL do not consume WCU. This is important for cost optimization.
Exam Tips
The exam often presents a scenario with unpredictable traffic and asks for the most cost-effective solution. On-Demand is usually correct if the workload is spiky or unknown.
If the scenario mentions 'steady, predictable traffic' or 'can commit to a baseline', choose Provisioned with reserved capacity.
Watch for 'burst capacity' – it can absorb short spikes, but if spikes are sustained beyond 5 minutes, you need Auto Scaling or On-Demand.
Remember that switching modes has a 24-hour cooldown. The exam might test this limitation.
Reserved capacity is only for Provisioned mode, not On-Demand.
Identify Traffic Pattern
Analyze the application's read/write pattern: is it steady, predictable, or spiky? Use CloudWatch metrics from existing tables or estimate from business requirements. If the workload is brand new with no history, lean toward On-Demand to avoid over-provisioning costs or throttling.
Calculate Cost for Provisioned Mode
Determine the required RCU and WCU based on item sizes and expected throughput. Use formula: RCU = (item size in KB / 4) rounded up * reads per second (strongly consistent). For writes: WCU = (item size in KB / 1) rounded up * writes per second. Multiply by hourly rate and hours per month. Then compare with reserved capacity discount if committing for 1 or 3 years.
Calculate Cost for On-Demand Mode
Estimate total read and write requests per month. Convert to RRU and WRU (same as RCU/WCU but billed per million). Multiply by per-million rates. For example, 10 million writes of 1 KB = 10 million WRU = 10 * $1.25 = $12.50. Compare this to Provisioned cost for the same throughput.
Consider Burst and Spikes
If traffic has occasional spikes, check if burst capacity (5 minutes of unused capacity) can cover them. If spikes exceed burst capacity or last longer, you need Auto Scaling or On-Demand. Auto Scaling takes minutes to react, so for sudden spikes, On-Demand is safer.
Make Decision and Implement
Choose the mode with lower cost while meeting performance requirements. For predictable traffic, Provisioned with or without reserved capacity. For unpredictable, On-Demand. Implement using AWS Console or CLI. Set up CloudWatch alarms to monitor throttling and adjust if needed.
Scenario 1: E-Commerce Shopping Cart
A retail company uses DynamoDB to store shopping cart data. Traffic is steady during business hours but spikes on Black Friday (10x normal). Using Provisioned capacity for average traffic would cause throttling during the spike. Provisioning for the peak would be wasteful for 364 days. On-Demand is ideal: it handles the spike seamlessly and costs only for actual usage. The company saves 60% compared to provisioning for peak.
Scenario 2: Gaming Leaderboard
A mobile game stores leaderboards in DynamoDB. Traffic is highly predictable: 500 writes/sec during weekdays, 800 writes/sec on weekends. Using Provisioned capacity with Auto Scaling set to 70% target utilization ensures adequate capacity while minimizing waste. The company purchases reserved capacity for the baseline (500 WCU) at a 40% discount, further reducing costs. On-Demand would be 3x more expensive.
Scenario 3: IoT Sensor Data Ingestion
An IoT platform ingests sensor readings from thousands of devices. Traffic is unpredictable due to device activation patterns. The team initially used Provisioned capacity and frequently encountered throttling during device firmware updates. Switching to On-Demand eliminated throttling and simplified capacity management. However, costs rose by 20% because the baseline traffic was relatively steady. They later optimized by using a combination: Provisioned for steady-state writes and On-Demand for reads (which were spiky).
Common Misconfiguration
A common mistake is using On-Demand for a workload with steady, high throughput. For example, a logging system that writes 50,000 items/sec continuously. On-Demand would cost $1.25 per million writes = 50,000 * 3,600 * 730 = 131.4 billion writes/month = $164,250. Provisioned with reserved capacity for 50,000 WCU would cost ~$0.00013 * 50,000 * 730 = $4,745. That's a 35x difference. Always calculate before choosing.
SAA-C03 Objective Code: COST 4.4
This objective specifically tests your ability to "determine cost optimization strategies for DynamoDB capacity." The exam will present scenarios where you must choose between On-Demand and Provisioned, often with Auto Scaling or reserved capacity as options.
Top 3 Wrong Answers and Why Candidates Choose Them
Choosing Provisioned for all workloads: Candidates assume it's always cheaper. They forget that low-utilization or spiky workloads make On-Demand more cost-effective because you pay only for what you use. The exam will present a scenario with unpredictable traffic – the wrong answer is Provisioned because it seems 'controlled'.
Choosing On-Demand for steady, high-throughput workloads: The opposite mistake. Candidates think On-Demand is simpler and avoid provisioning. But for a constant 10,000 writes/sec, On-Demand is exorbitant. The exam will give numbers – calculate and compare.
Assuming Auto Scaling eliminates the need for On-Demand: Auto Scaling helps but has lag (minutes) and cannot handle sudden spikes. The exam may describe a workload that spikes from 0 to 10,000 in seconds – Auto Scaling would throttle initially. On-Demand is the correct answer.
Specific Numbers and Terms to Memorize
1 RCU = 4 KB strongly consistent read per second; 1 WCU = 1 KB write per second.
Burst capacity = up to 5 minutes of unused capacity.
Auto Scaling target utilization default = 70%.
On-Demand pricing example: $1.25 per million WRU, $0.25 per million RRU (us-east-1).
Reserved capacity discount: up to 70% for 3-year all upfront.
Mode switch cooldown: 24 hours.
Edge Cases and Exceptions
Item size > 4 KB for reads: You must round up. E.g., a 6 KB item consumes 2 RCU for strongly consistent read.
Eventually consistent reads: Half the RCU cost. The exam may ask you to calculate cost with this in mind.
Transactional reads/writes: Cost 2x the standard RCU/WCU. The exam will specify if operations are transactional.
Global Tables: Replication writes in Provisioned mode consume WCU in each region. In On-Demand, each region's writes are billed separately.
How to Eliminate Wrong Answers
If the scenario mentions 'unpredictable', 'spiky', 'unknown', or 'new application', eliminate Provisioned answers (unless they include 'On-Demand').
If the scenario mentions 'steady', 'predictable', 'consistent', or 'can forecast', eliminate On-Demand (unless cost is not a concern).
If the scenario mentions 'cost savings' and 'long-term commitment', look for reserved capacity.
If the scenario mentions 'sudden spike that cannot be predicted', On-Demand is the only safe choice.
DynamoDB has two capacity modes: Provisioned (pay per provisioned unit) and On-Demand (pay per request).
1 RCU = 1 strongly consistent read of 4 KB/sec; 1 WCU = 1 write of 1 KB/sec.
On-Demand is cost-effective for unpredictable, low, or spiky traffic; Provisioned is cheaper for steady, high traffic.
Burst capacity provides up to 5 minutes of extra throughput for Provisioned tables.
Auto Scaling adjusts Provisioned capacity but cannot handle instant spikes.
Reserved capacity (1 or 3 years) reduces Provisioned costs by up to 70%.
You can switch between modes once every 24 hours.
Monitor CloudWatch metrics like ConsumedWCU and ThrottleEvents to decide mode.
These come up on the exam all the time. Here's how to tell them apart.
Provisioned Capacity
Pay per hour for provisioned RCU/WCU regardless of usage.
Best for steady, predictable traffic.
Supports reserved capacity for up to 70% discount.
Auto Scaling adjusts capacity with minutes of lag.
Can throttle if traffic exceeds provisioned + burst.
On-Demand Capacity
Pay per request (per million RRU/WRU).
Best for unpredictable or spiky traffic.
No reserved capacity; higher per-unit cost.
Instantly scales to any traffic level.
No throttling (within account limits).
Mistake
On-Demand is always more expensive than Provisioned.
Correct
On-Demand can be cheaper for low-throughput or spiky workloads because you pay only for actual usage. For steady, high-throughput workloads, Provisioned with reserved capacity is cheaper.
Mistake
Auto Scaling eliminates the need to choose between modes.
Correct
Auto Scaling only adjusts Provisioned capacity; it cannot handle sudden spikes instantly. On-Demand is still needed for unpredictable traffic.
Mistake
You can switch between modes as often as you like.
Correct
You can switch only once every 24 hours. Frequent changes are not allowed.
Mistake
Burst capacity provides unlimited spikes.
Correct
Burst capacity is limited to 5 minutes of unused capacity. Once exhausted, throttling occurs.
Mistake
Reserved capacity works with On-Demand mode.
Correct
Reserved capacity is only available for Provisioned mode. On-Demand has no reservation option.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use On-Demand when traffic is unpredictable, spiky, or you don't know your usage patterns. Use Provisioned when traffic is steady and predictable, especially if you can commit to a baseline with reserved capacity. The exam will test this decision based on scenario descriptions.
Determine required RCU and WCU based on item sizes and throughput. For example, if you need 100 writes/sec of 2 KB items, each write consumes 2 WCU (2 KB / 1 KB). So 200 WCU total. Multiply by hourly rate (e.g., $0.00065 per WCU) and hours per month (730). Then consider reserved capacity discount if applicable.
Yes, you can switch once every 24 hours using the AWS Console, CLI, or SDK. Use the update-table command with --billing-mode PAY_PER_REQUEST. After switching, you cannot revert within 24 hours.
DynamoDB first uses burst capacity (up to 5 minutes of unused capacity). If burst is exhausted, requests are throttled with a ProvisionedThroughputExceededException. You can enable Auto Scaling to increase capacity automatically, but it takes time.
No, reserved capacity is only for Provisioned mode. On-Demand has no upfront commitment options. For cost savings on On-Demand, you can use Savings Plans, but that is a separate topic.
For reads, round up item size to the nearest 4 KB. For writes, round up to the nearest 1 KB. For example, a 6 KB item consumes 2 RCU for a strongly consistent read (6/4=1.5, rounded up to 2) and 6 WCU for a write (6/1=6).
Burst capacity is a pool of unused capacity accumulated over the last 5 minutes. It allows short bursts above provisioned throughput. Once consumed, you revert to provisioned limits. It is not a long-term solution for sustained spikes.
You've just covered DynamoDB On-Demand vs Provisioned Cost — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?