Amazon Bedrock Pricing Explained: What You'll Actually Pay

August 02, 2026 · 2243 words · Cloud Development Group

You've decided to build an AI application on AWS. You've evaluated the models—Claude, Mistral, Llama—and you're ready to move forward. Then you hit the pricing page for Amazon Bedrock, and the question hits you: what will this actually cost?

If you're a CTO or engineering leader shipping production workloads, cost visibility matters. You need to know whether your margin holds, whether you can scale without burning cash, and whether you're paying for capability you'll never use. Amazon Bedrock pricing is straightforward once you understand the mechanics, but the devil is in the details—throughput, model choice, region, request volume, and whether you're invoking the API or running batch jobs.

This guide walks you through Amazon Bedrock pricing with the specificity you need to build a realistic budget and make informed trade-offs before you ship to production.

How Amazon Bedrock Pricing Works: The Basics

Amazon Bedrock uses a pay-per-use model with two core pricing dimensions: input tokens and output tokens. You are charged separately for tokens you send to the model and tokens the model generates in response. There is no monthly fee, no minimum, and no per-request charge—you pay only for tokens consumed.

This model is clean in principle. In practice, costs depend heavily on three variables:

As of late 2024, Amazon Bedrock pricing ranges from approximately $0.00015 per input token and $0.0006 per output token (Llama 3.1 70B) to $0.003 per input token and $0.015 per output token (Claude 3.5 Sonnet). For a 1,000-token request generating 500 output tokens on Claude 3.5 Sonnet, you'd pay around $0.010—negligible per call, but significant at scale.

Understanding Token Consumption: Where Your Costs Actually Hide

Most teams underestimate token consumption. Tokens are not words. The tokenizer varies by model, but broadly, 1,000 tokens ≈ 750 words for English text. However, token usage spikes in three common scenarios:

System Prompts and Few-Shot Examples

Every API call to Bedrock includes a system prompt—your instructions to the model. If you're building an agent that maintains context, a retrieval-augmented generation (RAG) system that includes document chunks, or a few-shot learning setup, you're sending those bytes on every single request.

Example: A customer service agent with a 2,000-token system prompt, 5 previous messages (3,000 tokens), and a retrieved document chunk (1,500 tokens) has already consumed 6,500 input tokens before the user's question arrives. At Claude 3.5 Sonnet rates, that's $0.0195 per call, even if the user only asks two words.

This is why architecture matters. If you're running 10,000 requests per day through such a system, you're looking at $195/day in overhead alone—before considering the user's actual queries. Caching strategies, session management, and careful prompt engineering can reduce this substantially.

Context Windows and Retrieval Systems

Larger context windows are a feature, not a cost advantage. Claude 3.5 Sonnet supports 200,000 tokens; Llama 3.1 goes to 128,000. If you're building a RAG system, you might retrieve 10 documents, each 1,000 tokens, and stuff them all into a single request. That works—but every token in those documents is billed at the input rate.

Smarter retrieval systems rank documents by relevance and include only what matters. Fewer tokens in = lower cost per request, faster response times, and better model performance (less noise in the context).

Model Output Length

Output tokens cost 3–5x more than input tokens, depending on the model. A model that generates verbose, meandering responses will cost more than one steered toward concise answers. Prompt engineering—specific instructions to be brief, to use bullet points, to avoid redundancy—directly impacts your bill.

Amazon Bedrock Pricing by Model and Region

Model choice is the primary cost lever. Here's a real-world comparison for a single request with 1,000 input tokens and 500 output tokens:

At 100,000 requests per month, this difference compounds: Llama costs $45/month; Claude 3.5 Sonnet costs $1,050/month. That's a 23x multiplier. It also explains why many teams start with open models—not for ideological reasons, but for cost efficiency during development and low-volume production phases.

Pricing is consistent across most AWS regions where Bedrock is available (us-east-1, us-west-2, eu-west-1, ap-southeast-1, and others). However, newer models and features roll out to us-east-1 first. If you need bleeding-edge models immediately, you may be region-locked.

On-Demand vs. Provisioned Throughput: Which Model Saves Money?

Amazon Bedrock offers two consumption modes:

