Amazon Bedrock charges for inference in one of two ways: on-demand, where you pay per 1,000 (or per million) input and output tokens at a rate set by the model provider, or Provisioned Throughput, where you pay an hourly rate for dedicated model units regardless of how much traffic you actually send. Embeddings, batch inference, and model customization (fine-tuning) are billed separately on top of these two core modes. Most teams overpay because they default to on-demand for high-volume workloads or provision throughput they don't need — both are fixable once you understand how the meter actually runs.

How does AWS Bedrock pricing actually work?

Bedrock has no platform fee — you pay AWS directly for tokens processed or capacity reserved, and the underlying rate depends entirely on which foundation model you call. Anthropic, Meta, Amazon, Mistral, and Cohere models each carry their own input/output token prices, so "Bedrock pricing" is really a menu of dozens of separate model price lists that AWS meters and bills through one account. There's no minimum spend for on-demand usage, and no reserved capacity requirement — you can call a model once and pay for exactly that one call.

The official rate card lives on the AWS Bedrock pricing page, and it's the only source of truth — third-party calculators and blog posts (including this one) lag behind AWS's own updates, so confirm current rates there before building a cost model your CFO will hold you to.

What's the difference between on-demand and Provisioned Throughput pricing?

On-demand pricing is consumption-based: you're billed per token, per request, with no commitment, which makes it ideal for unpredictable or low-to-moderate traffic. Provisioned Throughput flips the model — you purchase a set number of model units (MUs), each guaranteeing a fixed number of input and output tokens processed per minute, and you're billed hourly for that capacity whether or not you use it.

Provisioned Throughput commitments run 1-month or 6-month terms, with longer commitments earning a meaningfully lower hourly rate. Published hourly rates per model unit span roughly $21 to $50 depending on the model — Meta Llama models sit at the lower end and Stability.ai's image models at the higher end for a 1-month commitment, with 6-month commitments priced lower still. The break-even logic is straightforward: if your sustained token throughput would cost more under on-demand pricing than the flat hourly MU rate, provisioning wins; if traffic is bursty or low, on-demand almost always wins because idle provisioned capacity still bills.

How much do Bedrock's foundation models actually cost per token?

Every model prices input and output tokens separately, and output tokens are consistently priced higher than input tokens because generation is more compute-intensive than reading context. As of mid-2026, representative on-demand rates include:

• Claude Sonnet (Anthropic, current generation): roughly $3 per million input tokens and $15 per million output tokens on Bedrock — a 5x output/input ratio that's typical across frontier chat models.
• Meta Llama 3.3 70B: around $0.72 per million tokens for both input and output — open-weight models on Bedrock are priced far below proprietary frontier models.
• Amazon Titan Text Embeddings V2: a small fraction of a cent per million tokens, since embeddings are single-pass vector generations rather than multi-token generations.

These numbers move as AWS and model providers adjust pricing (Anthropic in particular has run promotional rate windows on newer Sonnet releases), so treat any per-token figure — including the ones above — as a snapshot, and re-check the official pricing page before finalizing a budget. The pattern that doesn't change: output tokens dominate cost in generation-heavy workloads (chatbots, drafting, summarization), while input tokens dominate cost in retrieval-heavy workloads (RAG with long context windows).

What does a realistic monthly Bedrock bill look like?

Take a mid-size SaaS support-automation feature calling Claude Sonnet: 200,000 requests/month, averaging 1,500 input tokens (retrieved context plus user message) and 400 output tokens per request. At roughly $3/$15 per million tokens, that's 200,000 × 1,500 = 300M input tokens (~$900) and 200,000 × 400 = 80M output tokens (~$1,200), for a monthly total near $2,100 — before embeddings for the retrieval step or any caching discount.

Now take a higher-volume internal tool doing continuous document classification with Llama 3.3 70B: 5 million calls/month averaging 300 tokens each way. At ~$0.72 per million tokens blended, that's roughly 5M × 300 × 2 = 3B tokens, landing near $2,160/month — comparable total spend to the Claude example above, but at 25x the request volume, because the per-token rate is roughly 4-20x cheaper. This is the core lever most teams miss: model choice often matters more than every other optimization combined.

