Cost

Purchase DynamoDB Reserved Capacity

If your high-volume DynamoDB tables run in provisioned mode with steady throughput, reserved capacity buys the same RCUs and WCUs for up to ~77% less — but it does nothing for On-Demand tables.

14 min·10 sections·AWS

Last reviewed 27 May 2026

DynamoDB Reserved Capacity: the basics

A commitment that only works if your tables are in the right mode

DynamoDB Reserved Capacity is a billing commitment against throughput, not storage. You commit to a block of provisioned Read Capacity Units (RCUs) and Write Capacity Units (WCUs) in a single AWS region for one or three years, and in exchange AWS discounts the hourly rate on that capacity by up to roughly 77% versus standard provisioned pricing. Nothing about a table changes — the discount is applied behind the scenes against the provisioned capacity you're already running in that region.

There is one hard prerequisite that makes or breaks the whole decision: reserved capacity only applies to tables in provisioned capacity mode. It does absolutely nothing for On-Demand (pay-per-request) tables — those bill per request and reserved RCU/WCU blocks never match them. So step 0 is not "how much do I reserve?" but "are my high-volume tables in provisioned mode with stable, predictable throughput?" If they're On-Demand, the right first move is the capacity-mode lesson, not this one.

Reserved capacity is region-scoped and pooled: a block of reserved RCUs/WCUs applies across all provisioned tables in that region and account, not to one named table. That makes it well-suited to a fleet of steady, always-on tables sharing a baseline. It is sold in three payment shapes — like other AWS reservations, more upfront means a deeper discount. And critically, you buy it through the console or from a Cost Explorer recommendation; there is no rich purchase API the way EC2 and RDS expose one.

In this lesson you'll learn why DynamoDB reserved capacity is gated entirely on capacity mode, how it's scoped (region-wide pools of RCUs and WCUs, throughput only, never storage), and the sequence that protects you — confirm provisioned mode, right-size, enable auto-scaling, then reserve the floor. You'll see the CLI calls that actually exist for this workflow: aws ce get-reservation-purchase-recommendation to surface a recommendation and aws dynamodb describe-table to compare consumed versus provisioned throughput — and you'll learn why the purchase itself happens in the console, not a rich CLI API. You'll also see the traps: reserving against On-Demand tables, committing before right-sizing, and forgetting that storage is never covered.

Fun fact

The reservation that covered nothing

DynamoDB reserved capacity is one of the deepest discounts in AWS — up to roughly 77% off provisioned throughput on a three-year commitment. A team saw that number, saw a six-figure annual DynamoDB bill, and bought a large block of reserved WCUs to capture it. The problem: their highest-volume tables had been migrated to On-Demand mode the year before to handle spiky traffic, and reserved capacity does nothing for On-Demand tables. The reservation matched almost none of their actual spend. They paid the full upfront commitment and the full On-Demand bill, side by side, for the entire term — a 77% discount that delivered close to 0% savings because nobody checked the capacity mode first.

Buying DynamoDB reserved capacity in action

Dana runs the platform team at a high-traffic consumer app. The FinOps dashboard shows about $22k/month of DynamoDB spend, and most of it is provisioned-throughput charges on a handful of always-on tables — a sessions table, an events ledger, a user-profile store — that have run the same steady shape for over a year. None of it is committed.

Before reserving a unit, Dana does the prerequisite work. She confirms the big tables are actually in provisioned mode (one borderline table was on On-Demand and stays there because its traffic is genuinely spiky). She right-sizes the provisioned RCUs/WCUs down on two tables that were padded for a launch that never spiked, and enables auto-scaling on all of them so day-to-day peaks are handled above the reserved floor.

Only then does she pull the Cost Explorer recommendation. It suggests a three-year reservation covering the steady baseline of provisioned write capacity, projecting roughly 60% savings on that slice. Dana decides to reserve ~80% of the stable floor — leaving auto-scaling to absorb the variable top On-Demand-style — and completes the purchase in the DynamoDB console, since there's no rich CLI purchase API. She notes the renewal date on the calendar and adds coverage and utilisation to the monthly pack.

