AWS Bedrock Pricing for Production Model Workloads

Bedrock pricing starts with on-demand token rates, then gets more complicated once your workload needs batch jobs, reserved capacity, or managed retrieval. Claude Sonnet 4.6 is listed at $3 input and $15 output per 1M tokens. Related analysis

That rate is the useful place to start, but it isn't the whole budget. Batch inference is listed at 50% off on-demand rates. Related analysis AWS teams with predictable asynchronous work can cut model spend quickly. Teams building live applications still need to price the operational layer around the model call.

Bedrock gives you a common AWS endpoint for models from Anthropic, Meta, Mistral, Cohere, and other providers. That can simplify permissions, observability, procurement, and deployment for an AWS-native stack. It can also put a pricing wrapper between you and the model provider.

The deciding question is simple: are you paying for lower model cost, or for AWS to run more of the surrounding system?

TLDR

Bedrock pricing depends on how you call the model and what AWS services sit around it. On-demand inference works for live traffic. Batch inference is listed at 50% off on-demand rates, while managed retrieval can create a $700 monthly minimum from 4 OCUs.

Key Takeaways

• Claude Sonnet 4.6 is listed at $3 input and $15 output per 1M tokens.
• Batch inference is listed at 50% off on-demand rates.
• Provisioned Throughput requires 1-month or 6-month commitments.
• Knowledge Bases are described with a roughly $700 monthly minimum from 4 OCUs.
• Direct model APIs can be the cleaner choice when AWS operations are not the buying reason.

How Bedrock Pricing Works

AWS Bedrock bills model use by tokens for on-demand inference. Input tokens are what you send to the model. Output tokens are what it generates. The difference matters because output-heavy workloads can cost far more than prompts that mostly retrieve, classify, or extract.

Claude Sonnet 4.6 is listed at $3 input and $15 output per 1M tokens. Related analysis A product that generates long drafts, detailed analyses, or agent traces should focus on output use first. A short prompt can be cheap while the generated response carries most of the bill.

Model selection changes the math. Llama 3.1 70B is listed at $2.65 input and $3.50 output per 1M tokens. Related analysis That spread between input and output pricing can make a smaller or more cost-efficient model attractive for high-volume classification, extraction, routing, or internal support work.

The model price is only one part of the production decision. Bedrock can also involve batch processing, reserved throughput, and Knowledge Bases. Each mode solves a different operational problem. Treating them as interchangeable is how a clean inference estimate turns into an ugly cloud bill.

Feature availability can also differ by AWS region and model provider. A workload may look good on paper, then require a different region, model variant, or deployment pattern once the team gets into implementation. Check the available model and feature set where the application will run before treating any rate as final.

On-Demand Model Pricing

On-demand inference is the default Bedrock billing mode for applications that need a response while a user waits. You send a request, Bedrock routes it to the selected model, and AWS bills token usage.

Model	Input price	Output price	Best fit
Claude Sonnet 4.6	$3 per 1M tokens	$15 per 1M tokens	Higher-quality generation and reasoning
Llama 3.1 70B	$2.65 per 1M tokens	$3.50 per 1M tokens	Cost-sensitive general-purpose workloads
Batch inference	50% off on-demand rates	50% off on-demand rates	Asynchronous processing
Provisioned Throughput	Commitment required	Commitment required	Predictable reserved capacity
Knowledge Bases	Roughly $700 monthly minimum from 4 OCUs	n/a	Managed retrieval

Claude Sonnet 4.6 is listed at $3 input and $15 output per 1M tokens. Related analysis The ratio matters more than the headline input price. If your product asks for a compact answer, the output side may stay contained. If it asks the model to draft pages, summarize long materials, or produce repeated tool-planning steps, output use can dominate.

Llama 3.1 70B is listed at $2.65 input and $3.50 output per 1M tokens. Related analysis That pricing shape makes it a different economic choice from Sonnet. It may fit workloads where acceptable quality is clear, prompts are stable, and the product does not need the most expensive reasoning model on every request.

A practical architecture often uses more than one model. Route straightforward jobs to the cheaper option. Reserve the premium model for requests where it improves the user-facing result or reduces manual review. The point is not to make the stack clever for its own sake. It is to stop paying premium output rates for work that a less expensive model handles well.

You also need to separate model cost from prompt design. Retrieval context, lengthy conversation history, repeated system instructions, and verbose tool outputs all add input tokens. Response defaults can add output tokens without delivering more value. A production budget should reflect the actual request payloads, not a tidy demo prompt.

