Cost

Switch DynamoDB tables between on-demand and provisioned capacity

DynamoDB has two billing modes priced an order of magnitude apart, and picking the wrong one per table is one of the quietest, most common ways to overpay for a database that's working perfectly.

14 min·10 sections·AWS

Last reviewed 27 May 2026

DynamoDB capacity modes: the basics

Two ways to pay for the same table

Every DynamoDB table bills under one of two capacity modes. On-demand charges per request: roughly $0.625 per million write request units and $0.125 per million read request units in US-East, with zero capacity planning. You provision nothing and pay only for the reads and writes that actually happen. Provisioned charges for reserved throughput by the hour: about $0.00065 per write-capacity-unit-hour and $0.00013 per read-capacity-unit-hour, billed whether you use the capacity or not. The table behaves identically either way; only the meter changes.

The trade is utilisation for predictability. On-demand is the right default for spiky, new, dev/test, or unpredictable workloads: you never overpay for idle capacity and you never get throttled by a bad capacity estimate. Provisioned is far cheaper per request at steady, predictable load (roughly 3.5x cheaper per million operations when the reserved capacity is fully utilised, and 6 to 7x once you layer DynamoDB Reserved Capacity on top) because you're buying throughput wholesale instead of retail. The catch is that you pay for that reserved capacity around the clock, used or not.

The check flags tables whose billing mode doesn't match their traffic shape. The overwhelmingly common case is a high-volume, steady-state production table left on on-demand "for simplicity": running 24/7 at predictable load while paying the retail per-request rate. The fix isn't always to switch; it's to read the table's real consumed-vs-provisioned utilisation and choose deliberately. The breakeven heuristic: if sustained utilisation of the equivalent provisioned capacity would clear roughly 30%, provisioned (with auto-scaling) usually wins; below that, on-demand is both cheaper and safer.

In this lesson you'll learn the two DynamoDB billing meters and the math that separates them, how to read a table's real consumed-versus-provisioned utilisation from CloudWatch to decide which mode is cheaper, and how to switch modes safely given AWS's switch limits: you can move provisioned to on-demand up to four times in a 24-hour rolling window, and on-demand to provisioned at any time. You'll see the AWS CLI commands to inspect billing mode and consumed capacity, switch a table to provisioned, and configure auto-scaling to a sensible target utilisation, plus why DynamoDB Reserved Capacity only applies after you've moved to provisioned, which fixes the correct order of operations: choose mode, tune provisioned, then reserve the floor.

Fun fact

The 30% line that flips the answer

There's a clean breakeven hiding in DynamoDB's price sheet. A write request unit on-demand costs about $0.625 per million, so 3,600 writes cost about $0.00225; a provisioned write-capacity-unit costs about $0.00065 per hour and serves up to 3,600 writes in that hour at sustained rate. Divide $0.00065 by $0.00225 and provisioned beats on-demand once you'd sustain roughly 30% of the provisioned capacity you'd need to cover your peak. At full utilisation that's a roughly 3.5x per-unit gap on plain provisioned; layer DynamoDB Reserved Capacity on top and the gap widens to the headline 6 to 7x. Below the breakeven line on-demand is genuinely cheaper; above it provisioned with auto-scaling wins, often by a lot. The trap is that almost nobody computes the line: they pick on-demand on day one when the table is spiky and correct, then never recheck once the workload goes steady and the answer has flipped.

Switching capacity mode in action

Marcus runs the FinOps cadence at a logistics company. The dashboard flags a DynamoDB table, orders-events, at about $2,100 a month on on-demand: the single largest DynamoDB line in the account. The table backs the order-event stream, which has run steadily for eighteen months: high volume, very little day-night variation, no real spikes.

He pulls the billing mode to confirm it's on-demand, then pulls two weeks of CloudWatch ConsumedWriteCapacityUnits. The table sustains around 1,400 write units per second almost flat, with peaks barely touching 1,900. That's exactly the profile on-demand is the wrong answer for: predictable, steady, and high-volume. He sizes provisioned capacity at roughly 2,200 WCU to cover peak with headroom, then checks the math: at provisioned rates plus auto-scaling, the same throughput lands near $340 a month.

