Amazon Bedrock Pricing: A CloudOps Guide to Managing AI Costs

Amazon Bedrock charges for inference: the process of sending a prompt to a foundation model and receiving a response. The core pricing unit is the token, a chunk of text roughly equivalent to four characters or three-quarters of a word. Every request has input tokens (your prompt, system message, and any conversation history) and output tokens (the model's response). You pay for both, at different rates.

What makes Bedrock costs harder to predict than compute is that tokens aren't fixed. A user who writes a two-sentence question consumes far fewer input tokens than one who pastes a 3,000-word document. An application that asks a model to "summarize briefly" generates fewer output tokens than one that asks for a detailed analysis. Multiply that variability across thousands of daily requests and budget forecasting becomes genuinely difficult without proper instrumentation.

Two additional factors complicate the picture. First, output tokens often cost more than input tokens for many models, because generating text is computationally heavier than processing it. This varies by provider: some models price input and output tokens equally, while others charge significantly more for output. Second, model selection has a dramatic effect on per-token rates. A lightweight model costs a fraction of what a frontier model in the same family costs per million tokens. The right model for a classification task is often wrong for a complex reasoning task, and vice versa. Selecting on capability alone, without factoring in cost, is one of the most common sources of unnecessary Bedrock spend.

Bedrock offers three main pricing modes: on-demand, provisioned throughput, and batch inference. Each serves a different workload profile. Understanding the trade-offs between them is foundational to both cost control and operational reliability.

Pricing mode	How you pay	Commitment	Latency	Best for
On-demand	Per token processed	None	Variable; throttling risk at peak	Bursty, experimental, or low-volume workloads
Provisioned throughput	Fixed hourly rate per model unit	1 or 6 months	Guaranteed; no throttling	High-volume, consistent workloads; required for custom models
Batch inference	Per token (up to 50% discount vs. on-demand)	None	Asynchronous; not real-time	Document processing, nightly jobs, async enrichment pipelines

On-demand pricing for foundation models

On-demand is the default. You pay per 1,000 tokens processed, with no upfront commitment and no minimum spend. It's ideal for workloads that are exploratory, bursty, or not yet predictable enough to justify capacity reservations.

The operational risk with on-demand is throttling. AWS enforces concurrency limits on foundation model access, and during peak demand periods, requests may queue or fail. For internal tools or low-stakes applications, this trade-off is acceptable. For customer-facing features with latency requirements, it's not.

Token rates vary significantly by model family and generation. Within the Anthropic Claude lineup on Bedrock, for example, lighter models can cost an order of magnitude less per million tokens than frontier models in the same family. Rates also differ between input and output tokens for most models, though some providers price them equally. Choosing the right model for the task, not just the most capable one available, is the single highest-leverage cost decision a team can make. Always verify current rates on the AWS Bedrock pricing page before committing to a model selection strategy, since rates and available model versions change frequently.*

Provisioned throughput pricing options

Provisioned throughput works like a reserved instance for inference. You purchase model units, each guaranteeing a specific token throughput per minute, and pay a fixed hourly rate regardless of whether you use that capacity. Commitments run one month or six months, with longer terms yielding better rates.

The financial case for provisioned throughput depends on utilization. If your workload runs at consistent volume during business hours, the fixed hourly rate can deliver meaningful savings over on-demand at the same throughput level. But the commitment is real. Unused provisioned capacity costs the same as fully utilized capacity. Teams that provision for peak load and run at 30% average utilization don't save money.

Provisioned throughput is also the only inference option for custom and fine-tuned models. If your team plans to deploy a domain-adapted foundation model, that forces provisioned throughput regardless of your volume profile.

Model customization and fine-tuning costs

Fine-tuning a foundation model on Bedrock creates three separate cost events: training, storage, and inference. Training costs are based on the total tokens processed across your dataset and the number of training epochs. After training, the custom model sits in storage at a monthly fee. Serving the fine-tuned model requires provisioned throughput, with at least one model unit required without a long-term commitment.

Before committing to customization, teams should run a proof of concept on a reduced dataset to validate whether performance improvements justify the added cost structure. Model distillation, which compresses the capabilities of a large model into a smaller, faster one, can reduce long-term inference costs. But distilled models carry their own training costs and also require provisioned throughput for deployment.

Accurate cost estimation requires moving from vague assumptions to measured token volumes. Teams that forecast Bedrock spend based on "number of API calls" will be wrong. The number of tokens per call, and the ratio of input to output, matters far more than call count.

Input and output token pricing calculations

The core formula is straightforward. Monthly cost equals input tokens multiplied by the input token rate, plus output tokens multiplied by the output token rate, both expressed per million tokens. The challenge is estimating those token volumes accurately before production data exists.

Start with your application's prompt architecture. A system prompt that runs 500 tokens gets charged on every single request. A retrieval-augmented generation (RAG) setup that injects 2,000 tokens of context per query scales that cost across every invocation. Audit your prompt templates and count tokens using the Bedrock tokenizer or a model-specific counter before you launch.

For output estimation, analyze what your application asks the model to produce. Single-answer classification tasks generate far fewer output tokens than conversational responses or long-form content. Build a representative sample of requests, measure actual input and output token counts, and use that as your baseline. Then apply a multiplier for expected request volume.

A practical example: an application sending 100,000 daily requests to a mid-tier foundation model, with 800 average input tokens and 400 average output tokens, generates 80 million input tokens and 40 million output tokens per day. Depending on the model and its output token rate, total daily spend can range from tens to hundreds of dollars and compound to five figures monthly. The output token cost, often higher than the input rate for the same model, drives the majority of that figure.* For current rates across all available foundation models, see the AWS Bedrock pricing page.

Cost estimation tools and methods

AWS provides a Bedrock pricing calculator and a token estimation tool in the console, both useful for initial modeling. For ongoing visibility, AWS Cost Explorer surfaces Bedrock spend but doesn't break costs down by model, application, or team without resource tagging. Tags are essential. Tag every Bedrock invocation with the application, team, and environment identifiers that correspond to your cost allocation structure, before workloads go to production.

DoiT Cloud Intelligence goes beyond tagging and dashboards. It provides real-time AI cost visibility across your Bedrock usage, with analytics that show how model selection, prompt patterns, and usage spikes drive spend at a granular level. That visibility connects cost data to engineering decisions in a way that static reports don't.

For multi-model environments where different applications use different foundation models, establish per-model cost budgets and alert thresholds separately. A spike in a frontier model costs look very different from a spike in a lightweight model, and collapsing them into a single budget line makes root cause analysis harder.

Optimization in Bedrock isn't a one-time audit. It's an operational discipline. AI workloads evolve quickly. A prompt that was efficient at launch can become expensive as use cases expand, context windows grow, and conversation histories accumulate. The teams that control Bedrock costs treat it the same way they treat compute right-sizing: continuously, with automated signals driving action.

Right-sizing model selection for workloads

Model right-sizing is the highest-leverage optimization available, and most teams underinvest in it. The default is to pick the most capable model in a family and deploy it across all use cases. The better approach is to match model capability to task complexity.

Classify your use cases by what they actually require. Simple extraction, classification, and summarization tasks don't need a frontier model. A smaller, cheaper model handles them accurately at a fraction of the cost. Reserve large models for complex reasoning, multi-step problem solving, and tasks where output quality materially affects business outcomes.

Test this rigorously. Run your actual workloads against a tiered set of models, measure output quality against your acceptance criteria, and calculate the cost difference. In many cases, a 90% quality threshold is achievable with a model that costs 10 to 20 times less than the top-tier alternative. That's not a minor efficiency gain. At scale, it's a budget transformation.

Also consider batch inference for workloads that don't require real-time responses. Bedrock's batch mode reduces token costs by up to 50% for supported models. Document processing, nightly analysis jobs, and asynchronous enrichment pipelines are strong candidates. The trade-off is latency: batch jobs run asynchronously, so they're not appropriate for user-facing features that expect immediate responses.

Implementing usage monitoring and budget controls

Monitoring Bedrock without token-level telemetry is like monitoring EC2 without CPU metrics. AWS CloudWatch surfaces Bedrock invocation counts and errors. Add custom metrics for token consumption per model, per application, and per environment. Set alarms on token thresholds that trigger before costs become a problem, not after the bill arrives.

Prompt caching reduces input token charges for repeated or static content. System prompts, reference documents, and shared context that don't change between requests can be cached. The cached portion bills at a reduced rate, which creates real savings for applications where the same system prompt appears in every call. Enable prompt caching for any content that fits this pattern.

Cross-region inference routes requests to available model capacity across AWS regions when your primary region is throttled or at capacity. This improves reliability under load without requiring separate provisioned throughput commitments. Evaluate it for production workloads where throttling tolerance is low.

Budget controls in AWS Budgets can alert on Bedrock spend, but they react to spend that's already happened. The stronger control is application-level rate limiting, which prevents runaway usage before it reaches your bill. Set per-user, per-session, and per-application token limits in your application layer and enforce them before requests hit the Bedrock API. That's the difference between a monitoring signal and an actual guardrail.

DoiT Cloud Intelligence provides automated anomaly detection for AI spend, surfacing deviations from expected cost patterns in real time. That means CloudOps teams learn about cost issues in hours, not at month-end close.

Unpredictable AI spend isn't just a financial problem. It's a credibility problem. When engineering leaders can't explain what drove a 40% increase in Bedrock costs from one month to the next, it creates friction with finance, slows down AI investment decisions, and undermines the case for expanding AI initiatives. Cost visibility isn't overhead. It's what makes the conversation about AI growth possible.

The teams that get this right treat Bedrock cost management as an engineering practice, not a finance function. They instrument token usage at build time, not after the first unexpected bill. They validate model selection against cost-quality trade-offs before launch. They build automated guardrails that enforce spending limits without requiring manual intervention. And they track cost per outcome, not just cost per call, so they can demonstrate ROI in terms that both engineers and executives understand.

That's the operational maturity that turns Bedrock from a cost risk into a sustainable capability.

DoiT helps CloudOps and FinOps teams bridge the gap between AI cost data and action. DoiT Cloud Intelligence surfaces real-time Bedrock spend by model, application, and team, with automated alerts and recommendations that don't require a FinOps expert to interpret. DoiT holds AWS Generative AI Competency and is available directly through the AWS Marketplace, so teams can deploy Cloud Intelligence within their existing AWS procurement workflow without adding a new vendor relationship.

Explore DoiT Cloud Intelligence for AI cost management and see how visibility into your Bedrock pricing can move from reactive to predictive.

What is the cheapest way to use Amazon Bedrock?

The cheapest approach combines model right-sizing with batch inference where possible. Using a smaller, task-appropriate model instead of a frontier model can reduce per-token costs by 10x to 20x. Enabling batch inference for non-real-time workloads adds up to 50% savings on top of that. Prompt caching for repeated system prompts and context reduces input token charges further. Start by auditing which use cases actually require a large model, and migrate everything that doesn't to the smallest model that meets your quality bar.

How does Amazon Bedrock provisioned throughput compare to on-demand pricing?

On-demand charges per token processed with no commitment. Provisioned throughput reserves dedicated capacity at a fixed hourly rate, billed whether you use it or not. Provisioned becomes cost-effective at high, consistent utilization levels, typically when on-demand costs would exceed the hourly commitment rate. For custom and fine-tuned models, provisioned throughput is required regardless of volume. On-demand is the right default for variable workloads, early-stage applications, and any use case where usage patterns aren't yet predictable.

How do input tokens and output tokens affect Amazon Bedrock costs?

Input and output tokens are priced separately, and output tokens typically cost three to five times more per million than input tokens. This means output verbosity, how much the model is asked to produce per request, has a disproportionate impact on your bill. Applications that request detailed explanations, long-form content, or verbose structured outputs will skew heavily toward output token costs. Designing prompts that constrain output length without sacrificing quality is a direct cost control.

Does Amazon Bedrock charge for failed API calls?

Bedrock charges for tokens that are successfully processed. Requests that fail before inference begins, such as authentication errors or throttled requests, don't generate token charges. However, retries on failed calls that reach inference before failing, for example due to context length violations, can generate partial charges. Monitoring retry rates and failure modes is part of responsible cost management.

What tools help track and control Amazon Bedrock spending?

AWS Cost Explorer surfaces Bedrock spend at the service level, and AWS Budgets can alert on cost thresholds. CloudWatch captures invocation metrics. For token-level visibility, application-side logging of input and output token counts per request is essential. Resource tagging by application, team, and environment enables cost allocation. Platforms like DoiT Cloud Intelligence provide real-time AI cost analytics and automated anomaly detection across your Bedrock usage.