Batch and Provisioned Throughput Costs

Batch inference is where Bedrock gets more interesting for workloads that do not need instant responses. Batch inference is listed at 50% off on-demand rates. Related analysis

That discount suits back-office work: document enrichment, content classification, catalog cleanup, evaluation runs, migration projects, and scheduled reporting. The trade is latency. A job that can wait is cheaper. A live customer interaction usually cannot wait.

The operational mistake is pushing every request through the live path because it is easier at launch. Teams then discover they are spending on high-priority inference for work that could have run later. A queue, a clear service-level expectation, and a batch path can change the economics without changing the model.

Provisioned Throughput is a separate decision. In 2026, Provisioned Throughput requires 1-month or 6-month commitments. Related analysis That makes sense when demand is stable enough to justify dedicated capacity and when the application cannot tolerate the uncertainty of shared on-demand throughput.

It is a poor fit for a workload still looking for product-market fit. Commitments turn forecast errors into paid infrastructure. A team with lumpy usage, unclear adoption, or an early feature should first understand its on-demand pattern. The future workload may warrant reserved capacity. The current one may just be expensive optimism.

The same principle applies to internal pilots. A pilot that needs a premium model for a narrow workflow may be worth funding. A broad internal rollout with no routing, no usage controls, and no plan for long outputs becomes a literal money pit.

Knowledge Bases Cost Floor

Knowledge Bases can be useful when your application needs AWS-managed retrieval over company documents. They also create a cost floor that changes the economics of smaller projects.

Knowledge Bases are described with a roughly $700 monthly minimum from 4 OCUs. Related analysis That is a meaningful starting point before the model generates a single answer.

The warning is straightforward. Do not choose managed Knowledge Bases because “RAG” sounds like the expected architecture. Choose it when the managed service saves enough engineering and operating work to justify the floor. A low-traffic assistant with a modest document set may not need it. A system with sensitive internal materials, changing permissions, and AWS-native governance may.

This is where teams often blend separate costs into a single model budget. They compare token rates, pick a model, and discover later that retrieval infrastructure is the larger fixed expense. The model may be cheap. The managed retrieval layer may be the bill that changes whether the feature ships.

A build-it-yourself retrieval stack has its own costs and maintenance burden. That does not make the managed option wrong. It means the comparison needs to include the alternative in full: storage, embeddings, retrieval, access controls, monitoring, engineering time, and the failure modes someone must own.

If your workload is deciding between retrieval and training, RAG vs fine-tuning cost is worth reading alongside the roughly $700 monthly minimum from 4 OCUs. Related analysis The cheaper model call is not automatically the cheaper product architecture.

Bedrock vs Direct API Pricing

Bedrock is often the better operational choice for an AWS-heavy organization. A direct model API is often the cleaner pricing choice when the team wants access to a specific provider and does not need AWS to own the surrounding control plane.

Claude Sonnet 4.6 is listed at $3 input and $15 output per 1M tokens. Related analysis Compare that rate with the provider’s current direct offering before assuming Bedrock is the lowest-cost path. The result may be close. It may not. Either way, the decision should be explicit.

Bedrock wins when AWS integration is part of the value. Centralized identity, existing account controls, familiar billing, regional deployment needs, and a shared endpoint across providers can reduce operational friction. For a larger platform team, those benefits can be worth paying for even when a direct API looks better on a narrow token-price comparison.

A direct provider API wins when model access and price are the priority. It can also give your team a faster path to provider-specific features. Anthropic API belongs in the comparison when Claude Sonnet 4.6 is listed at $3 input and $15 output per 1M tokens. Related analysis

The same thinking applies when your application can use a different provider entirely. OpenAI API should be evaluated against the $2.65 input and $3.50 output per 1M tokens listed for Llama 3.1 70B. Related analysis A model benchmark is not a procurement strategy. The work is matching quality, latency, controls, and operational ownership to the workload in front of you.

There is no universal winner. Bedrock can be the right answer for an AWS-native production system. Direct APIs can be the right answer for a team that wants the lowest practical model cost and faster access to a provider’s newest capabilities. The loser is the team that treats a token-price table as the entire architecture decision.

Sources

• PE Collective AWS Bedrock pricing for $3 input and $15 output per 1M tokens
• PE Collective AWS Bedrock pricing for 50% off on-demand rates
• PE Collective AWS Bedrock pricing for roughly $700 monthly minimum from 4 OCUs