A sustained, latency-sensitive workload — say a real-time chat product doing 50 requests/second around the clock — is often cheaper on Provisioned Throughput than on-demand once volume is predictable enough to size model units correctly against that $21-$50/hour-per-MU range.

How do embedding and RAG costs factor into total Bedrock spend?

Embedding costs are typically the smallest line item in a Bedrock bill in per-token terms, but they scale with your corpus, not your traffic: indexing 10 million document chunks once is a one-time cost, while every user query against a RAG system generates an additional embedding call plus the retrieval-augmented prompt's now-larger input token count. The hidden cost isn't the embedding call itself — it's that RAG inflates the input side of your generation call, since retrieved context gets stuffed into the prompt as input tokens billed at the generation model's (often much higher) input rate. Teams that skip this in their cost model routinely underestimate total spend by 30-50% because they price the embedding step but not its downstream effect on generation token counts.

According to Gartner, enterprise generative AI spending grew 76.4% year-over-year to $644 billion in 2025, with continued growth of roughly 80.8% projected for 2026 — a trajectory that makes token-level cost discipline a board-level concern, not just an engineering line item, once an AI feature moves from pilot to production scale.

What are the most effective ways to cut Bedrock spend?

Six levers consistently move the bill, in order of typical impact:

1. Right-size the model per task. Route simple classification, extraction, and short-response tasks to smaller/open-weight models (Llama, Titan, Nova Micro/Lite) and reserve frontier Claude/GPT-class models for tasks that genuinely need their reasoning depth. Model choice is the single biggest cost lever available.
2. Cache repeated context. Prompt caching (where supported) lets you avoid re-billing full input token cost for system prompts, few-shot examples, and static context that repeats across requests — this can cut input-token spend by more than half in RAG and agent workloads with stable system prompts.
3. Trim retrieved context aggressively. Re-rank and truncate RAG chunks before they hit the prompt; most retrieval pipelines over-fetch by 2-3x "just in case," and every extra chunk is billed input tokens whether or not the model needed it.
4. Cap output length explicitly. Set max_tokens deliberately instead of relying on defaults — verbose models will happily generate 3x the tokens a task actually requires unless bounded, and output tokens are the expensive side of the ratio.
5. Switch to Provisioned Throughput once volume is predictable. Track your on-demand spend for 2-4 weeks; if it's consistently exceeding what a 1-month MU commitment would cost at your sustained throughput, move that workload over.
6. Batch non-real-time workloads. Batch inference pricing on Bedrock runs at a discount versus real-time on-demand for jobs that don't need sub-second responses — nightly summarization, backfill classification, and bulk embedding jobs are natural candidates.

FAQ

Is AWS Bedrock cheaper than calling OpenAI or Anthropic APIs directly?

Not inherently — Bedrock doesn't add a markup on top of model provider rates, but it also doesn't automatically discount them. The value is operational: one bill, one IAM/VPC security model, and access to multiple model providers without separate vendor contracts. Cost differences come down to which specific model you choose, not the fact that it's routed through Bedrock.

Does AWS Bedrock charge a platform or subscription fee?

No. Bedrock has no base platform fee or minimum monthly spend for on-demand usage — you pay per token processed or per hour of Provisioned Throughput reserved.

When does Provisioned Throughput make sense instead of on-demand?

When your sustained, predictable token throughput would cost more under on-demand per-token billing than a fixed hourly model-unit rate. This applies to latency-sensitive production workloads running continuously at meaningful volume, not bursty or prototype workloads.

Why are output tokens more expensive than input tokens on Bedrock?

Generating each output token requires a full forward pass conditioned on everything generated so far, while input tokens are processed largely in parallel. Output token rates run roughly 4-5x higher than input rates across most Bedrock models.

How can I estimate my Bedrock bill before going into production?

Run a representative sample of real requests through the target model, measure actual input/output token counts, and multiply by the published per-model rate on the AWS Bedrock pricing page, adding a 20-30% buffer for RAG context growth and prompt drift.

Does model fine-tuning or customization add to Bedrock costs?

Yes — customized models incur a training cost and ongoing storage/hosting charges, plus inference is billed separately at that model's on-demand or provisioned rate.