Marcus doesn't flip it blind on a Friday. He switches orders-events to provisioned with auto-scaling at a 70% target utilisation, and watches ConsumedWriteCapacityUnits against the provisioned line for a day to confirm no throttling. He knows he has a safety valve (provisioned can be switched back to on-demand up to four times in a rolling 24 hours) but he'd rather not burn throughput re-transitioning the table, so he sizes for peak with headroom and gets it right on the first move. Once it's stable, he hands the table to the commitments review so the steady floor (about 1,200 WCU that never drops) can be covered by DynamoDB Reserved Capacity for a further discount. Sequence: choose mode, tune provisioned, then reserve.

First, confirm the table's billing mode and read the recent consumed-capacity metrics DynamoDB exposes on the table itself.

$ aws dynamodb describe-table --table-name orders-events --query '{Mode:Table.BillingModeSummary.BillingMode,RCU:Table.ProvisionedThroughput.ReadCapacityUnits,WCU:Table.ProvisionedThroughput.WriteCapacityUnits,Items:Table.ItemCount}'

{

"Mode": "PAY_PER_REQUEST",

"RCU": 0,

"WCU": 0,

"Items": 184203117

}

# PAY_PER_REQUEST = on-demand. RCU/WCU read 0 because nothing is reserved.

# 184M items on a steady high-volume table - a prime provisioned candidate.

BillingModeSummary confirms on-demand; the zeroed RCU/WCU are expected for pay-per-request.

Now pull two weeks of consumed write capacity to confirm the traffic is steady: the signal that makes provisioned the cheaper choice.

$ aws cloudwatch get-metric-statistics --namespace AWS/DynamoDB --metric-name ConsumedWriteCapacityUnits --dimensions Name=TableName,Value=orders-events --start-time $(date -u -d '14 days ago' +%FT%TZ) --end-time $(date -u +%FT%TZ) --period 86400 --statistics Average Maximum

{

"Datapoints": [

{ "Timestamp": "2026-05-12T00:00:00Z", "Average": 1411.2, "Maximum": 1903.0, "Unit": "Count" },

{ "Timestamp": "2026-05-13T00:00:00Z", "Average": 1388.7, "Maximum": 1871.4, "Unit": "Count" },

{ "Timestamp": "2026-05-14T00:00:00Z", "Average": 1402.9, "Maximum": 1888.6, "Unit": "Count" }

]

}

# Avg ~1,400 WCU, peak <1,950, flat day over day - steady, predictable, provisionable.

Steady ConsumedWriteCapacityUnits with little day-to-day variance is the textbook provisioned signal.

Capacity modes under the hooddeep dive

DynamoDB measures work in capacity units. One write-capacity-unit (WCU) covers one write per second of an item up to 1 KB; one read-capacity-unit (RCU) covers one strongly-consistent read per second up to 4 KB (or two eventually-consistent reads). On-demand bills the same work as request units after the fact: a write request unit and a read request unit are the on-demand equivalents, charged per million. The physical work is identical; only the accounting differs. On-demand at roughly $0.625 per million WRU costs about $0.00225 for the 3,600 writes one provisioned WCU sustains in an hour, against $0.00065 per WCU-hour provisioned, about a 3.5x gap at full utilisation on plain provisioned. Layer DynamoDB Reserved Capacity on top of provisioned and that gap widens to the headline roughly 6 to 7x.

Switching modes is a metadata operation on the table (no data movement, no downtime) but AWS caps how often you can do it: you can switch provisioned to on-demand up to four times in a 24-hour rolling window, while on-demand to provisioned can be done at any time. The practical constraint runs in the provisioned-to-on-demand direction: if you switch to provisioned, undersize the capacity, and start throttling, you can switch back to on-demand (you have up to four such switches in a rolling 24 hours) but you'd rather not spend those transitions firefighting. So the safe pattern is to size provisioned capacity to comfortably cover observed peak, enable auto-scaling before or with the switch, and watch ConsumedWriteCapacityUnits against the provisioned ceiling before walking away. New tables can also be created on-demand and switched once they have a traffic history to size against.