On-Demand

You pay per token, no commitment, no upfront cost. Ideal for variable workloads, development, and low-volume production systems. Latency is consistent; no setup required.

Provisioned Throughput

You reserve model capacity (measured in model units) for a one-month or six-month term. Provisioned throughput costs roughly 50% less per token than on-demand pricing, but requires an upfront commitment and minimum spend.

For Claude 3.5 Sonnet, 1,000 provisioned model units (PMU) cost approximately $2,000/month. Each PMU supports approximately 3,000 tokens per minute. Provisioned throughput makes sense if you have predictable, high-volume workloads (millions of tokens per month) and can forecast demand accurately. For exploratory projects or customer-driven spikes, on-demand is more flexible and often cheaper in total.

A practical rule: if your monthly token spend exceeds the provisioned throughput reservation cost by 30–50%, provisioned throughput pays for itself. Below that threshold, on-demand is cheaper and more resilient.

Bedrock Batch: The Hidden Cost Optimization

Many teams overlook Bedrock Batch. It allows you to submit large inference jobs asynchronously—processing thousands or millions of records overnight—at a 50% discount compared to on-demand pricing. The tradeoff is latency; batch jobs typically complete within hours, not milliseconds.

Amazon Bedrock pricing for batch processing is:

If your use case allows for batch processing—content classification, document summarization, bulk data enrichment, model fine-tuning evaluation—batch can slash costs dramatically. A system that processes 1 million tokens per day using Claude 3.5 Sonnet costs $30/day on-demand ($900/month). Via batch, that drops to $15/day ($450/month)—a savings of $450/month with a trade-off of hours of latency.

Batch is particularly valuable for SaaS companies with tightly managed margins. The latency is acceptable for async workflows, and the unit economics improve significantly.

Real-World Cost Scenarios: From Development to Production

Scenario 1: Customer Support Chatbot

A mid-market SaaS company deploys a customer service agent on Bedrock. The system receives 5,000 requests per day. Each request includes:

Daily token consumption: 5,000 requests × (4,000 input + 300 output) = 21.5 million tokens/day

On-demand cost (Claude 3.5 Sonnet): (21 million × $0.003) + (1.5 million × $0.015) = $85.50/day = $2,565/month

With conversation caching: Amazon Bedrock supports prompt caching, where repeated system prompts and conversation prefixes are cached and charged at 10% of the standard rate after the first request. With 80% cache hit rates (realistic for sticky sessions), effective cost drops to ~$1,500/month.

With provisioned throughput (2,000 PMU, ~$4,000/month): Saves money only if monthly token spend exceeds $8,000 in savings—not justified here.

Recommendation: On-demand + prompt caching. Cost: $1,500/month. Add guardrails (token limits, request throttling) to prevent runaway costs.

Scenario 2: RAG-Based Document Analysis Platform

An enterprise deploys a document analysis platform using Bedrock and Amazon Bedrock Knowledge Bases. The system processes 50,000 documents per month, each ~2,000 words. Workflow:

Monthly token consumption: 50,000 × (3,000 input + 200 output) = 160 million input + 10 million output tokens/month

On-demand cost (Claude 3.5 Sonnet): (160M × $0.003) + (10M × $0.015) = $630/month

Batch cost (50% discount): $315/month (with 2–4 hour processing latency)

Provisioned throughput (4,000 PMU, ~$8,000/month): Overkill; not justified.

Recommendation: Use Bedrock Batch for the initial analysis (save $315/month), on-demand for interactive queries. Implement request caching to reduce retrieval costs. Total monthly cost: ~$315–400.

Scenario 3: Agentic AI Workflow with Iterative Reasoning

A research team builds an AI agent that performs multi-step reasoning: plan → retrieve → analyze → synthesize. The agent handles 100 complex queries per day, with an average of 8 internal reasoning steps per query. Each step includes:

Daily token consumption: 100 queries × 8 steps × (5,500 input + 600 output) = 4.88 million tokens/day

On-demand cost (Claude 3.5 Sonnet): (39.2M × $0.003) + (4.8M × $0.015) = $190/day = $5,700/month

