Module 2: The Bedrock Cost Model
3. Bedrock quotas: the limit no bill shows
Description
Lesson 2 answered "how much does invoking Bedrock cost?" This lesson answers a different question, one no price from the previous lesson mentions: how many times per minute can you invoke it, no matter how much you're willing to pay? An AWS quota is a rate limit — not a money limit —, and Bedrock has its own quotas, documented, verified against official AWS documentation at the time of writing this guide. This lesson names them precisely, including an honesty worth stating up front: the exact number that applies to your specific account isn't published in any static document — it lives only in your own AWS account's Service Quotas console, something this $0 lab can't verify.
Connection to the module
Lessons 1 and 2 gave the complete cost model. This lesson closes the module's conceptual block with the one piece no budget, however generous, can buy: invocation speed. Lessons 4 through 6 return to executable ground — Infracost, inherited and put to the test against a real Bedrock resource.
What a quota is, and why it isn't the same as a price
A price tells you how much each unit costs. A quota tells you how many units per minute your account is allowed to consume, regardless of whether you have the money to pay for more. They're two completely independent questions: you can have a monthly budget of $10,000 without using even 1% of it, and still get a ThrottlingException error if you try to invoke a model faster than your quota allows in a specific minute. It's the same discipline of separating "how much does it cost" from "how much can I do" you already saw, under a different name, in finops-and-cost-guardrails-guide when it distinguished a resource's cost from its operational behavior under load.
TWO INDEPENDENT QUESTIONS, TWO DIFFERENT ANSWERS
"How much does one invocation cost?" --> Lesson 2 (price per token)
"How many invocations can I make
in one minute?" --> This lesson (quota)
Having leftover budget doesn't increase your quota.
Having leftover quota doesn't reduce your bill.The quota types Bedrock applies, verified against AWS Docs
Bedrock's official documentation (docs.aws.amazon.com/bedrock/latest/userguide/quotas-runtime.html, verified at the time of writing this guide) describes the bedrock-runtime endpoint's quotas — the one extract-shipment-manifest-fields uses to invoke a model — with this structure, quoted nearly verbatim:
| Quota type | Scope | What it measures |
|---|---|---|
| On-demand InvokeModel tokens per minute | Per model, per region | Input + output tokens, combined, your account can process per minute, invoking within a single region |
| Cross-Region InvokeModel tokens per minute | Per model, per region | The same measure, but for invocations through a cross-region inference profile — a separate quota from the previous one |
| Model invocation max tokens per day | Per model, per region | By default, the per-minute quota multiplied by 24 × 60 — the daily ceiling |
| InvokeModel requests per minute | Per model, per region | How many requests (not tokens) per minute — but, per official documentation, not every model has this quota: some are governed only by tokens per minute |
Notice two verified details that change how you read any quota figure you come across: first, the tokens-per-minute quota counts input and output together against a single limit — they're not two separate quotas, unlike a different Bedrock endpoint (bedrock-mantle, outside this guide's scope). Second, the quota for invocations through a cross-Region inference profile is independent of the single-region invocation quota — exhausting one doesn't exhaust the other, and vice versa.
The honest finding: the exact number isn't in any static document
This is where this lesson gets more precise than "look up the number in the documentation." An attempt was made, to write this lesson, to find the exact numeric value of the On-demand InvokeModel tokens per minute quota for Amazon Nova Lite, published in a static table. It wasn't found — and the reason is documented, it isn't an accidental gap in this guide.
The exact quote, verified against docs.aws.amazon.com/bedrock/latest/userguide/quotas-runtime.html: "RPM quotas on the bedrock-runtime endpoint are model-specific. [...] For models that do have an RPM quota, view the exact value in the Service Quotas console." Bedrock's official documentation explicitly points to your own account's Service Quotas console for the numeric value — not to a public table. And a second, even more specific quote, from docs.aws.amazon.com/nova/latest/userguide/quotas.html: "The On-demand model invocation quotas [...] aren't adjustable through Service Quotas. Contact your AWS account manager to be considered for an increase."
This confirms two things at once, verified by directly reading the documentation, not assumed:
- The exact number for your On-Demand quota is account-specific, not a universal published value — it's literally impossible to cite it precisely in a generic lesson like this one, and any tutorial citing "Nova Lite's quota is X tokens per minute" is citing, at best, a value that applied to a specific account at a specific moment.
- On-Demand invocation quotas aren't self-service. Unlike many other AWS quotas you can increase yourself from the Service Quotas console with a form, increasing Bedrock's On-Demand invocation quota requires contacting your AWS account manager — a manual process, not an automated one.
One real numeric example that IS published, to illustrate the shape of a Bedrock quota even though it's from a different category than what Andes Cargo would use in production: custom model deployment quotas, verified against the public table at docs.aws.amazon.com/general/latest/gr/bedrock.html:
| Model | Requests per minute | Tokens per minute | Tokens per day |
|---|---|---|---|
| Amazon Nova Micro / Nova Lite | 2,000 | 4,000,000 | 5,760,000,000 |
| Amazon Nova Pro | 200 | 800,000 | — |
These figures are real and public — but they're the quota for a different scenario (invoking a custom, self-hosted model deployed on top of Bedrock, not the base On-Demand model extract-shipment-manifest-fields invokes). They're cited here solely to show the shape a published Bedrock quota takes — requests/minute, tokens/minute, tokens/day, per model, per region —, not as the number that would apply to Andes Cargo.
Why this matters for extract-shipment-manifest-fields, even at low volume
ADR-001 fixes extract-shipment-manifest-fields as a low-volume escalation path — most manifests never touch it. It would be reasonable to think that, at low volume, a rate quota is never a real problem. But notice this whole lesson's key word: per minute, not per month. Low monthly volume can still bunch up in a burst: if a large logistics partner suddenly changes its shipping format, or if an incident causes many manifests to fail deterministic parsing at the same time (for example, an unannounced format change from a partner), dozens of ManifestParseFailed events could fire within the same minute — and that's where a tokens-per-minute quota, not the monthly budget, becomes the real limit.
LEFTOVER MONTHLY BUDGET EXHAUSTED PER-MINUTE QUOTA
($10,000 allocated, $40 spent) (burst of 50 invocations
in the same minute)
│ │
▼ ▼
"I have plenty of margin" ThrottlingException
-- no relationship to
available budgetThis is the exact reason for this lesson's title: no bill shows this limit. A ThrottlingException doesn't appear in Cost Explorer, doesn't appear in lesson 8's GENAI-COST-PROFILE.md, and no budget configured in Module 6 stops it. It's an availability failure, not a cost one — this guide's Module 7 revisits this distinction when it defines the AI workload's SLIs, including the block rate, a related but different concept.
Common mistakes
Assuming that, if GENAI-COST-PROFILE.md's budget has margin, any volume of invocations is going to work (cost/quota confusion mistake). What happens: someone checks the monthly budget, sees there's plenty of margin, and concludes there's no risk of extract-shipment-manifest-fields failing due to volume. How to spot it: if your only check before an expected traffic spike is the budget balance. How to fix it: budget and quota are two completely independent limits, as this lesson showed from its opening diagram. Having plenty of margin in the monthly budget says nothing about whether a burst of invocations in a specific minute is going to exceed your account's tokens-per-minute quota.
Citing a specific quota number as if it were universal, without having verified it against your own account (wrong-source mistake). What happens: someone finds, in a blog or tutorial, "Nova Lite's quota is X tokens per minute" and uses it for capacity planning without verifying it. How to spot it: if your capacity plan is based on a quota number you didn't see yourself in your own AWS account's Service Quotas console. How to fix it: this lesson showed, with the official documentation's verbatim quote, that the On-Demand quota is account-specific, not a universally published value — the only reliable source is your own Service Quotas console, never a figure cited in a third-party article.
Expecting to increase the On-Demand invocation quota with a self-service form, like other AWS quotas (expectation mistake). What happens: someone tries to raise the Bedrock quota from the Service Quotas console, using the same flow they've already used for another service, and is surprised when the option isn't available as self-service. How to spot it: if you're looking for a "Request increase" button and expecting an automatic or near-automatic approval. How to fix it: Bedrock's official documentation, cited above, is explicit — On-Demand invocation quotas aren't adjustable through Service Quotas; they require direct contact with your AWS account manager, a manual process with different timelines than a self-service form.
Exercises
Exercise 1 — Explain, without using the word "money," what a Bedrock quota measures. A colleague, after reading lesson 2 on pricing, asks what this lesson adds that the previous one didn't cover. Explain it to them without mentioning money or budget.
See solution
A quota measures allowed invocation speed, not cost — specifically, how many tokens (or, for some models, how many requests) your account can process in one minute, for a specific model and region. It's a rate limit — how much you can do in a given time —, completely separate from how much you're charged for doing it. You can have all the paying capacity in the world and still get an error if you try to invoke faster than your quota allows.
Exercise 2 — Predict what would happen, in terms of quota (not budget), if a large Andes Cargo logistics partner switched its shipping format from key=value to free text overnight, for all its shipments. Based on this lesson's "burst" diagram, describe the specific risk, distinct from the budget risk you already know from finops-and-cost-guardrails-guide's Module 6.
See solution
If that partner suddenly sends a high volume of free-text manifests in a short period (for example, batch-processing an entire day's accumulated shipments when its system starts up), process-shipment-manifest would publish many ManifestParseFailed events within a brief interval, and extract-shipment-manifest-fields would try to invoke Bedrock for almost all of them nearly simultaneously. This lesson's specific risk isn't that the monthly budget runs out (Module 6 covers that, with a different threshold) — it's that the account's tokens-per-minute quota runs out first, generating ThrottlingException on invocations that exceed that rate limit, regardless of how much budget remains available that month.
Exercise 3 — Explain why this lesson cites "custom model deployment" quota figures instead of the exact On-Demand quota Andes Cargo would use. Why did this lesson choose to show a real number from a different category, instead of simply omitting any numeric figure?
See solution
Because official documentation confirms, with a verbatim quote, that the exact On-Demand quota is account-specific and isn't published in any static table — citing an invented number for that specific quota would be exactly the kind of broken honesty this entire guide avoids. The custom model deployment figure, on the other hand, is publicly and verifiably published in official documentation — it's used here only to show the real shape a Bedrock quota takes (requests/minute, tokens/minute, tokens/day, per model), with a real, citable number, while making explicit that it isn't the figure that would apply to Andes Cargo's On-Demand scenario. It's the same discipline as the rest of this guide: show something real and verified, precisely labeled, instead of inventing the number that would be missing to complete a "cleaner" table.
Summary and next step
This lesson named Bedrock's quotas, verified against official AWS documentation: tokens per minute (input + output combined) as the main measure, requests per minute only for some models, a daily ceiling derived from the per-minute limit, and a separate quota for cross-region invocations. You confirmed the central finding, quoted verbatim: the On-Demand quota's exact numeric value isn't published in any static document — it lives in each specific account's Service Quotas console — and, unlike many other AWS quotas, it isn't adjustable via self-service.
Before moving on you should be able to: explain the difference between a cost limit and a quota limit without using the word "money"; name the four bedrock-runtime quota types cited in this lesson; and explain why "budget with margin" doesn't mean "no risk of ThrottlingException."
Lessons 4 through 6 return to executable ground: Infracost, the tool the rest of this ecosystem already trusts, put to the test against a real Bedrock resource — with that attempt's real result, whatever it turns out to be.
Resources
- AWS Docs — Quotas for the bedrock-runtime endpoint — the source for the four quota types cited in this lesson.
- AWS Docs — Quotas for Amazon Nova — the source for the quote about why On-Demand quotas aren't self-service adjustable.
- AWS General Reference — Amazon Bedrock endpoints and quotas — the public table where the custom model deployment figures cited in this lesson were verified.
- AWS Docs — Requesting a Quota Increase — the self-service process that does apply to other AWS quotas, for contrast.