Provisioned auto-scaling adjusts the reserved RCU/WCU between a min and max to track a target utilisation, typically 70%. It registers the table as a scalable target with Application Auto Scaling and attaches a target-tracking policy on DynamoDBWriteCapacityUtilization / DynamoDBReadCapacityUtilization. Set the target too high (90%+) and brief spikes throttle before scaling reacts; too low (40%) and you pay for idle headroom, eroding the advantage over on-demand. Crucially, DynamoDB Reserved Capacity (a one or three year commitment that further discounts provisioned RCU/WCU) only applies to provisioned mode, never on-demand. That fixes the order of operations: choose the mode, tune the provisioned auto-scaling, then reserve the steady floor.

# Confirm the current mode and any provisioned throughput on the table.
aws dynamodb describe-table --table-name orders-events \
  --query 'Table.{Mode:BillingModeSummary.BillingMode,RCU:ProvisionedThroughput.ReadCapacityUnits,WCU:ProvisionedThroughput.WriteCapacityUnits}'

# Pull two weeks of consumed capacity to size the switch against real peaks.
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name ConsumedReadCapacityUnits \
  --dimensions Name=TableName,Value=orders-events \
  --start-time $(date -u -d '14 days ago' +%FT%TZ) \
  --end-time $(date -u +%FT%TZ) \
  --period 3600 --statistics Average Maximum \
  --query 'Datapoints | sort_by(@,&Timestamp)[-24:]'

What is the impact of running the wrong capacity mode?

The direct cost is the multiple you pay for identical performance. A steady table sustaining 1,400 WCU and 2,000 RCU runs near $2,100 a month on-demand; the same throughput provisioned with sensible auto-scaling lands around $340. That's roughly 6x on a single table, recurring every month, with nothing visibly wrong: the database is fast and reliable the whole time. Across a fleet of mature production tables left on the default, this compounds into tens of thousands of dollars a month of pure pricing-mode overspend.

The cost runs the other way too. Putting a spiky, unpredictable, or low-volume table on provisioned is its own trap: you either oversize the reserved capacity and pay for idle headroom around the clock, or you undersize it and start throttling real traffic. You can switch a struggling table back to on-demand (up to four times in a rolling 24 hours) but each transition takes minutes and burns a re-mode you'd rather save, so the real cost is the firefighting and the throttled requests in between. "Always provisioned" is as wrong as "always on-demand." The whole point is that the right answer is per-table and depends on traffic shape.

There's a commitment interaction that surprises teams. DynamoDB Reserved Capacity discounts provisioned throughput further on a one or three year basis, but it only applies to provisioned mode. A table left on on-demand can't benefit from any reserved-capacity discount at all, so the convenience default doesn't just cost the retail per-request rate, it also locks the table out of the deepest discount tier entirely. Right-mode-first, then reserve, is the only sequence that captures both savings.

Finally, mode mismatches distort cost attribution and forecasting. On-demand cost moves directly with traffic, which looks like clean business-correlated spend, so a steady table on the wrong mode hides in plain sight as "growth." Provisioned cost is flatter and more forecastable. Getting each table onto the mode that matches its traffic shape doesn't just lower the bill; it makes the DynamoDB line predictable enough to budget against and to charge back honestly.

How do you pick and switch capacity mode safely?

Right-moding a table is a four-step loop on the FinOps cadence: read the real utilisation, decide the mode against the breakeven line, switch with auto-scaling and respect the switch-frequency limits, then reserve the steady floor.

1. Read consumed-versus-provisioned utilisation honestly

Pull at least 14 days of ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits from CloudWatch for every top-spend table. What you're looking for is the shape: steady and high (provisioned candidate), spiky or low (leave on-demand), or genuinely unpredictable (on-demand for safety). Average tells you the floor; peak tells you the capacity you must cover. Eyeballing the console cost number isn't enough; the decision lives in the traffic shape, not the dollar total.

2. Decide against the breakeven, not by gut

