.png)
AWS DynamoDB Reserved Capacity reduces provisioned throughput costs by up to 77% in exchange for a 1- or 3-year commitment. On paper, the math is you pay a one-time upfront fee, and receive a discounted hourly rate for the committed capacity. The engineering challenge is sizing that commitment correctly. If you buy too little, you are leaving savings on the table; buy too much and you're paying for capacity you don't use, with no refund available.
This guide covers exact pricing figures for read capacity units (RCUs) and write capacity units (WCUs), complete break-even analysis, the constraints that catch teams off-guard, and how the November 2024 on-demand price cut changes the provisioned-vs-on-demand calculus.
DynamoDB Reserved Capacity locks in a minimum provisioned throughput level, in blocks of 100 WCUs or 100 RCUs for a 1- or 3-year term. You pay a one-time partial upfront fee plus a discounted hourly rate for the committed capacity. In return, AWS cuts your provisioned throughput bill by up to 54% (1-year) or 77% (3-year) versus standard rates.
It is purely a billing construct. Purchasing a reservation changes nothing about your tables, There is no visible performance impact, no availability change, and no configuration required. AWS applies the discounted rate automatically at billing time, first to the purchasing account, then to any linked accounts under consolidated billing.
Three constraints define where this AWS DynamoDB capacity reservation applies:
If your table doesn't meet all three, the reservation discount does not apply to it.
Also read: AWS Reserved Instances: Complete Guide to Pricing, Types & Savings
The numbers below cover reserved capacity DynamoDB pricing for US East (N. Virginia), i.e., us-east-1, the AWS reference region and is generally the cheapest.
Note: Rates vary by region; always verify at the official AWS pricing page before budgeting.
Verify at aws.amazon.com/dynamodb/pricing/provisioned for rates change
Writes cost 5× more than reads per capacity unit. A workload with symmetric read/write load will spend the overwhelming majority of its throughput budget on writes. Now, this is one fact that shapes every reservation sizing decision.
Source: AWS pricing page
AWS publishes the 3-year amortized effective rate: $150 upfront ÷ 365 days ÷ 24 hours = $0.0171/hr effective for 100 WCUs. Verify exact current upfront fees and hourly rates at aws.amazon.com.
Also read: On-Demand vs Reserved vs Spot Instances: The Complete AWS Pricing Guide 2026
The break-even calculation determines at what utilization level a reservation pays off versus standard provisioned pricing and how long it takes to recover the upfront cost.
Scenario: A product catalog service running 1,000 WCUs and 5,000 RCUs, 24/7, in us-east-1.
Standard provisioned monthly cost:
1-Year Reserved Capacity monthly cost (effective):
3-Year Reserved Capacity effective cost:
These figures use current published AWS rates and amortization methodology. Verify exact numbers at Amazon docs. Use the AWS Pricing Calculator to model your specific workload.
For a 1-year reservation on 100 WCUs (upfront ~$150), the discounted hourly rate kicks in immediately. At standard savings rates, the upfront fee is typically recovered within the first 1–3 months of operation for a fully utilized reservation.
The critical variable is utilization. Reserved capacity is a commitment to pay, not a commitment to use. If your workload consumes only 60% of the reserved capacity, your effective savings shrink. That means, you're paying for 100% but benefiting from 60%. AWS billing doesn't refund the unused fraction.
Also read: How to Choose Between 1-Year and 3-Year AWS Commitments
These are the restrictions that create real operational problems at scale and that most documentation pages bury in footnotes.
Reservations are purchased in blocks of 100 WCUs or 100 RCUs. You cannot buy 73 WCUs to match your exact baseline; you must round up to 100. For workloads sitting between block sizes, this creates structural overcommitment.
Example: A workload with a stable baseline of 150 WCUs must either buy 100 (leaving 50 at standard rates) or 200 (over-reserving by 50 WCUs). Neither is exact. Managing this across dozens of tables compounds the problem significantly.
Once purchased:
A workload that migrates regions, gets deprecated, or shifts to on-demand capacity mid-term forfeits the remaining reservation value. This is the primary financial risk of DynamoDB Reserved Capacity.
Reserved capacity is tied to the region where it is purchased. A reservation in us-east-1 provides zero discount on capacity in us-west-2 or eu-west-1. Multi-region architectures require separate reservations per region, multiplying both the upfront cost and the sizing complexity.
Reserved capacity does not apply to DynamoDB Standard-IA (Infrequent Access) tables. If you're using Standard-IA to reduce storage costs on cold data, you cannot stack reserved capacity savings on top. The discount layers don't combine.
Reserved capacity only discounts provisioned mode throughput. On-demand tables (billed per-request) are ineligible. This is a significant constraint given the November 2024 on-demand price cut (discussed below).
You cannot purchase reserved capacity for replicated WCUs (rWCUs), i.e., the write units consumed by Global Tables replication. If Global Tables is a meaningful part of your DynamoDB spend, reserved capacity addresses only the local write portion.
Three-year reserved capacity is not available in all AWS Regions. If your workload runs in a region that doesn't support 3-year terms, the maximum discount available is the 1-year rate (~54%).
AWS cut DynamoDB on-demand pricing by 50% in November 2024, marking the most significant change to DynamoDB reserved capacity decision-making in years, and one that directly affects the provisioned-vs-on-demand break-even point.
Before November 2024: On-demand was substantially more expensive than provisioned at any meaningful scale. The math strongly favored provisioned and reserved for stable workloads.
After November 2024: The break-even point shifted toward on-demand. Workloads that were marginal candidates for provisioned capacity may now be better served by on-demand, particularly if utilization is irregular or if the team lacks the tooling to rightsize reservations accurately.
What this means for reserved capacity decisions: The 54%/77% reserved capacity discounts are calculated off provisioned rates, not the post-cut on-demand rates. Before purchasing a reservation, model your workload against the current on-demand rates, not the pre-2024 rates your existing cost benchmarks may reflect.
For strongly predictable workloads, reserved capacity on provisioned mode remains the lowest-cost option. For workloads with meaningful variability (>30% swing in peak vs. baseline), the new on-demand rates have closed the gap significantly.
Also read: Multi-Cloud Cost Optimization Guide for AWS, Azure, GCP Savings
AWS introduced Database Savings Plans at re:Invent 2025, the first commitment discount mechanism that applies to DynamoDB on-demand mode. This is a meaningful structural change to the DynamoDB discount landscape.
Database Savings Plans: How They Work
Verify Database Savings Plan pricing and eligibility at aws.amazon for rates and scope change
The introduction of Database Savings Plans doesn't eliminate reserved capacity's value for high-volume provisioned workloads, the 77% 3-year discount remains a strong ceiling. But for teams running on-demand mode for flexibility, Database Savings Plans now offer a meaningful commitment path that wasn't available before 2026.
Choose On-Demand when:
Choose Provisioned (with Auto Scaling) when:
Choose Reserved Capacity (Provisioned + Reservation) when:
Choose Database Savings Plans when:
Also read: Cloud Cost Analysis: How to Measure, Reduce, and Optimize Spend
Sizing reservations incorrectly is the single largest source of DynamoDB reserved capacity waste. The correct baseline is your sustained minimum over the commitment period.
Step 1: Pull 30–90 days of hourly WCU and RCU consumption data Use AWS Cost Explorer or CloudWatch metrics. Filter to each table and region separately. Aggregating across tables masks individual table patterns.
Step 2: Identify the P10 consumption baseline The 10th percentile of hourly consumption represents a conservative reservation floor, the throughput level your workload consumed or exceeded 90% of the time. Reserving at P50 (median) risks systematic underutilization during the bottom half of usage distribution.
Step 3: Round down to the nearest 100-unit block Round your P10 baseline down to the nearest 100-unit block. This is conservative by design. The cost of a slightly under-reserved table (paying standard rates on marginal capacity above the reservation) is lower than the cost of systematic overcommitment on non-refundable capacity.
Step 4: Separate WCU and RCU baselines per table, per region Don't aggregate. A table with 2,000 WCUs in us-east-1 and 800 WCUs in eu-west-1 needs separate reservation calculations and separate purchases. The total looks like 2,800 WCUs, but only 2,000 of those are eligible for a reservation in the region where the workload actually runs.
Step 5: Model the break-even against the current rate card Using the upfront fee and discounted hourly rates from the AWS pricing page, calculate total 1-year cost (upfront + hourly × 8,760 hours) versus total standard provisioned cost (standard rate × 8,760 hours). If the reservation pays off within 6–9 months, it's financially sound. If it requires >10 months to recover the upfront cost at your utilization level, reconsider.
Step 6: Account for projected capacity changes Are you migrating tables? Expecting sustained workload growth that would push you well above current baselines? Plan for the capacity level you'll maintain throughout the term, not just today's baseline.
If your actual provisioned capacity falls below the reserved level in a given period, you still pay the full reserved rate for that period. There is no retroactive credit for hours where consumption was lower than the commitment.
The practical scenarios where this creates waste:
Table decommissioning: A table is deprecated mid-term. The reservation continues billing until expiration. The upfront fee is already paid and non-refundable.
Workload migration: Traffic migrates to a different table, region, or service. The original reservation generates no savings on the new workload.
Over-optimized provisioning: You reduce provisioned capacity below the reserved floor (perhaps by switching to smaller item sizes or optimizing queries to require fewer capacity units). The billing floor is now your reserved amount, not your provisioned amount.
Consolidated billing partial mitigation: If you have AWS Organizations with multiple linked accounts, unused reserved capacity in one account can apply to usage in other linked accounts. This is the only built-in mechanism for partial redistribution. It requires centralized visibility across accounts to leverage effectively.
Also read: How to Identify Idle & Underutilized AWS Resources
Prerequisites:
Step 1: Sign in to the AWS Management Console and navigate to DynamoDB.
Step 2: Ensure you are in the correct AWS Region. Reserved capacity is region-specific, so purchases made in the wrong region cannot be transferred.
Step 3: In the navigation pane, select Reserved Capacity, then choose Purchase Reserved Capacity.
Step 4: Select the Offering Type: WCU (Write Capacity Units) or RCU (Read Capacity Units). You must purchase WCUs and RCUs as separate transactions.
Step 5: Select the term length: 1 year or 3 years (if available in your region).
Step 6: Enter the quantity in blocks of 100. The console will display the one-time upfront fee and the discounted hourly rate for the quantity selected.
Step 7: Review the total commitment cost and confirm the purchase. The reservation activates immediately.
Verification: How Do You Know It Worked: Navigate back to Reserved Capacity in the DynamoDB console. Active reservations appear with their term, quantity, region, and expiration date. In Cost Explorer, DynamoDB line items will begin reflecting the reserved rate for capacity within the reservation's scope within the next billing period.
What to Do If the 3-Year Term Isn't Available: Three-year reserved capacity is not available in all regions. If the option doesn't appear in the term dropdown, that region supports 1-year terms only. Verify regional availability at aws.amazon.com/dynamodb/pricing/reserved-capacity.
AWS Trusted Advisor and Cost Explorer both provide DynamoDB reservation recommendations. The limitation is both tools are working from utilization data that is up to 72+ hours old by the time a recommendation surfaces.
Why recommendation latency matters for reservations:
DynamoDB provisioned capacity scales up and down frequently, sometimes multiple times per day under Auto Scaling. A recommendation generated from data that is 3 days old may reflect a usage pattern that no longer exists. In fast-moving workloads (product launches, seasonal traffic spikes, schema migrations), acting on stale recommendations leads to:
This is a structural limitation of static recommendation tooling that cannot be worked around.
For engineering teams managing dozens of DynamoDB tables across multiple regions and accounts, the reservation sizing process described above - pull 90-day data, calculate P10, model break-even, submit purchase, monitor utilization is a full-time task when done manually. Most teams either skip it entirely or do it once per year during budget cycles, missing months of potential savings in between.
Usage.ai's Flex Reserved Instances product includes DynamoDB in its coverage scope, delivering 30–40% savings on DynamoDB provisioned throughput with $0 upfront cost and no multi-year lock-in.
Usage Flex Reserved Instances for DynamoDB is an automated commitment mechanism that delivers RI-equivalent discounts (30–40%) on DynamoDB provisioned capacity without requiring the customer to own the commitment. Usage.ai manages the reservation at the billing layer, guarantees against underutilization with cashback, and refreshes coverage recommendations every 24 hours, compared to the 72+ hour refresh cycle of AWS native tools.
The specific problems this solves:
Problem: Minimum block sizing causes systematic over-commitment DynamoDB reservations must be purchased in 100-unit blocks. A workload with an 850 WCU baseline either under-reserves (800 reserved, 50 at standard rates) or over-reserves (900 reserved, 50 WCUs of committed spend generating zero savings). At scale across 50+ tables, this block-size friction compounds into meaningful structural waste. Usage.ai's automation handles block-size optimization across your full table fleet.
Problem: Recommendations from AWS tools are up to 72 hours stale Usage.ai refreshes coverage recommendations every 24 hours. At $6–12K per day in uncovered provisioned spend for large DynamoDB deployments, a 3-day vs. 1-day refresh gap represents $18K+ in potentially missed savings per cycle.
Problem: Non-refundable commitments create organizational hesitation Usage.ai's cashback protection means underutilization of commitments purchased through the platform results in actual monetary cashback, and not AWS credits. This is the only platform in the market providing both cashback and credits on commitment underutilization.
Problem: Multi-account, multi-region DynamoDB is unmanageable manually Usage.ai operates at the billing layer across consolidated billing organizations, covering DynamoDB reservation opportunities across all accounts and regions without requiring infrastructure changes. Setup takes approximately 30 minutes with billing-layer access only.
Usage.ai delivers $91M+ in verified savings across 300+ enterprise customers. Customers including Motive, EVGo (NASDAQ: EVGO), Secureframe, and Blank Street Coffee use the platform across their full AWS commitment portfolios.
Fee model: percentage of realized savings only. Zero fee if Usage.ai saves nothing on the platform.
In US East (N. Virginia), standard provisioned pricing is $0.00065 per WCU per hour and $0.00013 per RCU per hour (verify at aws.amazon.com/dynamodb/pricing/provisioned — rates change). A 1-year reserved capacity term saves approximately 53–54% off these standard rates; a 3-year term saves approximately 76–77%. Reservations are purchased in blocks of 100 capacity units. AWS amortizes the upfront fee example: for 100 WCUs on a 3-year term, the $150 upfront fee equals $0.0171/hr effective rate when amortized.
DynamoDB Reserved Capacity saves up to 54% on a 1-year term or up to 77% on a 3-year term compared to standard provisioned capacity rates. A workload consuming 1,000 WCUs steady-state costs approximately $474/month at standard provisioned rates in us-east-1. A 3-year reservation reduces the effective cost to approximately $109/month, saving roughly $365/month. At 10,000 WCUs, those savings scale to approximately $3,650/month or $43,800/year. The actual savings depend on utilization rate and current AWS pricing.
No. DynamoDB Reserved Capacity is non-refundable, non-cancelable, and non-transferable. The one-time upfront payment cannot be recovered, and the reservation cannot be moved to a different AWS Region or account. The only partial mitigation is consolidated billing: unused capacity from one linked account can be applied to usage in other accounts within the same AWS Organization. This makes commitment sizing precision critical before purchase.
DynamoDB Reserved Capacity applies to single-region provisioned read and write capacity units (RCUs and WCUs), including those used by global and local secondary indexes. It does not apply to replicated WCUs (rWCUs); the additional write capacity consumed by Global Tables replication. If your DynamoDB spend includes a significant Global Tables component, reserved capacity addresses local provisioned throughput only, and rWCU costs remain at standard rates.
The minimum reservation is 100 capacity units; either 100 WCUs or 100 RCUs. Reservations must be purchased in multiples of 100. There is no option to reserve 50 WCUs or any quantity that isn't a multiple of 100. This block-size constraint means workloads sitting between multiples of 100 will either under-reserve or over-reserve. The total combined purchase limit via the AWS Management Console is 1,000,000 capacity units (WCUs + RCUs combined); larger purchases require an AWS service limit increase request.
No. DynamoDB Reserved Capacity applies exclusively to provisioned mode capacity; tables configured with a fixed WCU/RCU allocation. On-demand tables (billed per request via write request units and read request units) are ineligible. AWS introduced Database Savings Plans at re:Invent 2025 as the first commitment discount for DynamoDB on-demand mode, i.e., a 1-year, no-upfront-payment commitment to a $/hour spend level.
They address different cost layers. Reserved Capacity discounts DynamoDB provisioned throughput (WCUs/RCUs) specifically. AWS Compute Savings Plans cover EC2, Fargate, and Lambda — they have no effect on DynamoDB charges. The new Database Savings Plans (launched re:Invent 2025) are the closest analog to Savings Plans for DynamoDB, covering on-demand throughput with a flexible $/hour commitment. For provisioned DynamoDB workloads, Reserved Capacity and Database Savings Plans are separate and don't overlap; for on-demand workloads, only Database Savings Plans apply.
You still pay the full reserved rate for your committed capacity, regardless of actual usage. Reserved capacity commits you to pay for a minimum throughput level. If provisioned capacity drops below the reserved amount, the reservation continues billing at the committed rate with no credit for unused capacity. Over-reservation is therefore a direct cost, not a recoverable one. The only exception is consolidated billing: unused capacity from one account can offset usage in linked accounts within the same AWS Organization.
Share this post
.svg){kind=icon}
.svg)
.png)