AWS DynamoDB Support
DynamoDB on-demand vs provisioned capacity.
On-demand removes capacity planning and charges per request. Provisioned is usually cheaper for steady, predictable traffic but throttles if you under-provision. The right choice depends on your traffic shape, and tables can switch modes, though not unlimited times per day. We model both with your real usage.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Your DynamoDB bill is rising and you are unsure which mode fits
- Traffic is spiky or unknown and you see throttling
- A steady workload runs on on-demand and costs more than expected
- You launched a new table and need a starting mode
- You see ProvisionedThroughputExceededException errors
What you get
- Per-table usage analysis and recommended mode
- Cost model comparing on-demand, provisioned and reserved capacity
- Auto scaling or on-demand configuration in infrastructure as code
- Throttling and cost alarms
How we do it
A clear, safe process you can follow along with.
1. Collect usage per table and index
We read ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits at fine granularity for tables and global secondary indexes over several weeks, plus throttle and latency metrics.
2. Classify the traffic shape
Flat or slowly changing traffic favors provisioned with auto scaling. Sharp, unpredictable bursts or idle tables favor on-demand. Daily peaks may suit scheduled scaling.
3. Model the cost
We compute cost under each mode using current regional prices, including reserved capacity for provisioned, and the table class choice since Standard-IA lowers storage price and raises request price.
4. Check for throttling causes first
Throttling can come from a hot partition or a single hot key rather than total capacity. Changing modes will not fix that, so we check partition-level skew.
5. Switch and tune
For provisioned we set auto scaling min, max and target utilization from observed burst. For on-demand we consider maximum throughput limits as cost guardrails and review warm throughput for planned launches.
6. Monitor and revisit
We create alarms on throttles and on cost per table, and review again after traffic changes, being mindful of mode switch limits.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Choosing on-demand for everything
It is excellent for variable load but can cost more than provisioned for steady heavy traffic.
Auto scaling with a slow target
Auto scaling reacts over minutes, so sudden spikes can still throttle. We set minimums with that in mind.
Ignoring indexes
Each global secondary index has its own capacity needs.
Treating throttling as a capacity problem only
Hot keys throttle even when table capacity is available.
Frequently Asked Questions
Is DynamoDB on-demand more expensive than provisioned?
Per request it usually is, but you pay nothing for unused capacity. For steady high traffic provisioned is typically cheaper, and for variable traffic on-demand can win.
Can I switch between on-demand and provisioned?
Yes, but AWS limits how often you can switch a table. Check the current limit before planning frequent changes.
What causes ProvisionedThroughputExceededException?
Consumption exceeded provisioned capacity on the table, an index or a single partition. Review metrics for total versus per-key traffic and fix the cause.
Want Help With DynamoDB on-demand vs provisioned capacity?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required