AWS
Microsoft Azure
Google Cloud
The tradeoff is commitment risk. Reserved capacity works best when you commit only to capacity that your DynamoDB tables and indexes are likely to keep provisioned throughout the term.
The safest process is to right-size first, identify your stable provisioned floor, round that amount down to AWS’s required 100-unit blocks, and compare the current reserved-capacity quote with alternatives such as on-demand pricing and Database Savings Plans.
AWS documents the current eligibility rules, terms, restrictions, and regional pricing on its Amazon DynamoDB pricing page.
What DynamoDB reserved capacity pricing includes
Reserved provisioned capacity changes how AWS charges for eligible DynamoDB provisioned throughput. It does not create a separate DynamoDB capacity mode.You still operate a table in provisioned mode, but part of the eligible RCU or WCU usage receives reserved pricing based on the commitment you purchased.
For example, AWS currently lists standard provisioned read capacity in US East (N. Virginia) at $0.00013 per RCU-hour. At that rate, 100 provisioned RCUs running for 730 hours would have a gross throughput cost of:
A reserved-capacity calculation requires additional inputs from the live AWS offering:
Region
RCU or WCU quantity
Commitment term
Upfront fee
Reserved hourly rate
Purchase date
AWS provides the current provisioned-capacity pricing and purchase guidance on the official DynamoDB pricing page.
How many RCUs should you reserve?
The safest commitment target is usually the stable provisioned RCU floor that you expect to maintain throughout the reservation term.Do not reserve against peak capacity.
Do not automatically reserve against average capacity.
And do not use raw consumed RCU as the final commitment number.
DynamoDB provisioned pricing is based on how much capacity is provisioned, while consumed capacity helps you understand how much of that provisioned capacity the application is actually using.
That creates a two-step sizing process.
First, use consumption data to right-size the workload. Then use the resulting provisioned-capacity history to determine how much capacity is consistently eligible for a reservation.
Step 1: Review a representative usage period
Review ConsumedReadCapacityUnits and ProvisionedReadCapacityUnits in Amazon CloudWatch for each DynamoDB table and relevant index.Thirty days is a useful minimum for many workloads. A 60- to 90-day period can provide a better view when traffic changes by weekday, month-end cycle, release schedule, or season.
Also review throttling metrics. Low consumed capacity does not necessarily mean low demand if requests were being throttled.
AWS explains DynamoDB monitoring metrics and capacity behavior in its DynamoDB CloudWatch documentation.
Step 2: Right-size before committing
Suppose a table remains provisioned at 500 RCU but normally consumes only about 120 RCU.Buying a 500-RCU reservation before optimization could convert existing overprovisioning into a long-term commitment.
Instead, adjust the table or auto scaling configuration first and confirm that the lower provisioned level handles normal traffic without unacceptable throttling.
Then evaluate the new provisioned baseline.
If the table and its relevant indexes consistently remain at or above 380 provisioned RCU during normal operation, a conservative reservation target would be 300 RCU because AWS sells reserved capacity in blocks of 100 units.
Do not automatically round 380 up to 400.
If provisioned capacity later falls below 400, part of the commitment may go unused.
Step 3: Include relevant secondary indexes
Global secondary indexes have their own provisioned capacity and can add to the eligible regional reservation requirement. Local secondary indexes use the base table’s provisioned capacity, so do not add a separate LSI capacity floor.For example:
Base table stable floor: 300 RCU
GSI 1 stable floor: 100 RCU
GSI 2 stable floor: 100 RCU
Potential regional reservation: 500 RCU
AWS explains the difference between base-table and index capacity in its DynamoDB right-sizing guidance.
Step 4: Check future architecture changes
Before buying reserved capacity, look beyond historical usage.Planned changes can materially reduce the amount of capacity you need, including:
Moving a workload to on-demand mode
Switching to DynamoDB Standard-IA
Adding caching
Redesigning access patterns
Migrating to another Region
Retiring a service
Consolidating tables
Changing auto scaling targets
How to calculate reserved RCU break-even
Break-even depends on the actual AWS reservation quote you receive.A fixed statement such as “one year breaks even in four months” can become inaccurate if the underlying upfront fee or reserved hourly rate changes.
Instead, calculate break-even using the live offer.
- S = standard hourly rate per RCU
- R = reserved hourly rate per RCU
- Q = number of reserved RCUs
- U = upfront fee
A short break-even period does not automatically make a reservation safe. The more important question is whether enough eligible provisioned capacity will remain in place after break-even to continue using the commitment.
Restrictions to check before buying
DynamoDB reserved provisioned capacity has narrower eligibility than many spend-based AWS commitment models.According to the current AWS DynamoDB pricing guidance, teams should account for these restrictions:
Provisioned mode only: Native DynamoDB reserved capacity does not apply to on-demand tables.
Standard table class: DynamoDB Standard-IA capacity is not eligible for native reserved provisioned capacity.
Region specific: The commitment applies to eligible capacity in the Region where it was purchased.
100-unit blocks: Reserved capacity is purchased in blocks of 100 RCU or 100 WCU.
Three-year availability: Three-year offerings are available only in selected Regions.
Global Tables: Reserved capacity does not cover replicated write capacity units.
No cancellation: Reserved provisioned capacity cannot be sold or cancelled, and the upfront payment is non-refundable.
No Region transfer: A reservation cannot be transferred to another Region.
Under AWS Organizations consolidated billing, if Reserved Instances and Savings Plans discount sharing is enabled for the relevant accounts, AWS applies the reservation benefit to eligible usage in the purchasing account first. Any unused benefit can then apply to eligible linked-account usage according to the organization’s sharing settings.
AWS explains how these sharing controls work in its Reserved Instances and Savings Plans discount-sharing guidance.
That does not mean the reservation itself has been transferred between accounts. It is a consolidated-billing application of the pricing benefit.
This distinction matters when FinOps teams calculate commitment coverage across multi-account AWS organizations.
Should you reserve reads or writes?
Evaluate RCU and WCU separately.A predictable read baseline does not guarantee predictable writes. Similarly, a stable write-heavy ingestion workload does not mean read capacity deserves the same commitment level.
Use the same decision process for each capacity type:
Is the workload using provisioned mode and the Standard table class?
Does it have a post-optimization floor of at least 100 units?
Has that floor remained stable through a representative period?
Is the workload expected to remain in the same Region and capacity mode?
Does the current AWS reserved quote produce better economics than realistic alternatives?
If not, leave that portion at standard provisioned pricing or compare it with on-demand pricing and Database Savings Plans.
How reserved RCU works with auto scaling
DynamoDB auto scaling and reserved capacity solve different problems.Auto scaling adjusts the amount of throughput provisioned to the workload.
Reserved capacity changes the price applied to eligible provisioned throughput.
Suppose you have 300 reserved RCU in a Region.
If auto scaling provisions 500 eligible RCU, up to 300 RCU can receive reserved pricing while the remaining 200 RCU is billed at the applicable standard provisioned rate.
If provisioned capacity falls to 300 RCU, the eligible amount can fit within the commitment.
If provisioned capacity falls to 250 RCU, part of the 300-RCU reservation can become unused.
That is why the reservation should follow the workload floor rather than its peak.
For more detail on the interaction between scaling policies and provisioned throughput, see our guide to DynamoDB auto scaling.
Reserved capacity vs Database Savings Plans
Native DynamoDB reserved capacity generally fits workloads with a predictable provisioned floor in one Region.Database Savings Plans are designed around a one-year dollar-per-hour commitment and provide more flexibility across eligible database usage.
AWS currently advertises DynamoDB savings through Database Savings Plans of up to 18% for eligible on-demand throughput and up to 12% for eligible provisioned throughput. AWS explains the eligible database services and discount model in its Database Savings Plans documentation.
| Decision factor | DynamoDB reserved capacity | Database Savings Plans |
|---|---|---|
| Capacity mode | Provisioned only | Eligible provisioned and on-demand usage |
| Commitment basis | Number of RCU or WCU | Eligible database spend in $/hour |
| Term | One year; three years in selected Regions | One year |
| Upfront payment | Partial upfront | No upfront |
| Regional flexibility | Region specific | Can follow eligible usage across Regions |
| Service flexibility | DynamoDB capacity | Multiple eligible AWS database services |
| Maximum DynamoDB discount | Up to 54% or 77% | Up to 18% on-demand; up to 12% provisioned |
That means you should not size a Database Savings Plan against DynamoDB spend already expected to receive a native reservation benefit.
For a broader explanation of the spend-based option, see our Database Savings Plans guide.
What most DynamoDB teams should do
Start by determining whether the workload actually has a durable provisioned floor.Review 30 to 90 days of consumed capacity, provisioned capacity, throttling, scaling behavior, and upcoming architecture changes. Right-size the workload before introducing any commitment.
For stable Standard-class provisioned workloads, calculate a conservative native reservation amount by rounding the sustained provisioned floor down to the nearest 100 RCU or WCU.
Then compare three scenarios using the same workload forecast:
Standard or on-demand DynamoDB pricing
Native DynamoDB reserved provisioned capacity
AWS Database Savings Plans
For multi-account organizations, account for both consolidated-billing sharing settings and the fact that native DynamoDB reserved capacity is applied before Database Savings Plans.
The result should be a commitment level that reflects durable usage rather than the largest discount percentage available.
How we help with DynamoDB commitment planning
DynamoDB commitment planning becomes more difficult when eligible database spend is distributed across accounts, Regions, tables, capacity modes, and other AWS database services.At Usage.ai, we analyze eligible DynamoDB usage to help teams size AWS Database Savings Plans and manage the lifecycle of supported plans. We account for usage already covered by native reserved capacity so teams can reduce the risk of committing twice against the same DynamoDB spend.
With Flex Insured Commitments, teams can get the 30–40% savings of a 1-year commitment with none of the commitment risk.
If eligible usage drops and a qualifying DynamoDB Flex Commitment ends up costing more than the on-demand rate for that usage, we provide cashback protection on that difference, subject to program terms.
Our fees are based on realized savings, as described on our pricing page. Teams should also review the current Flex Commitment eligibility requirements before applying the program to an environment.
Frequently asked questions
What does one DynamoDB RCU provide?
For an item up to 4 KB, one RCU supports one strongly consistent read per second or two eventually consistent reads per second. Transactional reads require two read capacity units. Larger items are rounded up in 4 KB increments.
AWS provides the detailed read consistency calculation in its DynamoDB read and write operations documentation.
Can on-demand DynamoDB tables use reserved capacity?
No. Native DynamoDB reserved provisioned capacity applies to eligible provisioned capacity using the DynamoDB Standard table class.
Eligible on-demand DynamoDB usage can instead receive Database Savings Plans discounts.
Can I cancel or move DynamoDB reserved capacity?
No. AWS states that reserved provisioned capacity cannot be sold or cancelled, and its upfront fee is non-refundable. It also cannot be transferred to another Region.
Under AWS Organizations consolidated billing, unused reservation benefits may apply to eligible linked-account usage when discount sharing is enabled for the relevant accounts. This is billing benefit sharing, not transfer of ownership.
Does reserved capacity apply to secondary indexes?
Reserved provisioned capacity can apply to eligible DynamoDB table capacity and secondary-index capacity. Add a global secondary index’s stable provisioned capacity separately because its throughput is independent of the base table; do not add local secondary index capacity separately because it uses the base table’s provisioned capacity.
Do not reserve against temporary or highly variable provisioned capacity simply because its average is high.
Should I use consumed or provisioned RCU when sizing a reservation?
Use both.
Consumed RCU helps you understand actual demand and identify overprovisioning.
Provisioned RCU shows the capacity AWS is billing in provisioned mode and should be used to determine the stable eligible floor after right-sizing.
