What if your database could pay only for what it actually uses, no more, no less?
On-demand vs provisioned cost comparison in DynamoDB - When to Use Which
Imagine running a small online store and trying to guess how many customers will visit each day. You decide to prepare a fixed number of checkout counters (servers) to handle the rush. Sometimes, many customers wait in long lines; other times, counters sit idle.
Manually guessing traffic means you either waste money paying for unused capacity or frustrate customers with slow service during busy times. Adjusting capacity constantly is tiring and error-prone.
With on-demand and provisioned capacity modes, DynamoDB lets you choose how to pay for database usage. On-demand automatically adjusts to traffic, charging only for what you use. Provisioned lets you set capacity ahead, saving money if traffic is steady and predictable.
Set fixed capacity: 100 reads/sec, 50 writes/sec Pay for all even if unused
Use on-demand mode Pay only for actual reads and writes Or provision capacity based on expected load
You can optimize costs and performance by matching your database capacity to real user demand without guesswork.
A mobile app with unpredictable user spikes uses on-demand mode to handle sudden traffic without downtime or overspending.
Manual capacity planning wastes money or causes slowdowns.
On-demand mode charges per actual use, perfect for variable traffic.
Provisioned mode saves cost when traffic is steady and predictable.
Practice
Solution
Step 1: Understand billing modes in DynamoDB
DynamoDB offers two main billing modes: on-demand and provisioned. On-demand charges per request without pre-allocating capacity.Step 2: Identify the mode with no upfront capacity planning
On-demand mode does not require capacity planning and bills you based on actual usage.Final Answer:
On-demand mode -> Option CQuick Check:
On-demand charges per request = On-demand mode [OK]
- Confusing provisioned mode as pay-per-request
- Thinking reserved mode exists in DynamoDB billing
- Assuming manual mode is a billing option
Solution
Step 1: Recall DynamoDB table creation syntax for provisioned mode
Provisioned mode requires specifying ProvisionedThroughput with ReadCapacityUnits and WriteCapacityUnits.Step 2: Match the correct syntax
ProvisionedThroughput: { ReadCapacityUnits: 5, WriteCapacityUnits: 5 } uses the exact correct keys: ProvisionedThroughput with ReadCapacityUnits and WriteCapacityUnits.Final Answer:
ProvisionedThroughput: { ReadCapacityUnits: 5, WriteCapacityUnits: 5 } -> Option AQuick Check:
Provisioned capacity uses ProvisionedThroughput [OK]
- Using BillingMode for provisioned capacity
- Incorrect key names like CapacityUnits or Throughput
- Confusing ON_DEMAND with provisioned syntax
Solution
Step 1: Analyze usage vs provisioned capacity
The app uses 8 reads and 3 writes per second, which is below the provisioned 10 reads and 5 writes capacity.Step 2: Compare cost implications
Provisioned mode charges fixed capacity regardless of usage, so if usage is steady and below provisioned, it is cheaper than on-demand which charges per request.Final Answer:
Provisioned mode -> Option DQuick Check:
Steady low usage < provisioned = Provisioned cheaper [OK]
- Assuming on-demand is always cheaper
- Ignoring provisioned capacity limits
- Thinking cost depends only on data size
Solution
Step 1: Identify the mismatch between capacity and usage
The app needs 20 reads per second but provisioned capacity is only 5 reads, causing throttling.Step 2: Determine the fix
To fix, increase provisioned capacity or switch to on-demand mode which scales automatically.Final Answer:
Provisioned capacity too low; increase capacity or switch to on-demand -> Option AQuick Check:
Low provisioned capacity causes throttling; increase or switch [OK]
- Confusing on-demand and provisioned modes
- Reducing capacity when usage is high
- Ignoring throttling symptoms
Solution
Step 1: Understand startup needs
They want to handle unpredictable spikes but also control costs.Step 2: Evaluate billing options
Provisioned mode with auto scaling adjusts capacity automatically, balancing cost and flexibility better than fixed provisioned or pure on-demand.Step 3: Compare with other options
High fixed provisioned is costly; on-demand can be expensive at scale; manual limits reduce flexibility.Final Answer:
Use provisioned mode with low capacity and enable auto scaling -> Option BQuick Check:
Auto scaling balances cost and spikes well [OK]
- Choosing high fixed provisioned capacity unnecessarily
- Assuming on-demand always cheaper for spikes
- Trying to limit requests manually in on-demand mode
Ready to prove it?
Pass the test and this pattern moves unknown
