Module 6: Finops For Tokens
7. On-demand vs. Provisioned Throughput: when to use each, with real numbers
Description
This guide's Module 2, lesson 2 already cited Bedrock's five pricing models, including Provisioned Throughput — the only one that "goes back to looking like on = costs money" — with a qualitative criterion: it makes sense "when sustained volume is high enough that the cost of reserved hourly capacity ends up lower than the sum of thousands of On-Demand invocations." This lesson puts an exact number on that sentence, verified at this very moment against AWS's official pricing catalog — not memorized from an earlier version of this guide — and applies it to extract-shipment-manifest-fields's real usage profile.
Connection to the module
This is the module's only purely conceptual lesson, but with the same real-numbers discipline every lesson in this guide requires. It picks up the On-Demand pricing table from Module 2, lesson 2, the aws_bedrock_provisioned_model_throughput this module's lesson 2 already confirmed as a real Terraform resource, and the two volume assumptions (GENAI-COST-PROFILE.md, section 4) plus lesson 6's disproportionate scenario — to calculate, with verifiable arithmetic, exactly how far Andes Cargo is today from Provisioned Throughput being the right decision.
Analogy: the monthly transit pass, not the per-ride ticket
You already know the taxi meter that doesn't even know how many rides you'll take (lesson 2) — the metaphor for On-Demand. Provisioned Throughput is a transit line's monthly pass: you pay a fixed fee, no matter how many rides you take that month, and that fee is worth it only if you're going to ride enough that the individual per-ride cost, summed up, exceeds the pass's price. Nobody buys a monthly pass to ride twice a month — the loose ticket comes out cheaper in that case, even though the pass "feels" more professional or more predictable. The question this lesson answers with numbers is exactly that: how many "rides" (invocations) per month would Andes Cargo need for the pass (Provisioned Throughput) to start beating the loose ticket (On-Demand)?
The numbers, verified at this very moment
The two prices this comparison needs, both verified live against AWS's public pricing catalog (the same API that feeds aws.amazon.com/bedrock/pricing/), checked the same day this lesson was written — marked VARIABLE, not permanent, the exact same discipline as Module 2, lesson 2:
On-Demand, Amazon Nova Lite (us-east-1):
| Axis | Price |
|---|---|
| Input | $0.06 per 1M tokens |
| Output | $0.24 per 1M tokens |
Provisioned Throughput, per Model Unit / hour (us-east-1, identical for Nova Micro, Nova Lite, and Nova Pro):
| Commitment | Price per MU/hour |
|---|---|
| No commitment | $60.50 |
| 1-month commitment | $55.00 |
| 6-month commitment | $30.25 |
The two On-Demand prices are identical to what Module 2, lesson 2 already cited. All three Provisioned Throughput prices also match, exactly, what that lesson previewed — confirmed again here, not recycled without checking, because a decision of this magnitude deserves its own verification, not a memory citation from an earlier module.
The crossing point: how many invocations/month Andes Cargo would need
The exact question: at what monthly invocation volume (with extract-shipment-manifest-fields's token size: 800 input tokens, 150 output, GENAI-COST-PROFILE.md section 4) does the total On-Demand cost equal the cost of reserving a single Model Unit, running the full thirty days of the month?
python3 -c "
cost_per_request = (800 * 0.06 + 150 * 0.24) / 1_000_000
no_commit_month = 60.50 * 24 * 30
six_month_month = 30.25 * 24 * 30
print(f'On-Demand cost per invocation: \${cost_per_request:.6f}')
print(f'1 MU, no commitment, 1 month: \${no_commit_month:,.2f}')
print(f'1 MU, 6-month commitment, 1 month: \${six_month_month:,.2f}')
print(f'crossing point, no commitment: {no_commit_month/cost_per_request:,.0f} invocations/month')
print(f'crossing point, 6 months: {six_month_month/cost_per_request:,.0f} invocations/month')
"What to expect (literal — executed to write this lesson):
On-Demand cost per invocation: $0.000084
1 MU, no commitment, 1 month: $43,560.00
1 MU, 6-month commitment, 1 month: $21,780.00
crossing point, no commitment: 518,571,429 invocations/month
crossing point, 6 months: 259,285,714 invocations/month
Also verified with Module 2's own calculator (scripts/bedrock_cost_estimate.py), run exactly at the 6-month commitment's crossing point:
python3 bedrock_cost_estimate.py \
--model amazon.nova-lite-v1:0 --input-tokens 800 --output-tokens 150 \
--monthly-requests 259285714What to expect (literal):
Model amazon.nova-lite-v1:0
Input tokens / request 800
Output tokens / request 150
Monthly requests (declared) 259,285,714
Monthly input tokens 207,428,571,200
Monthly output tokens 38,892,857,100
Input cost ($0.0600/1M tok) $12,445.71
Output cost ($0.2400/1M tok) $9,334.29
----------------------------------------------------
TOTAL MONTHLY COST $21,780.00
$21,780.00 — exact, matching, two independent calculation paths (direct arithmetic and Module 2's calculator) confirming the same number. 259 million invocations a month is the point at which 1 Model Unit, at the cheapest possible commitment (6 months), starts costing the same as staying on On-Demand.
Compared against Andes Cargo's real volumes
VOLUME SCALE, ANDES CARGO vs. THE CROSSING POINT
Realistic (GENAI-COST-PROFILE.md §4) 40 / month
Stress (GENAI-COST-PROFILE.md §4) 5,000 / month
Disproportionate (M6.6, deliberate) 100,000 / month
│
│ 2,593x away
▼
Crossing point (6-month commitment) 259,285,714 / month
Crossing point (no commitment) 518,571,429 / monthEven lesson 6's deliberately disproportionate scenario — a hundred thousand invocations a month, twenty-five times the original stress scenario — is 2,593 times below the point where the cheapest possible Provisioned Throughput would start paying off. Put another way: Andes Cargo would need each of its current manifests (~400/month, COST-PROFILE.md section 4) to multiply by more than 648,000, or dozens of companies Andes Cargo's size to route manifests through the same model, for this decision to even enter serious discussion with today's numbers.
This number's honesty: what it DOES measure, and what it does NOT
This comparison is intentionally conservative in one specific sense, and it's worth stating precisely: it's a purely dollar-based comparison — how much it would theoretically cost to serve that volume with 1 MU versus serving it On-Demand — not confirmation that 1 Nova Lite Model Unit can physically process 259 million invocations a month. AWS's official documentation (docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html) is explicit on one point: the exact throughput a Model Unit delivers — how many input and output tokens per minute — isn't published; that same document points to "contact your AWS account manager" for that figure. This means the real crossing point could require more than one Model Unit to sustain that volume — which would only push the crossing point even further away, never closer — so this lesson's conclusion (Provisioned Throughput isn't a real decision for Andes Cargo today) stands, if anything, reinforced by this limitation, not weakened.
WHAT THIS COMPARISON VERIFIES WHAT IT CANNOT VERIFY
The $ cost of reserving 1 MU How many invocations/minute
per month, at each commitment level 1 MU delivers in practice
(verified, public catalog) (not published -- "contact
│ your account manager")
▼ │
The $ cost of serving a given ▼
volume On-Demand, at this If the real volume needed
workload's real token size MORE than 1 MU, the crossing
│ point would be EVEN HIGHER --
▼ never lower
The $ crossing point, with the
assumption most favorable to
Provisioned Throughput (a single MU)Decision criterion, in one sentence
Provisioned Throughput stops being a theoretical curiosity and becomes a serious decision when sustained volume — not an occasional spike — approaches, even within an order of magnitude, the crossing point calculated against the longest available commitment (the cheapest per hour). For extract-shipment-manifest-fields, as ADR-001 defined it — an escalation path, a minority of total traffic —, that point is more than three orders of magnitude away from the most pessimistic scenario this guide considered. The right decision for Andes Cargo, today, is still On-Demand — the same conclusion from Module 2, lesson 2, now backed by the exact number measuring how far that alternative is from becoming relevant.
Common mistakes
Comparing Provisioned Throughput's hourly price directly against the On-Demand monthly cost, without converting both to the same time unit (a units mistake). What happens: someone compares $60.50 (per hour) against $0.42 (the stress scenario's monthly On-Demand cost) and incorrectly concludes Provisioned Throughput is "obviously" more expensive by a huge factor, without considering that $60.50 is per hour, not per month. How to spot it: if your comparison mixes an hourly figure with a monthly figure without converting. How to fix it: always multiply the hourly price by the commitment period's real hours (24 × 30 for a month, as this lesson does explicitly) before comparing against any monthly figure.
Assuming 1 Model Unit is enough for any volume, without considering that the real throughput per MU isn't published (over-simplification). What happens: someone concludes, from this lesson, that "259 million invocations/month with 1 MU" is a confirmed fact about capacity, not just about cost. How to spot it: if you cite this lesson's crossing point as a guarantee that 1 MU can actually serve that volume. How to fix it: this lesson's honesty section explicitly clarifies this — the number is a cost floor, with the most favorable possible assumption (a single MU); AWS doesn't publish the real throughput per MU, so the volume a single unit can physically handle could be much lower, which would move the crossing point upward, not downward.
Citing this lesson's prices months later without checking them again (the same mistake, in a new domain, Module 2 already named several times). What happens: someone uses $60.50/$55.00/$30.25 as if they were permanent. How to spot it: if you're making a real budget decision based on a price from this lesson without having reviewed it again. How to fix it: always verify against aws.amazon.com/bedrock/pricing/ on the day you need the real number — the exact same discipline every cited price in this guide requires.
Exercises
Exercise 1 — Calculate the crossing point with the 1-month commitment ($55.00/MU/hour), and place it on this lesson's scale. Is it closer to or farther from lesson 6's disproportionate volume than the 6-month crossing point?
See solution
$55.00 × 24 × 30 = $39,600.00 per month; $39,600.00 / $0.000084 ≈ 471,428,571 invocations/month — farther than the 6-month crossing point (259,285,714), because a shorter commitment costs more per hour, so an even larger volume is needed to justify it. The relationship stays consistent: the longer the commitment, the cheaper per hour, and the lower (more reachable, though still astronomical for Andes Cargo) the crossing point.
Exercise 2 — If Andes Cargo chose Nova Micro instead of Nova Lite (lower On-Demand price, same Provisioned Throughput price per this module's lesson 2), would the crossing point go up or down? Justify without recalculating everything, using the formula's logic.
See solution
It would go up (an even larger volume would be needed). The crossing point is MU_monthly_cost / cost_per_invocation; if the cost per invocation drops (Nova Micro is cheaper than Nova Lite On-Demand, Module 2, lesson 2) while Provisioned Throughput's cost per MU stays the same (this guide's Module 6, lesson 2 already confirmed all three Nova models share the same price per MU), the fraction's denominator drops, so the result — the crossing point — goes up. A cheaper On-Demand model makes Provisioned Throughput an even more distant decision.
Exercise 3 — Explain why this lesson uses "a single Model Unit" as its assumption, instead of calculating how many MUs Andes Cargo would actually need for its real volume. Why doesn't that simplification invalidate the lesson's conclusion?
See solution
Because the exact number of tokens/minute a Model Unit delivers isn't published (this lesson's honesty section already cites this, straight from AWS's official documentation). Using 1 MU is the assumption most favorable possible to Provisioned Throughput — the cost floor: if the real volume needed 2, 5, or 50 MUs to sustain the required throughput, Provisioned Throughput's monthly cost would multiply by that same amount, pushing the crossing point even further from Andes Cargo's real volume. Since this lesson's conclusion (On-Demand is still correct, by a margin of more than three orders of magnitude) already holds under the assumption most favorable to the alternative, any more realistic assumption would only reinforce that same conclusion — never reverse it.
Summary and next step
This lesson calculated, with prices verified live and arithmetic verifiable along two independent paths, the exact point where Provisioned Throughput would start beating On-Demand for extract-shipment-manifest-fields: between 259 and 519 million invocations a month, depending on the chosen commitment. Compared against the three volume scenarios this guide already considered — 40, 5,000, and lesson 6's deliberately disproportionate 100,000 — the minimum distance is more than 2,500 times. The conclusion — On-Demand is still the right decision — holds even under the most favorable possible assumption for the alternative (a single Model Unit), because AWS doesn't publish the real throughput per MU and any realistic adjustment would only push the crossing point further away.
Before moving on you should be able to: calculate the crossing point between On-Demand and Provisioned Throughput for any combination of price and token size; explain why this lesson's number is a cost floor, not a capacity guarantee; and defend, with the complete scale drawn in this lesson, why On-Demand is still correct for Andes Cargo today.
Lesson 8, the project that closes this module, brings all the pieces together — bedrock-budget.rego, the calculator with a budget, the complete tagging — in a real act pull_request run, in parallel with Module 5's security gate.
Resources
- AWS — Amazon Bedrock Pricing — the official source for every price in this lesson; check the current number here before any real decision.
- AWS Docs — Increase model invocation capacity with Provisioned Throughput in Amazon Bedrock — the source for the limitation cited in the honesty section: throughput per MU isn't published.
- Terraform Registry —
aws_bedrock_provisioned_model_throughput— the real resource confirmed in this guide's Module 6, lesson 2, withmodel_unitsas its central attribute. - This module, lesson 2 — the origin of the contrast between reserved capacity (Provisioned Throughput) and invocation (on-demand, with no equivalent resource), which this lesson turns into numbers.