Apply the heuristic: if sustained utilisation of the provisioned capacity you'd need to cover peak would clear roughly 30%, provisioned with auto-scaling almost always wins; below that, on-demand is both cheaper and safer against spikes. New, low-volume, dev/test, and bursty tables belong on on-demand and should stay there; "always provisioned" is as much a mistake as "always on-demand." The output of this step is a per-table decision with the projected cost under each mode written down.

3. Switch with auto-scaling, and respect the switch-frequency limits

Switching mode is a no-downtime metadata change. On-demand to provisioned can be done at any time; provisioned to on-demand is capped at four switches in a rolling 24 hours, so you have a safety valve if a provisioned switch goes wrong, but it's not unlimited and re-transitioning takes minutes. Don't switch to provisioned with a hand-guessed capacity. Enable auto-scaling at a roughly 70% target utilisation, set min capacity near the observed floor and max comfortably above observed peak, then watch consumed-versus-provisioned for a day before walking away. Sizing for peak with headroom on the first move is exactly how you avoid spending those re-mode switches firefighting throttled traffic.

4. Reserve the steady floor, in that order

Only once a table is on provisioned and stable does DynamoDB Reserved Capacity apply: it discounts provisioned RCU/WCU on a 1 or 3 year term and never touches on-demand. So the sequence is fixed: choose mode, tune the provisioned auto-scaling to find the real floor, then buy reserved capacity to cover the part of that floor that never drops. Reserving before tuning over-commits to the wrong shape; staying on on-demand forfeits the discount entirely.

# Switch the table to provisioned with a peak-covering starting capacity.
aws dynamodb update-table \
  --table-name orders-events \
  --billing-mode PROVISIONED \
  --provisioned-throughput ReadCapacityUnits=3000,WriteCapacityUnits=2200

# Register write capacity as a scalable target, then target-track at 70%.
aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb \
  --resource-id table/orders-events \
  --scalable-dimension dynamodb:table:WriteCapacityUnits \
  --min-capacity 1200 --max-capacity 2400

aws application-autoscaling put-scaling-policy \
  --service-namespace dynamodb \
  --resource-id table/orders-events \
  --scalable-dimension dynamodb:table:WriteCapacityUnits \
  --policy-name orders-events-wcu-70 \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
    'TargetValue=70.0,PredefinedMetricSpecification={PredefinedMetricType=DynamoDBWriteCapacityUtilization}'

Quick quiz

Question 1 of 5

A production table has run 18 months at a flat ~1,400 WCU with peaks near 1,900, currently on on-demand at about $2,100/month. You also want to apply DynamoDB Reserved Capacity to lower it further. What's the right sequence?

Keep learning

Dig deeper into DynamoDB capacity modes, auto-scaling, reserved capacity, and the pricing math behind the choice.

You've completed Switch DynamoDB tables between on-demand and provisioned capacity. You now know the two billing meters and the gap between them (about 3.5x on plain provisioned at full utilisation, widening to roughly 6 to 7x once Reserved Capacity is layered on) how to read consumed-versus-provisioned utilisation to choose deliberately, the breakeven line around 30% sustained utilisation, and the safe switch path that respects the switch-frequency limits (provisioned to on-demand up to four times in a rolling 24 hours, on-demand to provisioned at any time) and auto-scales to a 70% target. Most importantly you know the sequence (choose mode, tune provisioned, then reserve the floor) so the next time the dashboard flags a steady table on on-demand you'll have a defensible path from "flagged" to "right-moded."

Back to the library

DynamoDB capacity modes: what it means for the bill

The same database, two prices, often the wrong one

DynamoDB is AWS's managed NoSQL database, and it can be billed in one of two ways. "On-demand" is pay-as-you-go: you pay for each read and write the application makes, with nothing reserved up front. "Provisioned" is more like a monthly plan: you reserve a set amount of throughput and pay for it by the hour whether the application uses it or not. The database does exactly the same job under both; the only thing that changes is how the line item is calculated.

The reason this matters for the bill is that, once you're running steadily, provisioned is several times cheaper per request: roughly three-and-a-half times at full utilisation, and six to seven times once a reserved-capacity commitment is layered on top. On-demand is the convenient default (engineers reach for it because it requires no forecasting and never throttles) and it's genuinely the right answer for new, spiky, or low-volume tables. But on a large table running predictable traffic all day, every day, paying the convenience rate is pure overspend: you could be buying the same throughput wholesale and choosing not to.

