Amazon Bedrock pricing — every model, every input.

IHow Amazon Bedrock pricing works

Bedrock pricing has a reputation for being confusing, but the core is simple once you separate two things: what you are billed for (tokens, mostly) and how you choose to pay for it (one of four modes). Get those two straight and every line on a Bedrock bill becomes legible.

The fundamental unit is the token. A token is a chunk of text — roughly ¾ of a word in English, so 1,000 tokens ≈ 750 words. Every request to a text model is metered in two directions: input tokens (everything you send — your prompt, the system instruction, any conversation history or retrieved documents) and output tokens (everything the model generates back). You are billed separately for each, almost always at a published rate per 1,000 tokens (some pages quote per-million; divide by 1,000 to convert).

Output tokens are typically priced 3–5× higher than input tokens for the same model, because generation is the expensive part. This matters for cost design: a workload that reads a lot and writes a little (classification, extraction, routing) is cheap; one that writes a lot from a short prompt (long-form generation) is dominated by output cost.

The single biggest driver of cost is which model you pick. Bedrock hosts a ladder of models from many providers, and prices span more than two orders of magnitude from the smallest to the largest. The discipline that separates a cheap Bedrock bill from an expensive one is matching the model to the task — using a small, fast model where it is good enough and reserving frontier models for the genuinely hard requests. Many production systems route requests across a tier of models for exactly this reason.

Not everything is token-priced. Image and video generation is billed per image or per second of video. Embeddings are billed per input token (output is a vector, not charged). Fine-tuning a custom model has a one-time training charge plus an ongoing cost to store and serve it. And the four pricing modes (next section) change the per-token rate or replace it with a capacity charge. Everything else — Knowledge Bases, Guardrails, Agents — is generally billed on top of the underlying model tokens it consumes, plus any supporting AWS services (vector store, storage, etc.).

Important caveat, stated once and meant throughout: the dollar figures on this page are representative as of 2026 to illustrate relative cost and the shape of a bill. Foundation-model prices change frequently as providers compete. Always confirm current rates on the official AWS Bedrock pricing page before budgeting — and see the amazon-bedrock-pricing-calculator sibling to model your own numbers.

IIPer-model pricing — input and output per 1K tokens

This is the table most people come for: representative 2026 on-demand text-model prices across the major providers on Bedrock, expressed per 1,000 input and output tokens. Use it to rank models by cost and to sanity-check a budget — not as an audited price sheet.

Rows are ordered roughly cheapest to most expensive. The "per 1M tokens" columns are included because providers increasingly quote prices that way — they are simply the per-1K figure × 1,000. Where a model is sold mainly per-million, we show the equivalent per-1K so the table stays comparable.

IIIOn-Demand vs Batch vs Provisioned Throughput vs prompt caching

The same model can cost very different amounts depending on how you buy capacity. Choosing the right mode for each workload is the largest controllable lever on a Bedrock bill — often a bigger swing than switching models.

There are four pricing modes. Most teams use On-Demand for everything at first, then move specific workloads onto Batch, Provisioned, or caching as patterns emerge. They are not mutually exclusive — a single product can use all four for different paths.

IVEmbeddings, fine-tuning, and custom-model hosting costs

Beyond plain inference, three cost categories surprise teams because they are priced differently from chat tokens: embeddings (the engine of RAG and search), fine-tuning (training a custom model), and the ongoing cost of hosting that custom model. Each is worth understanding before you commit to an architecture.

VThree worked monthly-cost examples

Abstract per-token rates are hard to feel. Here are three concrete, representative monthly estimates for common workloads, using the table above. They are illustrative — your mileage varies with prompt length, model choice, and mode — but they show the shape and the order of magnitude.

Example A — a simple support chatbot (Claude Haiku, on-demand). Say 50,000 conversations a month, each averaging 800 input tokens (system prompt + history + question) and 400 output tokens. That is 40M input tokens and 20M output tokens. At Haiku's representative rates ($0.25 / $1.25 per 1M), input ≈ $10, output ≈ $25 → ≈ $35/month. Add prompt caching on the fixed system prompt and the input portion drops further. A genuinely cheap production feature.

