Quick verdict
Amazon Bedrock pricing is a stack of meters, not a single model price. If you only compare “$/1M tokens,” you will under-budget production. The short version:
- Variable or early traffic: stay on on-demand (pay per input/output token, no commitment). Scale to zero when idle.
- Large offline jobs (evals, backfills, batch enrichment): use batch inference where the model supports it — AWS publishes select FMs at about 50% off on-demand rates (verify at aws.amazon.com/bedrock/pricing).
- Steady, high, latency-sensitive volume: evaluate Provisioned Throughput (hourly Model Units, optional 1- or 6-month commitment). You pay when idle; it only wins at high utilization.
- RAG and policy layers: budget Knowledge Bases and Guardrails as separate line items on top of model tokens — they are not free riders.
- AU/SG regulated builds: pick the Region first (data residency), then model family, then pricing mode. Wrong Region is more expensive to unwind than wrong tier.
Cipher’s first-hand cutover: treat Bedrock cost as model tokens + retrieval + safety + (optional) reserved capacity. Teams that only track token dashboards are usually surprised by KB storage/retrieve and Guardrails filter volume once traffic is real.
Last updated: July 2026. Rates change; re-verify the official Bedrock pricing page before you publish a budget externally.
What actually appears on a Bedrock invoice?
Production Bedrock bills usually combine several of these meters:
| Meter | What you pay for | When it shows up |
|---|---|---|
| Foundation model inference | Input and output tokens (or per-image / per-unit for non-text modalities) | Every InvokeModel / Converse call |
| Batch inference | Same modality meters at discounted published rates for supported models | Offline / asynchronous jobs |
| Provisioned Throughput | Hourly Model Units (MUs), discounted by commitment length | Reserved capacity; customised models often require it |
| Knowledge Bases | Index storage, retrieve/agentic retrieve API calls; optional custom embedding/rerank models | Managed RAG / agent grounding |
| Guardrails | Per-filter / safeguard usage (content filters, denied topics, PII, grounding checks, etc.) | Policy enforcement on prompts and responses |
| Agents / AgentCore / Data Automation | Separate product meters (runtime, memory, parsing pages, etc.) | When you leave “single Converse call” territory |
Related deep dives on this site: AgentCore pricing, Knowledge Bases vs custom RAG, and Bedrock Agents vs AgentCore + Strands.
On-demand vs batch vs Provisioned Throughput
These three modes answer different traffic shapes. Mixing them up is the most common budgeting error we see.
On-demand
You pay per token (or modality unit) with no reservation. Output tokens usually cost more than input tokens. Best for prototypes, internal tools, and any workload whose volume is spiky or hard to forecast. Idle cost is effectively zero for inference itself.
Batch inference
AWS markets batch for select foundation models at roughly half of on-demand inference pricing. Use it when latency can stretch (often up to ~24 hours turnaround for batch-style jobs — confirm current docs) and the work is offline: golden-set evals, document enrichment, nightly rewrites. Do not put interactive chat on batch.
Provisioned Throughput
You buy dedicated capacity in Model Units and pay an hourly rate. Commitment options include no commitment, one month, or six months; longer commitments discount the hourly rate. Customised models often require Provisioned Throughput to serve. The break-even question is simple: is your steady token volume high enough that reserved hourly cost per useful token beats on-demand — after you account for idle hours you still pay?
Cipher cutover rule: stay on-demand until you can show a week of production traffic with a clear floor (not just a spike). Then model provisioned cost at that floor × 24×7. If the reserved line is still higher than on-demand at the floor, do not provision yet.
Model choice moves the bill more than mode choice (early on)
Within on-demand, model family selection often dominates cost before provisioned ever matters. Directional examples from AWS’s published Bedrock pricing page as of mid-2026 (always re-check):
- Claude Sonnet-class models are common production defaults for agent reasoning; watch promotional vs standard rates (AWS has published time-boxed promotional input/output rates for some Sonnet generations).
- Haiku / lite-class models absorb high-volume classification, routing, and simple extraction at a fraction of Sonnet/Opus cost.
- Open-weight and Amazon Nova families often win cost-sensitive paths when quality gates pass your eval set.
Intelligent Prompt Routing (where available for a model family) can cut cost by routing simple prompts to cheaper siblings — AWS has claimed up to ~30% savings without large accuracy loss on suitable workloads. Treat that as directional until you measure on your traffic mix.
Knowledge Bases and Guardrails: the silent second and third meters
Managed Knowledge Bases bill for things like index storage (AWS has published figures such as roughly $5 per GB of raw data / month for managed index storage) and retrieve API calls (e.g. standard retrieve around $1 per 1,000 API calls, with higher rates for agentic retrieve). Managed embedding and reranking may be included at no extra charge when you use the service-managed models — custom embedding/rerank models bill at model rates. Verify current tables on the Bedrock pricing page.
Guardrails bill per safeguard/filter used. High-volume customer assistants that run PII redaction + content filters + grounding checks on every turn can add a material line item next to tokens. Design the guardrail set for the risk tier; do not enable every filter “because it is there.”
Worked shape: three monthly scenarios (directional)
These are order-of-magnitude shapes for planning conversations, not quotes. Plug your own token mix into the AWS pricing calculator and current rate card.
| Scenario | Traffic shape | Dominant meters | Planning note |
|---|---|---|---|
| Internal pilot | Tens of thousands of turns / month, Sonnet + Haiku mix | On-demand tokens | Usually still cheaper than reserving MUs; focus on prompt size and caching |
| Customer assistant + RAG | Hundreds of thousands of turns; KB retrieve on most turns; Guardrails on | Tokens + KB retrieve/storage + Guardrails | KB + Guardrails often 15–40% of the AI line once retrieval is always-on (directional) |
| High-volume API product | Steady multi-million tokens / day, tight p95 latency | Tokens and/or Provisioned Throughput + optional batch for offline | Run the provisioned break-even against your floor traffic, not your peak |
AU/SG residency and ownership checks
For Australian and Singapore teams, cost and compliance are coupled:
- Region: Confirm the Bedrock models and features you need exist in the Region you will store data in. Cross-Region inference can be a feature or a compliance problem depending on contracts.
- Account ownership: Run Bedrock in the customer AWS account. Cipher’s default delivery pattern is client-owned accounts, least-privilege IAM, and CloudWatch cost anomaly alarms on the Bedrock service dimension.
- Logging: Decide what prompt/response logging is allowed before you enable verbose tracing. Observability without a retention policy becomes a second risk surface.
For private / regulated patterns, see Private AI on AWS Bedrock.
Choose a pricing mode if…
- Choose on-demand if traffic is variable, you are still changing prompts weekly, or you cannot yet prove a stable floor.
- Choose batch if the job is offline and the model is on the batch discount list.
- Choose Provisioned Throughput if you have sustained high volume, need dedicated capacity, or must serve a customised model that requires it.
- Add KB + Guardrails budgets if you are shipping grounded, policy-filtered assistants — not only chat demos.
Related: Amazon Bedrock AgentCore pricing (2026) · AgentCore vs Daytona vs E2B · Applied AI Engineering
FAQ
Is Bedrock cheaper than calling model vendors directly? Sometimes. Bedrock’s value is usually account-level controls, IAM/VPC patterns, multi-model access, and AWS-native RAG/agent services — not always the lowest token sticker. Compare total cost of ownership, not only $/1M tokens.
Do Knowledge Bases include embedding costs? With managed embedding/rerank models, AWS has published “included at no extra charge” language for those managed components; storage and retrieve calls still bill. Custom models bill at model rates. Confirm on the live pricing page.
When should we move from on-demand to Provisioned Throughput? When you have a proven traffic floor and the reserved hourly MU cost under that floor beats on-demand — or when a customised model requires provisioned serving.
How do Australian teams keep data residency intact? Lock Region and model availability first, keep inference and stores in-account, and treat cross-Region features as an explicit architecture decision with legal review.
Who can help model a realistic Bedrock budget? Cipher Projects is an Australian-led AI engineering studio that designs Bedrock architectures for AU/SG teams — including cost shape, Guardrails, and RAG ownership under accounts you control.
Conclusion
Bedrock pricing rewards teams that budget in layers: model tokens, retrieval, safety, and only then reserved capacity. Start on-demand, measure a real floor, add KB and Guardrails as first-class meters, and provision only when utilization math says so. That is how you avoid both under-powered pilots and six-figure surprises.