From a budgeting standpoint, the framing isn't "on-demand is bad." It's that capacity mode is a per-table decision that should be revisited as a table matures. A new table starts spiky and unpredictable, so on-demand is correct and the cost is small. Two years later it's a steady production workhorse, the traffic is forecastable, and nobody ever went back to switch it, so it's quietly costing several times what it should. The question to bring to the cost review is simple: which of our biggest DynamoDB tables are on on-demand, and have we checked whether their traffic is now steady enough to justify provisioned?

This lesson is for the finance partner who sees a DynamoDB line on the cloud bill and has no easy way to tell whether it's well-tuned or quietly overpriced. It explains why the same table can cost six times as much under one billing mode than another, what "good" utilisation looks like as a number, how the choice interacts with reserved-capacity commitments, and the three things finance can actually do (reporting, a maturity-review cadence, and sequencing) without learning any DynamoDB internals. By the end you'll know exactly what to ask for at the monthly review and how to tell whether the answer is healthy.

Fun fact

The 30% line that flips the answer

How a finance partner closes the loop

Priya is the finance partner embedded with the platform team at a logistics company. At the monthly cost review, the DynamoDB line has crept up with volume and nobody can quickly say whether that's healthy growth or waste. Priya asks the question that's now standing on the agenda: "Which of our top five DynamoDB tables are on on-demand, and for each one, is the traffic steady enough that provisioned would be cheaper?" The biggest, an order-event table, is $2,100 a month on-demand against traffic that's been flat for eighteen months.

The conversation isn't technical. Priya doesn't ask about capacity units or auto-scaling targets. She asks three things: is the traffic on this table predictable, has anyone rechecked the billing mode since the table matured, and what would it cost under the other mode. The platform lead pulls the numbers: steady traffic, never rechecked since launch, and a projected drop from $2,100 to roughly $340. That's a 6x saving on identical performance, so engineering commits to switch it the following week and recheck the rest of the top five on a maturity cadence.

Two months later the same line is materially lower and Priya has added a recurring item: a quarterly pass over the largest tables to confirm mode still matches traffic shape. She also knows the right floor isn't zero on-demand (new and spiky tables belong there) and that the real risk is a mature, steady table left on the convenience rate. The dollar saving is the headline; the discipline of rechecking as tables mature is what keeps it from coming back.

Why this matters to the budget, not just the bill

The per-table impact is large as a multiple and meaningful in aggregate. A single mis-moded production table can run 5 to 7x its necessary cost, and a portfolio of them left on the default typically represents a few percent of total cloud spend hiding inside a line that looks like normal database growth. It rarely moves a quarter on its own, but it's exactly the kind of structural overspend that's invisible until someone asks the right question, then turns out to be a clean, recurring saving.

The more important impact is on commitment economics. DynamoDB Reserved Capacity gives a further discount on provisioned throughput on a one or three year term, but it cannot be applied to on-demand at all. So a table left on the convenience mode is paying the retail rate and is structurally excluded from the deepest discount you have available. If your DynamoDB reserved-capacity utilisation or coverage looks low, the first thing to check is how much of your steady DynamoDB volume is still sitting on on-demand and therefore can't be covered.

The third impact is forecasting quality. On-demand spend tracks traffic one-for-one, so a steady table on the wrong mode shows up as smooth, business-correlated cost: the hardest kind of waste to spot, because it looks exactly like healthy growth. Moving steady tables to provisioned converts that line into a flatter, more predictable cost you can actually budget against and challenge when it moves. Better forecasting is a real second dividend on top of the headline saving.

Finally, it's a discipline signal. A portfolio where large tables get their mode rechecked as they mature, and where provisioned-then-reserved is followed in order, indicates a team that tunes cost as workloads evolve. A portfolio of mature tables all sitting on launch-day defaults predicts the same untuned pattern across other services: over-provisioned clusters, unreserved steady compute, idle capacity. Watch the share of steady DynamoDB volume still on on-demand as a leading indicator, not a target.

What finance can actually do about this