Example B — a RAG knowledge assistant (Claude Sonnet, on-demand + embeddings). Say 20,000 questions a month, each pulling ~3,000 tokens of retrieved context plus a 500-token question (3,500 input) and producing a 600-token answer. That is 70M input and 12M output tokens. At Sonnet's representative rates ($3 / $15 per 1M), input ≈ $210, output ≈ $180 → ≈ $390/month for inference. Add a one-time corpus embedding of, say, 100M tokens with Titan (≈ $2–$10) plus the vector store. Prompt caching on the repeated instructions and any shared context can cut the input bill substantially. The lesson: in RAG, the retrieved context dominates input cost, so retrieval tuning is a cost lever, not just a quality lever.

Example C — a nightly batch summarization job (Nova Lite, Batch). Say 500,000 documents a month, each ~1,500 input tokens summarized to ~200 output tokens. That is 750M input and 100M output tokens. At Nova Lite's representative on-demand rates ($0.06 / $0.24 per 1M) that would be input ≈ $45, output ≈ $24 → ≈ $69; run it via Batch at ~50% off and it is ≈ $35/month for half a million documents. This is why high-volume, non-interactive work belongs on a cheap model and the Batch path.

Across all three, two patterns repeat: (1) model choice and mode move the number more than anything else — the same workload can be 10× cheaper on the right model; and (2) these are small numbers at prototype and early-production scale, which is precisely why so many teams build the whole thing on AWS credits and pay $0 out of pocket while they prove the workload out.

VIThe levers that cut your Bedrock cost

If a Bedrock bill is too high, the fix is almost always one of a short list of levers. In rough order of impact, here is what actually moves the number — useful whether you are optimizing your own spend or stretching a pool of AWS credits further.

• Right-size the model — The biggest lever. Route easy requests to a cheap, fast model (Nova Micro/Lite, Haiku) and reserve frontier models (Sonnet, Opus-class, Nova Premier) for genuinely hard ones. A tiered router can cut cost 5–10× with little quality loss.
• Move bulk work to Batch — Anything not interactive — enrichment, classification, embedding, evaluation — belongs on the Batch path at ~50% off. Often the single easiest win.
• Turn on prompt caching — If requests share a long system prompt, instruction set, or document, cache it. On chatbots and RAG with large fixed context this can slash the input portion of the bill.
• Shorten prompts and cap output — Input cost scales with everything you send (including retrieved context and history) and output cost with what you let the model write. Trim retrieved chunks, summarize history, and set sensible max-output limits.
• Use Provisioned Throughput only for steady volume — Reserved capacity wins when traffic is high and predictable; it wastes money on spiky or low traffic. Match the mode to the traffic shape.
• Reconsider fine-tuning vs RAG — A fine-tuned model carries a standing hourly hosting cost. For many cases, prompt engineering or RAG on a base model gives similar results with no reserved-capacity bill.
• Watch the supporting services — Knowledge Bases, vector stores, S3, and logging all add cost around the model. Include them in the budget — the model tokens are sometimes not the largest line.

VIIHow AWS credits make Bedrock $0 to build

Everything above prices what Bedrock costs if you pay AWS directly. For most startups and many companies, the relevant number is different — because AWS will frequently fund the build with credits, and Bedrock spend draws those credits down before it ever touches your card.

AWS runs several credit programs precisely to put generative-AI workloads on AWS, and Bedrock usage is fully credit-eligible. The relevant pools: AWS Activate (general startup credits, commonly up to $100K for institutionally-funded startups); a dedicated Bedrock / Generative-AI POC pool ($10K–$50K) aimed specifically at proving out a GenAI use case; and the competitive Generative AI Accelerator (credit awards up to $1M for a small cohort of AI-first startups). Credits apply automatically against your AWS bill — including Bedrock inference, fine-tuning, embeddings, and the supporting services — until exhausted.

The practical mechanic is that most of these pools are partner-filed: they are requested through the AWS Partner Network (the ACE program), not a public self-serve form. That is why teams typically route through an AWS partner rather than applying alone — and it is the gap CloudRoute fills. CloudRoute matches you to the right credit pool for your stage and to a vetted AWS DevOps/ML partner who both files the credit application and helps build the Bedrock workload (the RAG pipeline, the agent, the cost-tuned model routing). The customer pays $0 — AWS funds the credit pool, AWS pays the partner through engagement-funding programs, and the partner pays CloudRoute a routing commission. You never see an invoice.

Put together with the cost levers above, the picture for a startup is: build aggressively on Bedrock, draw down a $25K–$100K credit pool while you find product-market fit, and only start paying real money once usage — and ideally revenue — has scaled past the credits. Related: see the cross-cluster pages on AWS credits for generative-AI startups and Bedrock POC funding for the full credit mechanics.