With extended thinking (if available): Extended thinking allows the model to reason through complex problems, but tokens generated during reasoning are billed. If reasoning tokens add 50% to total output, costs increase proportionally.

Provisioned throughput (6,000 PMU, ~$12,000/month): Breaks even if monthly savings exceed $6,300 (roughly 50% of monthly on-demand spend). At this scale, provisioned throughput saves money.

Recommendation: Evaluate provisioned throughput for production workload. Implement session caching for repeated reasoning chains. Consider smaller models (Llama 3.1) for preliminary reasoning steps, then use Claude 3.5 Sonnet only for final synthesis. Hybrid approach could drop cost to $3,000–4,000/month.

Cost Control: Guardrails and Best Practices

Token consumption can accelerate quickly without guardrails. Here's how production teams manage it:

Token Budgeting and Alerts

Set monthly token budgets per application, per model, and per environment. Use AWS CloudWatch to monitor token consumption and trigger alerts at 50%, 75%, and 90% of budget. Implement automatic throttling or graceful degradation when thresholds are breached.

Prompt Optimization

Audit system prompts and context regularly. Remove redundant instructions; consolidate guidance into concise, high-signal prompts. A 500-token reduction in the system prompt saves $150/month at 100,000 daily requests.

Request-Level Controls

Enforce maximum input and output token limits per request. Implement timeouts and retry budgets to prevent cascading failures that consume tokens uselessly. Log all requests with token counts to identify cost anomalies early.

Caching and Session Management

Use Bedrock's prompt caching feature for repeated context. Session-based architecture (storing conversation state in DynamoDB or Redis rather than re-sending it on every call) reduces input tokens significantly.

Model Selection by Task Complexity

Route simple tasks (classification, formatting) to smaller, cheaper models (Llama, Mistral). Reserve expensive models (Claude 3.5 Sonnet, Opus) for complex reasoning and creative work. A hybrid approach can cut costs by 30–50% with no quality loss.

When to Engage AWS Consulting Support

Amazon Bedrock pricing is transparent, but optimizing your architecture for cost requires deep knowledge of your workload, model capabilities, and AWS primitives. Many teams make one-time decisions early—model choice, provisioned vs. on-demand, prompt design—that carry cost implications for months or years.

If you're evaluating Bedrock for a production system, cost is inseparable from architecture. At Cloud Development Group, we've helped engineering teams design and implement production AI workloads on Bedrock—from initial architecture through cost optimization after launch. Our approach is concrete: we model your expected token consumption, validate it with prototypes, and recommend the right mix of on-demand, provisioned throughput, and batch processing for your use case.

Whether you're building a customer-facing agent, a document processing pipeline, or an internal reasoning system, the decisions you make during architecture phase directly impact your unit economics. We help you make those decisions based on evidence, not guesses.

Conclusion: Building Budget Clarity Into Your Bedrock Strategy

Amazon Bedrock pricing is pay-per-token and predictable—until you ship to production and token consumption doesn't match your estimates. The most common misses are system prompts and context that consume more tokens than the user's actual query, retrieval systems that pull too much context, and on-demand pricing used for workloads that would benefit from provisioned throughput or batch processing.

Start by modeling your expected token consumption realistically: include system prompts, retrieved context, conversation history, and the full request lifecycle. Choose your model based on capability requirements and cost trade-offs, not hype. Prototype with a month of production-like traffic to validate assumptions. Then, if the numbers hold, provision appropriately—on-demand for variable workloads, provisioned throughput for predictable high-volume systems, batch for asynchronous jobs.

The teams shipping the most cost-effective Bedrock systems early treat pricing as an architecture constraint, not an afterthought. If you'd like to pressure-test your Bedrock strategy or discuss your AI application architecture, Cloud Development Group is built to help. We work with small, senior teams on concrete plans and incremental milestones—from design through delivery and beyond.

Ready to build on Bedrock with clarity on costs and a path to production? Let's talk through your use case. Reach out to discuss your architecture, expected token consumption, and the right pricing model for your workload.

Tell us what you're building.

Full-stack development and AWS implementation consulting for teams shipping production AI. Short discovery, concrete plan, incremental milestones.

Start a conversation