Finance can't change a table's capacity mode, but it can set the conditions that get each table onto the right one and keep it there. Three levers, used together at the cost cadence.

1. Put mode-versus-traffic on the monthly report

Add a standing line for the largest DynamoDB tables showing, for each, the billing mode and whether traffic is steady or spiky. The headline isn't the dollar total; it's how many large, steady tables are still on on-demand. That count is the leading indicator; if it isn't shrinking over a couple of cycles, the maturity-review habit isn't happening and that's the conversation.

2. Make mode review a maturity gate, not a one-off

The right trigger isn't a cleanup sprint, it's a rule: any DynamoDB table that crosses a spend or volume threshold gets its billing mode rechecked. New tables stay on on-demand without question; the recheck only fires once a table is large enough that the multiple matters. That converts the decision from "audit everything" into "the few tables where it pays" and keeps the cadence cheap.

3. Enforce the choose-then-reserve sequence

When the team brings DynamoDB Reserved Capacity to the commitments review, the precondition should be that the underlying table is already on provisioned and tuned. Reserving capacity on a table that hasn't had its mode and auto-scaling settled means committing one to three years to a shape you haven't validated. Finance owns the commitment approval, so finance can hold the order: mode first, tune second, reserve third.

4. Treat the on-demand share of steady volume as the metric

A residual of on-demand spend is correct and healthy: that's your new and spiky tables doing exactly what they should. The wrong question is "why isn't this zero?" The right one is "what fraction of our steady, high-volume DynamoDB traffic is still on on-demand?" A small and stable fraction is good; a growing one means tables are maturing onto the default and never getting rechecked.

Quick quiz

Question 1 of 5

The DynamoDB line has risen steadily with transaction volume. The platform team says that's just business growth. As the finance partner, what's the right next move?

Keep learning

Dig deeper into DynamoDB capacity modes, auto-scaling, reserved capacity, and the pricing math behind the choice.

You've finished the finance partner's view of DynamoDB capacity modes. You know why the same table can cost six times as much under one mode than the other, why on-demand cost hides as healthy growth, how the choice gates the reserved-capacity discount, and what the finance levers are: reporting the on-demand share of steady volume, a maturity-review gate, and holding the choose-then-reserve sequence. Next time the DynamoDB line rises, you'll have a sharper question than "is that just growth?"

Back to the library

DynamoDB capacity modes: the headline

A pricing-mode choice that can be 6x off and never trips an alarm

DynamoDB, one of the platform's core managed databases, can be billed two ways: pay-per-request or reserved-capacity. For steady, high-volume workloads the reserved option is several times cheaper for identical performance. Because the convenient default is the pay-per-request mode, mature production tables routinely run for years on the expensive setting with nothing visibly wrong: the database is fast, reliable, and quietly overpriced.

This is a tuning-discipline issue, not a defect. Nothing breaks if you ignore it; you simply pay a multiple of what you need to. The leadership signal is whether the org revisits these per-table decisions as workloads mature, and whether mode selection is sequenced correctly with the reserved-capacity commitments that depend on it. Getting it right is low-risk, recurring savings on infrastructure that's already running.

A short read on a recurring, low-drama category of cloud overspend, written for the exec who wants the headline and the one question to ask. You'll get the rule-of-thumb framing, what mode mismatches typically signal about wider cost-tuning discipline, and what "good" looks like at an org level: no commands, no internals.

Fun fact

The 30% line that flips the answer

What it looks like when the org gets this right

At one company the quarterly cloud review used to show DynamoDB cost rising in step with transaction volume, and everyone treated that as the cost of growth. The exec sponsor asked a sharper question: "Is that line rising because we're doing more business, or because we're paying the convenience rate on databases that have long since stopped being unpredictable?" Nobody had the answer, which was itself the finding.

Within a quarter the team had a standing practice: every large DynamoDB table gets its billing mode rechecked as it matures, steady high-volume tables move to provisioned with auto-scaling, and the predictable floor underneath them gets covered by a reserved-capacity commitment. The DynamoDB line decoupled from raw volume: it now tracked genuine business growth rather than untuned defaults. The exec hadn't asked the team to chase a number; she'd asked them to make sure each table was on the right plan for its maturity.