First, ask Cost Explorer what it recommends reserving for DynamoDB. Scope it to the DynamoDB service so you don't get EC2 or RDS noise.

$ aws ce get-reservation-purchase-recommendation --service "Amazon DynamoDB" --term-in-years THREE_YEARS --payment-option PARTIAL_UPFRONT --lookback-period-in-days SIXTY_DAYS --query 'Recommendations[0].RecommendationDetails[0]'

{

"InstanceDetails": {

"DynamoDBCapacityDetails": {

"CapacityUnits": "WriteCapacityUnit",

"Region": "us-east-1"

}

"RecommendedNumberOfCapacityUnitsToPurchase": "12000",

"EstimatedMonthlySavingsAmount": "4380.00",

"EstimatedSavingsPercentage": "60.4",

"EstimatedMonthlyOnDemandCost": "7250.00",

"MinimumNumberOfCapacityUnitsUsedPerHour": "11800"

}

# Recommendation is region-scoped and per capacity type (WCU here) — and only counts PROVISIONED usage.

The recommendation is a region-wide block of one capacity type — and it only reflects tables already in provisioned mode.

Before reserving, check that the table is in provisioned mode and compare consumed throughput to what's provisioned, so you reserve the real floor and not padded headroom.

$ aws dynamodb describe-table --table-name sessions --query 'Table.{Name:TableName,Mode:BillingModeSummary.BillingMode,RCU:ProvisionedThroughput.ReadCapacityUnits,WCU:ProvisionedThroughput.WriteCapacityUnits}'

{

"Name": "sessions",

"Mode": "PROVISIONED",

"RCU": 8000,

"WCU": 12000,

}

# Mode=PROVISIONED → eligible. If this read "PAY_PER_REQUEST", reserved capacity would do nothing.

# Pull ConsumedWriteCapacityUnits from CloudWatch to confirm 12000 is the real floor, not launch-day padding.

BillingMode is the make-or-break field: PROVISIONED is eligible, PAY_PER_REQUEST (On-Demand) is not.

DynamoDB reserved capacity under the hooddeep dive

DynamoDB bills throughput in capacity units and storage separately. In provisioned mode you set Read Capacity Units (RCUs) and Write Capacity Units (WCUs) and pay an hourly rate per unit — in rough US-East terms about $0.00013 per WCU-hour and $0.00013 per RCU-hour (roughly $0.47/WCU-month and $0.09/RCU-month at standard provisioned rates). In On-Demand mode you instead pay per request (per million read/write request units) with no provisioned floor. Reserved capacity is a commitment against the provisioned hourly rate, so it can only ever match capacity units on tables running in provisioned mode — On-Demand tables bill on a different meter the reservation never touches.

A reservation is matched by just two attributes: the AWS region and the capacity type (RCU or WCU). It is not bound to a named table. AWS pools all provisioned RCUs (and, separately, all WCUs) across every table in that region and account, then applies the reserved block against that pool first, billing only the overflow at standard rates. That's why reserved capacity suits a fleet of steady, always-on tables sharing a baseline: you reserve the floor of total regional throughput, not any single table. Storage — the GB-month charge for the data itself — is on yet another meter and is never covered by reserved capacity.

This is why capacity mode and right-sizing must come before the commitment. Reserved capacity is non-refundable and matched only to provisioned usage, so committing against a table you later flip to On-Demand strands the reservation entirely. Committing before right-sizing locks in padded headroom you didn't need. And unlike EC2 or RDS, there is no rich purchase-reserved-* CLI API for DynamoDB — the buy is done through the DynamoDB console (Reserved capacity) or accepted from a Cost Explorer recommendation. The CLI's role here is analysis: surface the recommendation, confirm the mode, and measure consumed-versus-provisioned before a human commits in the console.

# Confirm the billing mode of every table before reserving anything.
# Reserved capacity ONLY applies to tables whose mode is PROVISIONED.
for t in $(aws dynamodb list-tables --query 'TableNames[]' --output text); do
  mode=$(aws dynamodb describe-table --table-name "$t" \
    --query 'Table.BillingModeSummary.BillingMode' --output text)
  echo "$t -> ${mode:-PROVISIONED}"
done

# Pull the real consumed write floor over the last 14 days (provisioned tables only),
# so you reserve the baseline rather than launch-day padding.
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB --metric-name ConsumedWriteCapacityUnits \
  --dimensions Name=TableName,Value=sessions \
  --start-time "$(date -u -d '14 days ago' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 3600 --statistics Minimum Average

# NOTE: there is no rich CLI purchase API for DynamoDB reserved capacity.
# Complete the purchase in the DynamoDB console under "Reserved capacity".

What is the impact of leaving DynamoDB uncommitted?

The direct impact is paying full standard rates on a workload that's usually one of the steadiest in the estate. At roughly $0.47 per WCU-month and $0.09 per RCU-month standard provisioned, a fleet running 12,000 WCUs and 8,000 RCUs is north of $6k/month before storage. A three-year commitment drops the throughput rate by up to ~77% — on a steady baseline that's several thousand dollars a month, tens of thousands a year, of discount that AWS offers and no one is claiming because nobody owns the DynamoDB commitment decision.

The first trap is mode. Reserved capacity does nothing for On-Demand (pay-per-request) tables, and many estates have quietly migrated their highest-volume tables to On-Demand to absorb spiky traffic. A reservation bought without checking mode matches almost nothing — you pay the upfront commitment and the full On-Demand bill side by side. The eligibility question is binary and it comes before any sizing math: a table in PAY_PER_REQUEST mode is invisible to reserved capacity no matter how much you commit.

The second trap is the stranding risk, which runs the opposite direction. Reserved capacity is non-refundable and region-and-type scoped. Commit before right-sizing and you lock in padded throughput. Commit and then flip a table to On-Demand, or move the workload to another region, and the reservation bills against nothing while the new shape pays full rate. Over-buy beyond the steady floor — reserving the peak instead of the baseline — and the unused units sit idle every hour for the full term. The deep discount and the deep trap are two sides of the same rigidity.

Finally, there's a scope surprise: reserved capacity covers throughput only, never storage. A large table with modest throughput but terabytes of data will see its throughput line drop and its storage line stay exactly where it was — so the bill moves less than a naive "77% off DynamoDB" expectation. Setting that expectation correctly matters: the reservation is a throughput instrument, and storage right-sizing (TTL, archiving cold data, table-class choice) is a separate lever entirely.

How do you commit to DynamoDB reserved capacity safely?

Buying DynamoDB reserved capacity is a four-step sequence, and the order is the whole point: confirm the tables are in provisioned mode, right-size and enable auto-scaling, reserve only the steady floor, then review coverage and utilisation every month.

1. Confirm provisioned mode BEFORE anything else

Reserved capacity does nothing for On-Demand (PAY_PER_REQUEST) tables. List every table's BillingMode and separate the provisioned, steady tables (eligible) from the On-Demand ones (not eligible — and often On-Demand for good reason, like genuinely spiky traffic). If your high-volume tables are On-Demand but their traffic is actually stable, the right first move is the capacity-mode lesson — switch them to provisioned with auto-scaling — not a reservation. Reserving against an On-Demand fleet is the single most expensive mistake in this category.

2. Right-size and enable auto-scaling, then find the floor

Reservations lock in a throughput level, so fix the level first. Pull consumed RCU/WCU from CloudWatch over the trailing 14–60 days and right-size provisioned capacity down to the real baseline, removing launch-day padding. Enable application auto-scaling so day-to-day peaks are handled above the reserved floor. The reserved block should cover the always-on baseline; auto-scaling absorbs the variable top at standard rates.

3. Reserve the stable floor, not the peak, and choose payment deliberately

Reserve roughly 80% of the steady provisioned floor in each region, per capacity type (RCU and WCU are separate), leaving the variable top uncovered so a future right-size or mode change doesn't strand units. Choose the payment option as a cash decision — more upfront deepens the discount, less upfront preserves capital — and the term (1 vs 3 years) by how confident you are the shape persists. Remember the purchase happens in the DynamoDB console (or by accepting a Cost Explorer recommendation); there's no rich CLI purchase API.

4. Review coverage and utilisation on every FinOps cadence

Track two numbers monthly: coverage (share of provisioned capacity-hours covered by a reservation on the eligible fleet) and utilisation (share of reserved units actually consumed; must stay near 100%). Watch expirations 60–90 days out so renewals are deliberate. If utilisation drops, a table was right-sized below the floor or flipped to On-Demand and stranded the reservation — investigate before buying anything new. Don't expect the storage line to move; that's a separate lever.

# Step 1: confirm eligibility — which tables are PROVISIONED (reservable) vs On-Demand?
for t in $(aws dynamodb list-tables --query 'TableNames[]' --output text); do
  mode=$(aws dynamodb describe-table --table-name "$t" \
    --query 'Table.BillingModeSummary.BillingMode' --output text)
  printf '%-30s %s\n' "$t" "${mode:-PROVISIONED}"
done

# Step 2/3: pull the Cost Explorer recommendation for the eligible provisioned baseline,
# comparing payment options before a human commits in the console.
for opt in NO_UPFRONT PARTIAL_UPFRONT ALL_UPFRONT; do
  echo "== $opt =="
  aws ce get-reservation-purchase-recommendation \
    --service "Amazon DynamoDB" \
    --term-in-years THREE_YEARS \
    --payment-option $opt \
    --lookback-period-in-days SIXTY_DAYS \
    --query 'Recommendations[0].RecommendationSummary.{Savings:TotalEstimatedMonthlySavingsAmount,Pct:TotalEstimatedMonthlySavingsPercentage}'
done

# Step 3 (purchase): no rich CLI API exists — buy in the DynamoDB console under "Reserved capacity".

Quick quiz

Question 1 of 5

Your highest-volume DynamoDB tables are in On-Demand (pay-per-request) mode to absorb spiky traffic, but analysis shows their traffic is actually steady and predictable. You want to capture the reserved-capacity discount. What's the right move?

Keep learning

Dig deeper into DynamoDB capacity modes, reserved-capacity mechanics, and how it fits the broader commitment strategy.

You've completed Purchase DynamoDB Reserved Capacity. You now know why the discount is gated entirely on capacity mode — provisioned only, never On-Demand — how reserved capacity is scoped as a region-wide pool of RCUs or WCUs that covers throughput but never storage, and the sequence that protects you: confirm provisioned mode, right-size and enable auto-scaling, reserve the stable floor, and review coverage and utilisation. You also know the buy happens in the console, not a rich CLI API. The next time the bill shows a large, uncommitted DynamoDB fleet, you'll have a defensible path from standard rates to a sound multi-year commitment without stranding a unit.

Back to the library

DynamoDB Reserved Capacity: what it means for the bill

A deep discount that's locked behind a configuration question

DynamoDB Reserved Capacity is a one- or three-year commitment to a block of database throughput in a region, in exchange for a rate cut of up to about 77% — one of the deepest commitment discounts AWS offers. It's attractive precisely because well-run DynamoDB tables are steady, always-on workloads: the kind of predictable spend that's ideal to commit against. The discount applies to throughput only; the storage line on the bill is unaffected and keeps billing at its normal rate.

The catch finance partners need to internalise is that this discount has a precondition that has nothing to do with money. It only applies to tables running in provisioned capacity mode. A large share of DynamoDB spend in many estates is in On-Demand mode — pay-per-request — and for those tables a reserved-capacity purchase is worthless; it will sit unused while the On-Demand bill keeps running at full rate. So the first question at the cost review isn't "should we reserve?" but "which of our high-volume tables are in provisioned mode with stable traffic, and have we right-sized them?"

The number to watch is DynamoDB reserved-capacity coverage and utilisation: of the provisioned RCU/WCU-hours you ran, what share were covered by a reservation, and of the capacity you reserved, what share was actually consumed. Steady provisioned tables should sit high on coverage, with utilisation near 100%. Reserved capacity is non-refundable, so an over-buy — or a buy made before tables are right-sized or migrated off On-Demand — becomes stranded waste you can't unwind.

This lesson is for the finance partner who hears "DynamoDB reserved capacity, up to 77% off" and wants to know why the team hasn't bought it yet. It walks through the prerequisite that makes the discount real or worthless — provisioned versus On-Demand mode — how coverage and utilisation behave as monthly metrics, the cash-versus-discount tradeoff in the payment options, and the sequencing rule that prevents stranded waste: fix the mode and right-size before you commit. By the end you'll know which numbers to ask for at the cost review and why a 77% discount can still be a bad buy.

Fun fact

The reservation that covered nothing

How a finance partner frames the decision

Raj is the finance partner embedded with the platform team. At the monthly review he sees $22k/month of DynamoDB spend running entirely at standard rates and asks the obvious question: "These tables have been steady for a year — why isn't any of this on a commitment with that 77% discount I keep hearing about?" The engineering lead's answer is the lesson in one line: the discount only applies to provisioned-mode tables, and some of the spend is On-Demand by design.

The conversation that follows is about prerequisites and cash, not configuration. Raj asks three things: which tables are in provisioned mode and genuinely steady, have they been right-sized first, and what's the payback on the upfront. The team confirms the core tables are provisioned, steady, and now right-sized. Finance agrees a three-year commitment fits the cash position, projecting ~60% on the covered baseline with the upfront paying back in a few months — but only on the provisioned slice, not the On-Demand table that stays uncovered on purpose.

Crucially, Raj doesn't push for 100% coverage. He agrees to reserve ~80% of the stable floor and let auto-scaling handle peaks, because reserved capacity is non-refundable — over-buy or buy ahead of a mode change and it strands. He adds two standing numbers to the cost pack: DynamoDB reserved coverage (target high on the provisioned fleet) and reserved-capacity utilisation (must stay near 100%), and he flags that the storage line is unaffected so nobody expects it to move.

Why this matters to the budget, not just the bill

The headline impact is a missed discount on a large, predictable line item. DynamoDB throughput on always-on tables is among the most committable spend you have, and reserved capacity offers up to ~77% off it — one of the deepest discounts in the AWS catalogue. Leaving a steady provisioned fleet at standard rates forgoes that discount with no engineering change required, just a purchase decision. On a six-figure annual DynamoDB bill, that's a material, recurring saving sitting uncollected.

The reason it gets missed is the eligibility gate. The discount only applies to provisioned-mode tables, and the share of spend that's On-Demand is invisible to it. So before any savings math, finance needs one fact: what proportion of DynamoDB spend is provisioned versus On-Demand? Only the provisioned, steady slice is reservable. You then need a separate coverage metric — provisioned capacity-hours covered by a reservation — and a utilisation metric — share of reserved units actually consumed. Both belong on the monthly pack as their own lines.

The payment options are a genuine cash-versus-discount tradeoff and that decision is finance's to make: more upfront means a deeper discount but a real cash outlay today, less upfront means shallower discount but no capital tied up. Term length (1 vs 3 years) is the other lever — 3-year deepens the discount but extends the lock-in. Tie the choice to cost of capital and to how confident the team is the tables will still be in provisioned mode at this shape — not to a console default. Require an explicit payback number.

The risk to guard against is over-commitment, because reserved capacity is non-refundable. A reservation bought before right-sizing, before confirming mode, or ahead of a region move becomes stranded — billing against capacity no one consumes. The protective rule finance can hold the line on: commit to roughly 80% of the stable provisioned floor only, never the peak, never On-Demand tables, and never ahead of a known change. And set expectations that storage won't move — this is a throughput discount only.

What finance can actually do about this

Finance owns the commitment decision even though it can't run the CLI or click the console buy. Four levers, used together on the monthly cadence.

1. Ask the mode question before the savings question

The 77% discount only applies to provisioned-mode tables. Before any savings math, ask what share of DynamoDB spend is provisioned versus On-Demand — only the steady provisioned slice is reservable. If the big tables are On-Demand but their traffic is genuinely stable, the right ask is a capacity-mode review, not a reservation. Reserving against On-Demand spend is locked-in waste from day one.

2. Track DynamoDB coverage as its own line, separate from Savings Plans

Savings Plans don't cover DynamoDB throughput, so it never appears in the compute commitment number. Add reserved-capacity coverage as a standalone line on the eligible provisioned fleet, and pair it with utilisation. Coverage tells you how much discount you're capturing; utilisation tells you whether you've over-bought. A steady provisioned fleet well below a healthy coverage band is uncollected discount and the prompt to act.

3. Make right-sizing and mode confirmation a precondition for any buy

Hold the line that no reserved capacity is purchased until tables are confirmed provisioned, right-sized, and on auto-scaling. Reserved capacity is non-refundable, so a premature buy is locked-in waste. "Confirm mode, right-size, then commit" protects the budget far more than chasing the deepest discount on a shape that's about to change — and require an explicit payback number on the upfront.

4. Watch utilisation and expirations, and set the storage expectation

High coverage with sagging utilisation means over-buy — reserved units billing against capacity no one consumes, worse than standard rates. Keep utilisation near 100% and put expiration dates on the finance calendar 60–90 days ahead so renewals are deliberate, never a silent lapse. And set the expectation up front that the storage line won't move — this is a throughput discount only, so storage savings need a separate lever (TTL, archiving, table class).

Quick quiz

Question 1 of 5

DynamoDB is $20k/month at standard rates on a fleet that's been steady for over a year. Someone proposes buying reserved capacity to grab the 77% discount. As the finance partner, what's the right next move?

Keep learning

Dig deeper into DynamoDB capacity modes, reserved-capacity mechanics, and how it fits the broader commitment strategy.

You've finished the finance partner's view of DynamoDB reserved capacity. You know the eligibility gate that makes the discount real or worthless — provisioned versus On-Demand mode — which two metrics to track (coverage and utilisation), how the payment options trade cash for discount depth, and the rule that prevents stranded waste: confirm mode and right-size before you commit, cover only the stable floor, and don't expect storage to move. Next time DynamoDB shows up uncommitted at the monthly review, you'll have a sharper question than "can we get the 77% discount on this?"

Back to the library

DynamoDB Reserved Capacity: the headline

One of the deepest discounts AWS offers, gated by one setting

DynamoDB is often a meaningful, very steady slice of the cloud bill, which makes it a strong candidate for a commitment discount — up to roughly 77% on throughput, deeper than most reservation programs. The headline catch is that the discount only applies to tables configured in provisioned mode; tables left in On-Demand mode get nothing from it, no matter how much you commit.

The one question worth asking: "Are our biggest, steadiest DynamoDB tables in the mode that lets us commit, and are they right-sized before we do?" The discipline this signals is whether the team is doing the unglamorous prerequisite work — choosing the right capacity mode and right-sizing — before locking in a multi-year, non-refundable commitment. A careless buy here strands money for years; a careful one banks a large, durable saving on spend that was never going to go away.

A short read for the exec who wants the headline and the single question to ask. You'll get why DynamoDB needs a deliberate, mode-aware commitment decision, what "good" coverage looks like, and the one discipline — right-size and pick the right capacity mode first — that decides whether this deep, irreversible discount creates savings or locks in waste. No commands, no internals.

Fun fact

The reservation that covered nothing

What it looks like when the org gets this right

At one company, the cost review kept surfacing a large, flat DynamoDB line that no one had ever committed against. The assumption in the room was that databases were "handled" by the company's compute Savings Plan — which, like Savings Plans generally, does nothing for DynamoDB throughput. The deep reserved-capacity discount was sitting unclaimed on a third of the database bill.

The exec sponsor changed the framing with one question: "Before we commit, are these tables in the mode and the shape we'll still be running in three years?" That forced the prerequisite work into the open. The team confirmed capacity mode, right-sized the provisioned tables, kept the genuinely spiky table on On-Demand, and only then committed to the steady baseline — banking a large, durable saving without stranding a unit.

The lasting outcome wasn't the one-time discount; it was the principle. Deep, irreversible commitments follow the prerequisite work — pick the right capacity mode, right-size, enable auto-scaling — and only then reserve the floor. The review now tracks DynamoDB coverage as its own number, and the database tier stopped being the quiet exception everyone assumed was covered.

Why this is on the report at all

DynamoDB is often one of the steadiest, most predictable cloud costs, which makes it a prime candidate for a multi-year discount of up to ~77% — deeper than most reservation programs. The reason it lands on the report is that the company-wide Savings Plan everyone relies on doesn't cover DynamoDB throughput at all, and the discount that does is gated on a configuration choice most people in the room don't track: whether the tables are in provisioned mode. An estate can look committed on its main dashboard while a deeply discountable database tier runs at full price.

The trend and the discipline behind it matter more than any single purchase. Because reserved capacity is multi-year and non-refundable, the right pattern is to confirm capacity mode, right-size, enable auto-scaling, and only then commit to the steady floor. An organisation that commits carefully after that prerequisite work banks durable savings; one that buys against On-Demand tables or ahead of a right-size locks in waste it can't escape for years. Whether DynamoDB is covered at all, and whether the prerequisite work happened first, is the tell for whether the commitment strategy is mature.

The leadership move on this category

The executive handle isn't to approve a purchase — it's to set the principle that makes the purchases sound.

1. Insist the prerequisite work happens before any commitment

Deep, non-refundable commitments should only be made on tables that are confirmed in the right capacity mode, right-sized, and stable. Make "pick the mode, right-size, then commit" a stated principle. A reservation bought against On-Demand tables or ahead of a right-size delivers little discount and locks in waste for years — worse than the missed saving it was trying to capture.

2. Require commitment coverage across all categories, not just compute

Ask for coverage of every committable category, including DynamoDB and other managed databases — not just the EC2 Savings Plan number. DynamoDB is a likely blind spot precisely because Savings Plans don't reach it and the discount is gated on a setting nobody tracks, yet it's often the steadiest spend you have.

3. Treat DynamoDB coverage as a one-minute confidence signal

"Are our steadiest tables in the mode that lets us commit, and is utilisation near 100% on what we've reserved?" is a one-line review item that tells you whether the commitment strategy is mature without any technical depth. Healthy coverage with full utilisation on a stable, right-sized provisioned fleet means the discipline is working and attention belongs elsewhere.

Quick quiz

Question 1 of 5

Your cost pack shows a large, flat DynamoDB line running entirely at standard rates, and the team is excited about a 77%-off reservation. You ask one question. What's the right read?

Keep learning

Dig deeper into DynamoDB capacity modes, reserved-capacity mechanics, and how it fits the broader commitment strategy.

That's the lesson. Two takeaways worth holding onto: DynamoDB reserved capacity is one of the deepest discounts AWS offers but it only applies to provisioned-mode tables and only to throughput, never storage — and it's multi-year and non-refundable, so it must follow the prerequisite work of picking the right capacity mode and right-sizing, never precede it. The leadership question is about coverage across all categories and the discipline behind it, not the size of any single purchase.

Back to the library

Part of the learning path Lock in your commitments

Purchase DynamoDB Reserved Capacity

DynamoDB Reserved Capacity: the basics

The reservation that covered nothing

Buying DynamoDB reserved capacity in action

DynamoDB reserved capacity under the hooddeep dive

What is the impact of leaving DynamoDB uncommitted?

How do you commit to DynamoDB reserved capacity safely?

1. Confirm provisioned mode BEFORE anything else

2. Right-size and enable auto-scaling, then find the floor

3. Reserve the stable floor, not the peak, and choose payment deliberately

4. Review coverage and utilisation on every FinOps cadence

Quick quiz

Keep learning

DynamoDB Reserved Capacity: what it means for the bill

The reservation that covered nothing

How a finance partner frames the decision

Why this matters to the budget, not just the bill

What finance can actually do about this

1. Ask the mode question before the savings question

2. Track DynamoDB coverage as its own line, separate from Savings Plans

3. Make right-sizing and mode confirmation a precondition for any buy

4. Watch utilisation and expirations, and set the storage expectation

Quick quiz

Keep learning

DynamoDB Reserved Capacity: the headline

The reservation that covered nothing

What it looks like when the org gets this right

Why this is on the report at all

The leadership move on this category

1. Insist the prerequisite work happens before any commitment

2. Require commitment coverage across all categories, not just compute

3. Treat DynamoDB coverage as a one-minute confidence signal

Quick quiz

Keep learning

Related cost lessons