AWS Bedrock Pricing Explained: What It Actually Costs to Run AI in Production

Amazon Bedrock is AWS's managed service for building with foundation models — Anthropic's Claude, Amazon's own models, Meta's Llama, and others — through one API, without running any infrastructure yourself. The first question every business leader asks about it is the right one: what does it actually cost?

Exact per-token prices change often and vary by model and region — you can always check the current numbers on the official AWS Bedrock pricing page. So rather than a price sheet that's wrong next quarter, here's the part that stays true: how Bedrock pricing works, what actually drives your bill, and how to control it. Understand the model and you can estimate any specific price yourself.

The core model: you pay for tokens

With Bedrock's standard on-demand pricing, you pay per token — roughly a chunk of a word (a good rule of thumb is ~750 words ≈ 1,000 tokens). Two things matter:

• Input tokens vs. output tokens. You're billed for both what you send in (your prompt plus any context) and what the model generates. Output tokens are typically priced higher than input — so long, chatty responses cost more than they look.
• The model you choose. This is the biggest lever by far. A small, fast model can cost an order of magnitude less per token than a large, top-tier one. Same API, wildly different bill.

So the basic formula for a request is: (input tokens × input price) + (output tokens × output price), at the rate for the model you picked. Multiply by your request volume and you have a ballpark.

The other ways to pay

• Batch inference. If your workload is asynchronous — process a pile of documents overnight, not answer a user in real time — batch mode runs the same models at a lower per-token rate. Free money if your use case allows it.
• Provisioned Throughput. For high, steady volume you can reserve dedicated model capacity for an hourly fee (with 1- or 6-month commitments). It only makes sense at scale; below a certain volume, on-demand is cheaper and far more flexible.

The pattern that works: prototype on on-demand, measure real token usage, then optimize — move to batch or provisioned throughput only once the numbers justify it.

The costs nobody warns you about

The token price is rarely the whole bill. The extras that surprise teams:

• Context is tokens too. If you're doing retrieval-augmented generation (RAG), every document you stuff into the prompt is billed as input tokens — on every single call. A "cheap" model with a bloated context can cost more than an expensive model used sparingly.
• Knowledge Bases & vector storage. Bedrock Knowledge Bases (managed RAG) mean paying to generate embeddings and to run a vector store (e.g. OpenSearch Serverless) — an ongoing cost separate from the model calls.
• Agents, Guardrails, and evaluation add their own charges on top of the underlying model usage.
• Retries and runaway loops. A poorly-bounded agent that calls the model in a loop can turn a rounding-error feature into a real line item. Set limits.

How to keep the bill under control

• Right-size the model per task. Route simple classification or extraction to a small cheap model; reserve the flagship model for the genuinely hard reasoning. Most "AI is expensive" problems are really "we used the biggest model for everything" problems.
• Trim prompts and context. Shorter system prompts, tighter RAG retrieval (fewer, more relevant chunks), and a sensible cap on max output tokens all cut cost directly.
• Cache and reuse. Don't pay to answer the same question twice; cache common results and reuse embeddings.
• Measure before you optimize. Log token counts per feature. You can't control a cost you're not watching, and the 20% of features driving 80% of spend are usually a surprise.

The real cost of production AI isn't the tokens

Here's the thing we tell clients: for most business applications, the Bedrock token bill is smaller than people fear — often a rounding error next to what the feature earns or saves. The expensive part is building it right: choosing the model deliberately, keeping data private and guarded, bounding what the AI can do, and not over-engineering a science project when a small, well-aimed integration would do.

That's exactly how we approach it — practical AI on AWS and Amazon Bedrock, guided by senior engineers, sized to the job. If you're trying to figure out what an AI feature would actually cost to run, tell us what you're building and we'll help you estimate it honestly.