That's the right outcome state. The goal isn't "no tables on on-demand"; that would be wrong. The goal is "every large table is on the cheaper mode for its actual traffic shape, and the reserved commitments sit on top in the right order." The cost line stops being a mystery and becomes a confidence signal.

Why this is on the report at all

The DynamoDB number is usually a moderate line, and it tends to rise with transaction volume in a way that reads as healthy growth. The reason it's tracked is that a meaningful part of that rise can be pure pricing-mode overspend: mature, steady tables paying several times the necessary rate while looking exactly like business-correlated cost. A team that revisits mode as tables mature has a DynamoDB line that tracks real growth; a team that never does carries a structural premium hidden inside it.

There's a sequencing dimension leadership should care about, because it shows up across the whole cost program: the deepest DynamoDB discount only applies after a table is on the right mode. Choose mode, tune, then commit: get that order wrong and you either over-commit to the wrong shape or leave the discount on the table entirely. The same choose-then-commit discipline governs reserved instances and savings plans elsewhere, so it's a useful tell for whether cost tuning is mature across the board.

The leadership move on this category

The handle for an executive isn't to drive the DynamoDB dollar line; it's to set the norms that get every large table onto the right plan and keep the commitments in the right order.

1. Require mode to be revisited as workloads mature

The default choice is made when a table is new and unpredictable, and it's usually right then. The failure mode is never going back once the workload turns steady. Make "recheck billing mode when a table becomes a mature, high-volume workload" an expected practice, not a heroic audit, and most of this category never accumulates.

2. Insist on choose-then-commit ordering

Reserved capacity should only be bought against tables already on the right mode and tuned. This is the same discipline that governs reserved instances and savings plans elsewhere, so holding the line here is a cheap, visible test of whether cost commitments across the org are being made in the right order rather than reflexively.

3. Make it a confidence signal at the review

Ask one thing: "Are our largest DynamoDB tables on the cheaper mode for their actual traffic, and are the commitments sequenced after that?" A clean yes for several quarters means cost tuning is working and attention belongs elsewhere. A vague answer means mature workloads are likely sitting on untuned defaults, and probably not just in DynamoDB.

Quick quiz

Question 1 of 5

You ask whether your largest DynamoDB tables are on the cheaper mode for their traffic, and the team confirms steady tables are provisioned, spiky ones are on-demand, and reserved capacity sits on top after tuning. What's the right read?

Keep learning

Dig deeper into DynamoDB capacity modes, auto-scaling, reserved capacity, and the pricing math behind the choice.

That's the lesson. Two takeaways worth holding onto: DynamoDB can be billed two ways priced several times apart, and the convenience default quietly overcharges mature, steady tables while looking like growth. The leadership question is whether mode is revisited as workloads mature and whether commitments are sequenced after tuning, not the raw dollar figure.

Back to the library

Part of the learning path Right-size your compute

Switch DynamoDB tables between on-demand and provisioned capacity

DynamoDB capacity modes: the basics

The 30% line that flips the answer

Switching capacity mode in action

Capacity modes under the hooddeep dive

What is the impact of running the wrong capacity mode?

How do you pick and switch capacity mode safely?

1. Read consumed-versus-provisioned utilisation honestly

2. Decide against the breakeven, not by gut

3. Switch with auto-scaling, and respect the switch-frequency limits

4. Reserve the steady floor, in that order

Quick quiz

Keep learning

DynamoDB capacity modes: what it means for the bill

The 30% line that flips the answer

How a finance partner closes the loop

Why this matters to the budget, not just the bill

What finance can actually do about this

1. Put mode-versus-traffic on the monthly report

2. Make mode review a maturity gate, not a one-off

3. Enforce the choose-then-reserve sequence

4. Treat the on-demand share of steady volume as the metric

Quick quiz

Keep learning

DynamoDB capacity modes: the headline

The 30% line that flips the answer

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. Require mode to be revisited as workloads mature

2. Insist on choose-then-commit ordering

3. Make it a confidence signal at the review

Quick quiz

Keep learning

Related cost lessons