Module 2: The Bedrock Cost Model
2. How Bedrock is billed: on-demand, Provisioned Throughput, Batch, Flex, Priority
Description
Bedrock doesn't have a single pricing model — it has five, and choosing the right one for extract-shipment-manifest-fields is an architecture decision, not an administrative detail. This lesson names all five, with figures cited from AWS's official pricing page and Bedrock's public pricing catalog, verified at the time of writing this guide — never memorized from an earlier version of that page, because, as lesson 1 warned, these numbers change.
Connection to the module
Lesson 1 installed the intuition: Bedrock charges per token, not per hour. This lesson puts exact numbers to that intuition, and adds a piece lesson 1 hadn't mentioned yet: there isn't a single price per token — there are five different pricing structures, each designed for a different usage pattern. Lesson 3, immediately after, adds the piece no price covers: the limit on how much you can invoke per minute, no matter how much you're willing to pay.
The five pricing models, at a glance
BEDROCK'S FIVE PRICING MODELS
On-Demand You pay per token, when you use it. No commitment,
no reservation. This guide's default.
Batch Same as On-Demand, but processed in batch,
asynchronously (not real-time).
~50% cheaper than On-Demand.
Flex Reduced price in exchange for tolerating more
latency -- Bedrock can delay the response
if the system is busy. ~50% cheaper
than On-Demand.
Priority The opposite of Flex: you pay a premium to
guarantee lower latency under load.
~75% more expensive than On-Demand.
Provisioned Throughput You reserve dedicated capacity per hour, at a fixed
price, regardless of how many tokens you process with it.
The only one of the five that goes back to looking
like "on = costs money."On-Demand: the default, paid per real token
On-Demand is exactly what lesson 1 described: you pay, per million tokens, a separate input price and output price, with no prior commitment. You don't reserve anything, you don't commit to a minimum volume, and there's no discount for using more — every token costs the same as the one before it. It's the pricing model extract-shipment-manifest-fields uses by default in this guide, and the one lesson 7's calculator models.
Prices cited, verified against AWS's official catalog at the time of writing this guide (August 2026, us-east-1):
| Model | Input price (per 1M tokens) | Output price (per 1M tokens) |
|---|---|---|
| Amazon Nova Micro | $0.035 | $0.14 |
| Amazon Nova Lite | $0.06 | $0.24 |
| Amazon Nova Pro | $0.80 | $3.20 |
| Amazon Nova Premier | $2.50 | $12.50 |
Notice two things before continuing. First, the output price is always higher than the input price for the same model — typically 4 to 5 times higher, across the whole table above. This isn't a coincidence: generating text (output) is computationally more expensive for the model than reading it (input), and the price reflects that. Second, the difference between the cheapest model in the table (Nova Micro) and the most expensive (Nova Premier) is more than 70 times in input price, and nearly 90 times in output price — model choice, not just volume, is the biggest cost lever Andes Cargo controls, exactly the criterion Module 1, lesson 6 already installed without giving it numbers.
How this table was verified. The four Nova prices were pulled directly from AWS's public pricing catalog (the same API feeding the official pricing page), queried live on August 13, 2026 — not from a third-party tutorial or from this guide's writer's training memory. All these numbers are marked VARIABLE — they're going to change. The source to verify the current price the day you need it is always aws.amazon.com/bedrock/pricing/, never this lesson.
Batch: the same price at half the cost, no real time
Batch cuts the On-Demand price roughly in half, in exchange for one condition: processing isn't real-time — it gets submitted as an asynchronous job that Bedrock processes when it has capacity available, typically within a window of hours, not seconds. Verified against the same pricing catalog:
| Model | Batch input price (per 1M tokens) | Batch output price (per 1M tokens) | Discount vs. On-Demand |
|---|---|---|---|
| Amazon Nova Micro | $0.0175 | $0.07 | 50% |
| Amazon Nova Lite | $0.03 | $0.12 | 50% |
| Amazon Nova Pro | $0.40 | $1.60 | 50% |
| Amazon Nova Premier | — | $6.25 | 50% |
The 50% discount checks out, exactly, in every row of this table against the corresponding On-Demand row above. For extract-shipment-manifest-fields, Batch isn't a realistic option — Andes Cargo's full flow is: a free-text manifest arrives, process-shipment-manifest fails to parse it, publishes ManifestParseFailed, and extract-shipment-manifest-fields needs to respond within the same shipment-processing cycle, not hours later. Batch makes sense for workloads that do tolerate that delay — for example, if Andes Cargo ever needed to bulk-reprocess thousands of historical manifests, not manifests arriving one by one in production.
Flex: the same discount, with a different condition
Flex also cuts the price roughly in half, but with a condition different from Batch's: the request is still synchronous (you wait for the response in the same call), but Bedrock can delay it if the system is under heavy load — there's no latency guarantee. Verified against Nova Pro, the only model in the table above where an explicit Flex entry was confirmed in the catalog:
| Model | Flex input price (per 1M tokens) | Flex output price (per 1M tokens) | Discount vs. On-Demand |
|---|---|---|---|
| Amazon Nova Pro | $0.40 | $1.60 | 50% |
For a task like extract-shipment-manifest-fields — extracting fields from a manifest to finish processing a shipment — latency does matter: the shipment is waiting on that result to continue its flow. Flex would be reasonable if Andes Cargo decided, later, that the escalation path can tolerate a few extra seconds of delay in exchange for half the cost — a business decision, not a technical one, that this guide names without making it.
Priority: the premium for guaranteed lower latency
Priority is the opposite of Flex: it pays a premium — verified at +75% over the On-Demand price — in exchange for higher priority in Bedrock's processing queue, with lower expected latency under load.
| Model | Priority input price (per 1M tokens) | Priority output price (per 1M tokens) | Premium vs. On-Demand |
|---|---|---|---|
| Amazon Nova Pro | $1.40 | $5.60 | +75% |
| Amazon Nova Premier | $4.375 | $21.875 | +75% |
The +75% checks out exactly on both rows: $0.80 × 1.75 = $1.40 (Nova Pro, input); $3.20 × 1.75 = $5.60 (Nova Pro, output). Priority would make sense if extract-shipment-manifest-fields ever became part of a flow with a strict, contractual latency SLA — for example, if a large logistics partner required guaranteed shipment confirmation in under a second. With Andes Cargo's current volume and criticality (an escalation path, not the default, per ADR-001), paying a 75% premium for a latency guarantee isn't justified yet — another decision this guide names, without making it for Andes Cargo.
Provisioned Throughput: the only one that goes back to "on = costs money"
Provisioned Throughput breaks the pattern of the other four: instead of paying per token, you reserve dedicated compute capacity — measured in "Model Units" — per hour, at a fixed price that doesn't depend on how many tokens you process with that capacity. It's, of the five, the only Bedrock pricing model that resembles what EC2 already taught you: you pay for the time the capacity exists, whether you use it or not.
Prices cited, verified against the official catalog (per Model Unit, per hour, us-east-1, identical at this moment for Nova Micro, Nova Lite, and Nova Pro):
| Commitment | Price per Model Unit / hour |
|---|---|
| No commitment | $60.50 |
| 1-month commitment | $55.00 |
| 6-month commitment | $30.25 |
Notice something real and verified: the three Nova models in this table — Micro, Lite, and Pro, with On-Demand prices that differ by up to 20 times from each other — have exactly the same Provisioned Throughput price per Model Unit. This makes sense once you understand what you're buying: you're not buying "tokens from a specific model at a different price," you're buying dedicated compute capacity — the price per hour reflects the cost of that reserved capacity, not the model running on top of it. Provisioned Throughput makes sense when sustained invocation volume is high enough that the cost per reserved hour ends up lower than the sum of thousands of On-Demand invocations — this guide's Module 6, lesson 7 comes back to this comparison with real numbers applied to Andes Cargo's specific volume.
When each one makes sense: the criterion, not the fad
WHICH PRICING MODEL SHOULD YOU CHOOSE?
Does it need a real-time (synchronous) response?
│
NO ────────────► Batch (~50% cheaper, hours of wait OK)
│
YES
│
Does it tolerate variable latency under load?
│
YES ────────────► Flex (~50% cheaper, no latency guarantee)
│
NO
│
Does sustained volume justify reserved capacity?
│
YES ────────────► Provisioned Throughput (fixed price per hour,
│ regardless of volume -- Module 6 does the
│ exact math on where that point sits)
│
NO
│
Is there a contractual minimum-latency SLA?
│
YES ────────────► Priority (+75%, guarantees queue priority)
│
NO
│
▼
On-Demand (this guide's default for extract-shipment-manifest-fields)For extract-shipment-manifest-fields, exactly as ADR-001 defined it — a synchronous escalation path, low initial volume, no contractual SLA yet —, On-Demand is the right decision, and it's the one lesson 7's calculator and lesson 8's GENAI-COST-PROFILE.md use as their baseline. This isn't a permanent choice: if volume grew enough, Provisioned Throughput would enter the conversation with real numbers, exactly as Module 6, lesson 7 develops it.
Common mistakes
Assuming Batch and Flex are interchangeable because both give ~50% off (oversimplification mistake). What happens: someone reads "both are ~50% cheaper" and concludes they're the same option under a different name. How to spot it: if your question is "which one do I use, Batch or Flex?", without considering the mechanism difference. How to fix it: Batch is asynchronous (you submit a job, you pick it up hours later); Flex is synchronous with variable latency (you wait for the response in the same call, but it may take longer under load). For extract-shipment-manifest-fields, which needs to respond within the same shipment-processing flow, Batch is ruled out by design — Flex remains, at least technically, a synchronous option.
Thinking Provisioned Throughput is always more expensive because "reserving" sounds like over-committing (intuition-without-numbers mistake). What happens: someone dismisses Provisioned Throughput outright, assuming paying for a reserved hour always costs more than paying only for what you use. How to spot it: if your reasoning is "paying upfront is always worse than paying per use," without having crossed the numbers. How to fix it: at sufficiently high, sustained volume, the total cost of thousands of On-Demand invocations can exceed the cost of capacity reserved per hour — it's exactly the same logic you already saw with EC2 reserved instances versus on-demand, applied here to Bedrock. The crossover point depends on real volume, not a general rule; Module 6, lesson 7 does that math with Andes Cargo's numbers.
Memorizing this lesson's numbers as if they were permanent (expectation mistake, the same one Module 1's lesson 6 already named for the model catalog). What happens: someone, months after reading this guide, is still citing "$0.06 per million input tokens for Nova Lite" as if it were a fixed fact. How to spot it: if you're making a real budget decision based on a number from this lesson without having verified it again. How to fix it: every price in this lesson is marked VARIABLE for an explicit reason — check against aws.amazon.com/bedrock/pricing/ the day you need the real number, exactly the same discipline finops-and-cost-guardrails-guide already required for S3, Lambda, and DynamoDB prices.
Exercises
Exercise 1 — Calculate, without lesson 7's calculator, the exact Batch discount on Nova Lite. Using this lesson's On-Demand table and Batch table, calculate the exact discount percentage for Nova Lite's input price in Batch versus On-Demand. Does it match the cited 50%?
See solution
On-Demand, input, Nova Lite: $0.06 per million tokens. Batch, input, Nova Lite: $0.03 per million tokens. $0.03 / $0.06 = 0.5, meaning exactly 50% of the On-Demand price — a 50% discount, matching exactly what was cited. The same proportion holds in the output column ($0.24 → $0.12) and in the table's other Nova rows — the 50% isn't a marketing approximation, it's the real, consistent proportion across the whole verified catalog.
Exercise 2 — Explain, in your own words, why Nova Micro, Nova Lite, and Nova Pro share the same Provisioned Throughput price per hour, despite having very different On-Demand prices from each other. A colleague, looking at the Provisioned Throughput table, asks why the larger model (Nova Pro) doesn't cost more per reserved hour than the smaller one (Nova Micro). Explain the reason to them.
See solution
Provisioned Throughput doesn't sell "tokens from a specific model" — it sells dedicated compute capacity, measured in Model Units, independent of which model runs on that capacity. The price per Model Unit per hour reflects the cost of that reserved infrastructure, not the size or capability differences between Nova Micro and Nova Pro. The difference between those models, in a Provisioned Throughput scenario, would show up in how many Model Units each one needs to sustain the same volume of tokens per minute (a larger model probably needs more Model Units for the same throughput), not in a different price per unit.
Exercise 3 — Justify, citing ADR-001, why this lesson chooses On-Demand as extract-shipment-manifest-fields's pricing model, and not Priority. Someone on Andes Cargo's team proposes using Priority from day one, "so shipments with free-text manifests get processed faster." Use ADR-001's criterion to answer whether that's justified today.
See solution
ADR-001 explicitly defines extract-shipment-manifest-fields as an escalation path, not the default — it's invoked only when the deterministic parser has already failed, and is expected to be a minority fraction of total manifest traffic. Priority makes sense when there's a contractual minimum-latency SLA that justifies paying a 75% premium — Andes Cargo, at this guide's current state, has no such contractual commitment declared in any previous document. Paying for Priority "just in case" directly contradicts ADR-001's discipline: this guide's whole architecture decision is to avoid overspending on the path that's already, by design, the most expensive in the system. The correct answer is to start with On-Demand, and reconsider Priority only if a real, evidenced requirement for guaranteed latency shows up — not before.
Summary and next step
This lesson cited Bedrock's five real pricing models, with figures verified live against AWS's official catalog: On-Demand (the default, paid per token, no commitment), Batch (~50% cheaper, asynchronous), Flex (~50% cheaper, variable latency), Priority (+75%, guaranteed priority), and Provisioned Throughput (fixed price per hour of reserved capacity, the only one that goes back to looking like "on = costs money"). You confirmed, with the exact table, that On-Demand is the right decision for extract-shipment-manifest-fields per ADR-001's criterion — an escalation path, not a service with a contractual SLA yet.
Before moving on you should be able to: name the five pricing models and the usage pattern each one favors; calculate, given an On-Demand price, the approximate Batch/Flex/Priority price without consulting a table; and explain why Provisioned Throughput is the only one of the five that doesn't depend on each individual invocation's content.
Lesson 3 adds the piece no pricing model in this lesson covers: the limit on how many invocations per minute your account can make, no matter how much you're willing to pay — the limit no bill shows.
Resources
- AWS — Amazon Bedrock Pricing — the official source for all this lesson's prices; check here for the current number before any real decision.
- AWS Price List API — Amazon Bedrock — the programmatic pricing catalog, the primary source queried for this lesson's Nova prices (
us-east-1, published 2026-08-13). - AWS Docs — Increase model invocation capacity with Provisioned Throughput in Amazon Bedrock — official Provisioned Throughput reference, revisited with applied numbers in Module 6, lesson 7.
- This module, lesson 1 — the roaming analogy this lesson puts numbers to.