Bedrock's pricing page hides what you'll actually pay

The Bedrock pricing page makes the decision look easy. A few tenths of a cent per thousand tokens - how expensive can that be? Then the first real month lands and the number is nothing like the back-of-envelope estimate, because the token rate was never the whole bill. Here is how Amazon Bedrock actually charges you in 2026 - the four billing modes, why output tokens quietly dominate the cost, the AWS line items that never appear in the per-token quote, and a worked monthly bill for a production agent so you can price your own before you commit.

The per-token price is not the price

Every Bedrock cost conversation starts in the wrong place: the price per thousand tokens for one model. That figure is accurate, but on its own it tells you almost nothing about your monthly bill, for three reasons.

• You pay for two token streams, not one. Input tokens (your prompt, the retrieved context, the system instructions) and output tokens (what the model writes back) are billed separately, and output is far more expensive - commonly around five times the input rate on a frontier model.
• The model you name changes the number by an order of magnitude. A frontier model and a small fast model can differ by 20 to 50 times per token. Run the wrong tier for a simple task and you are overpaying every single call.
• The model is one service among many. A working agent also needs embeddings, a vector store, compute to orchestrate it, logging, and often Guardrails. Those are separate AWS charges the token quote never mentions.

So the honest question is not "what does Bedrock cost per token" but "what does my workload cost per month once every service it touches is on the bill". That is the number your finance team signs off, and it is the one this guide helps you build.

How Bedrock actually bills you - the four modes

Bedrock is not one pricing model, it is four. Knowing which one fits your workload is the single biggest lever on the bill.

On-demand (pay per token)

The default. You pay for every input and output token at the model's published rate, with no commitment. Perfect for a live agent, a chatbot, or anything with unpredictable, bursty traffic. You pay for exactly what you use, and nothing when it is idle - which is also why a sudden traffic spike shows up directly on the bill.

Batch (the same work, roughly half price)

Submit a large job as a file and let Bedrock process it asynchronously, and you pay about half the on-demand token rate. If the work is not interactive - overnight document classification, bulk summarization, backfilling embeddings - batch is close to free money left on the table if you are not using it. The trade-off is latency: you get results in a window, not in real time.

Provisioned throughput (reserved capacity by the hour)

Instead of paying per token, you buy model units that guarantee a fixed throughput and pay an hourly rate whether you use them or not. This only wins at steady, high, predictable volume - or when you need a fine-tuned model served, which requires provisioned throughput. Below the break-even point it is pure waste; above it, it is cheaper and more predictable than on-demand. We come back to that break-even below.

Model customization (fine-tuning and storage)

Fine-tuning or continued pre-training bills you for the training compute once, then a recurring monthly storage fee to keep the custom model, plus provisioned throughput to actually serve it. It is the most expensive path to reach for last, not first - for most teams, a better prompt and good retrieval beat a fine-tune on both cost and effort. If you are weighing this, our note on when to use SageMaker versus Bedrock covers where custom training actually earns its keep.

What a token actually costs

Exact rates move - AWS adjusts them and adds models constantly, so always price against the live Bedrock pricing page - but the shape is stable and worth internalizing. Illustrative 2026 on-demand rates, per 1,000 tokens, to show the ratios that drive your bill:

• A frontier model (top-tier reasoning): roughly $0.003 per 1K input tokens and $0.015 per 1K output. Note the 5x gap between input and output.
• A small fast model (good enough for routing, extraction, short replies): often in the region of $0.0002 to $0.0008 per 1K tokens - 20 to 50 times cheaper.
• Embeddings (turning text into vectors for retrieval): typically around $0.0001 per 1K tokens - cheap per call, but you run it on every document you index and every query you answer.

Two rules fall out of this. First, watch output length: a model that writes a 600-word answer when 100 words would do is paying the premium rate for filler on every call. Second, match the model to the job - route simple steps to the small model and reserve the frontier model for the reasoning that actually needs it. If you are also weighing Bedrock against calling a provider directly, the trade-offs are laid out in our AWS Bedrock vs OpenAI API cost and speed comparison.

The line items nobody quotes

This is where estimates go wrong. A production agent is never just the model - it is a small system of AWS services, each with its own meter running:

• Embeddings. Every document you index and every user query gets embedded. Cheap per token, but at scale and on re-indexing it adds up.
• The vector store. This is the quiet one. OpenSearch Serverless bills by capacity unit (OCU) by the hour, with a minimum floor - not by the query - so it costs money even at low traffic. Picking the right vector store is a real cost decision; we break it down in what a RAG app on AWS really costs at 1M queries a month.
• Compute. Lambda, Fargate, or an API layer to orchestrate the calls, run tools, and handle retries. Modest per request, real at volume.
• Data transfer and logging. Bytes leaving AWS cost money, and CloudWatch logs from a chatty agent are easy to under-budget.
• Guardrails and knowledge bases. Bedrock Guardrails (content filtering, PII, topic blocks) and managed Knowledge Bases are separate priced features. Worth it for safety and speed to build, but budget them in, not out.

On a real retrieval agent these surrounding costs frequently rival the model spend. Leave them out of your estimate and you will be wrong by a factor, not a fraction.

On-demand vs provisioned throughput - when each wins

This is the decision that most often makes or wastes money on Bedrock. The logic is the same break-even you would apply to reserved cloud capacity anywhere:

• Stay on-demand when traffic is spiky, unpredictable, or still growing, or when you are early and do not yet know your steady-state volume. You pay only for what you use, and you never eat idle capacity.
• Move to provisioned throughput when you have proven, sustained, high volume on one model and can keep those reserved units busy most of the day. Past the break-even, the fixed hourly rate beats paying per token, and your bill becomes predictable.
• You have no choice but provisioned throughput when you are serving a fine-tuned or custom model - that path requires it regardless of volume, which is another reason to be sure a fine-tune is worth it first.

The practical rule: launch on-demand, watch the real usage for a few weeks, and only reserve capacity once the numbers prove you would keep it busy. Reserving too early is the classic Bedrock overspend. A short review with our AWS consulting team can size that break-even against your actual traffic before you lock anything in.

A worked monthly bill

Take a customer-support agent for a mid-market company: about 50,000 conversations a month, retrieval over a modest knowledge base, a frontier model for the answer and a small model for routing. Illustrative, not a quote - your mix will differ, but the proportions are the lesson:

• Model tokens (on-demand): the bulk of the bill, and inside it, output tokens dominate. Routing on the small model is a rounding error; the frontier answers are where the money goes.
• Embeddings: small if the knowledge base is stable, larger in any month you re-index everything.
• Vector store (OpenSearch Serverless): a flat floor you pay every hour regardless of traffic - often a bigger share than teams expect at this scale, because the minimum capacity does not shrink with low volume.
• Compute, logging, data transfer: individually minor, collectively a real slice - budget them as a group, not as zero.

The headline: the token rate you started from is maybe half to two-thirds of the total, and the biggest cut usually comes not from a cheaper model but from shorter outputs, routing simple work to the small model, and right-sizing the vector store. That is the difference between building the estimate properly and being surprised.

How to keep the Bedrock bill down

1. Right-size the model per step. Route classification, extraction, and short replies to a small model; reserve the frontier model for genuine reasoning.
2. Shorten outputs. Ask for the answer length you need. Output is the expensive stream; trimming verbosity cuts cost on every call.
3. Batch anything non-interactive. Overnight and bulk jobs at roughly half price is the easiest saving on the list.
4. Right-size retrieval. Retrieve fewer, better chunks so you stuff fewer input tokens into every prompt, and pick a vector store that fits your real query volume.
5. Instrument the spend. Tag and watch cost by feature from day one so a runaway prompt or a re-index storm shows up in hours, not on the invoice - the same discipline in our Bedrock setup guide for regulated workloads.

None of this needs a fine-tune or a heroic re-architecture. It is the boring, effective work of matching each call to the cheapest thing that does the job - which is exactly what our AI on AWS team and AI agent developers do when we build and cost these systems for clients.

FAQ

How is AWS Bedrock priced? Four ways. On-demand charges per input and output token with no commitment. Batch runs non-interactive jobs at roughly half the on-demand rate. Provisioned throughput reserves capacity at a fixed hourly rate. Model customization bills training compute once plus monthly storage. Most live apps start on-demand.

Why is my Bedrock bill higher than the token price suggested? Because the token rate is only the model. A real workload also pays for embeddings, a vector store (OpenSearch Serverless bills hourly by capacity, not by query), compute, data transfer, logging, and Guardrails. Together these often match the model spend.

Is on-demand or provisioned throughput cheaper? On-demand is cheaper for spiky or growing traffic because you pay only for use. Provisioned throughput wins only at proven, steady, high volume that keeps the reserved units busy, and is required to serve a fine-tuned model. Launch on-demand, measure, then decide.

What is the biggest way to cut Bedrock costs? Usually not a cheaper model. Shorten outputs, route simple steps to a small model, batch non-interactive work, retrieve fewer input tokens, and right-size the vector store. Those move the bill more than swapping the headline model does.