Amazon Bedrock is easy to adopt and easy to overspend on. There's no cluster to size, no endpoint to keep warm, no capacity to reserve — you call an API and the tokens are metered. That frictionlessness is exactly why the bill creeps: nothing forces a decision about cost until it's already large.
By the time a Bedrock line item is worth a meeting, it's usually the sum of a dozen unrelated choices — which model each team defaulted to, how much context each request drags along, whether caching is on and actually working, and whether anyone ever benchmarked on-demand against committed capacity. The good news is that the same properties that make it easy to overspend make it easy to fix: almost every lever below is a configuration change, not a re-architecture.
Here are nine levers, roughly ordered from "do this first" to "do this once the big wins are banked." The dollar figures are illustrative and internally consistent — use them to reason about ratios, not to quote list prices.
1. Get Per-Model, Per-Application Visibility First
In AWS Cost Explorer, Amazon Bedrock is a single service line. You can see that you spent, say, $180K last month, but not which model, which application, or which team drove it — and you certainly can't see input versus output tokens, or how much of that was cache reads. Optimizing at this resolution is guessing.
The fix is to join two data sources. Cost comes from the AWS Cost and Usage Report (CUR), which itemizes Bedrock usage by model ID and usage type at an hourly grain. Token and application attribution comes from Bedrock model invocation logging, which records per-request input/output token counts (and cache read/write tokens on supported models) to CloudWatch Logs or S3. Enable invocation logging on day one — it can't be backfilled, so every day it's off is a day of attribution you'll never recover. Join the two on model, region, and time window and you finally have cost per model, per application, and per team.
2. Right-Size Model Selection and Routing
This is the biggest lever by a wide margin, because foundation model pricing spans more than an order of magnitude across tiers. Running a premium reasoning model where a mid or small model clears the quality bar is the single most common source of avoidable Bedrock spend — and it's usually invisible, because the premium model works, it's just expensive.
| Model Tier | Relative Input ($/M tokens) | Relative Output ($/M tokens) | Fits |
|---|---|---|---|
| Small (Haiku-class) | ~$0.80 | ~$4 | Classification, extraction, routing, simple Q&A, high-volume tasks |
| Mid (Sonnet-class) | ~$3 | ~$15 | Most production copilots, RAG answers, summarization, tool use |
| Premium (Opus-class) | ~$15 | ~$75 | Hard multi-step reasoning, agentic planning, high-stakes generation |
The table makes the arithmetic obvious: moving a workload from a premium to a mid model is roughly a 5x cut on the same tokens; from mid to small, another 3–4x. The discipline is to route by task complexity rather than defaulting everything to the most capable model. A cheap classifier or a fast small model can triage requests, sending only the genuinely hard ones up-tier. Cascade and fallback patterns push this further: answer with a small model, and only escalate to a larger one when a confidence check or validation step fails. Most teams discover that 60–80% of traffic never needed the premium model — they just never measured which requests did.
3. Turn On Prompt Caching — and Verify It Hits
Bedrock supports prompt caching on eligible models, with cache reads discounted up to roughly 90% off base input price. For any workload with a large shared prefix — a system prompt, tool definitions, policy context re-sent on every request — this is the largest single discount available, and it stacks on top of whatever model tier you've chosen.
The catch is that caching is a bet on your own traffic: a cache write costs a premium, and it only pays off if the prefix gets read again before the cache expires. "Caching enabled" tells you nothing; the hit rate tells you everything. We wrote the full break-even math, the write premium mechanics, and the production patterns that quietly kill hit rates in the prompt caching economics deep dive — if Bedrock is a meaningful line item, read that before assuming your caching is working.
4. Move Latency-Tolerant Work to Batch Inference
Bedrock batch inference processes requests asynchronously at roughly a 50% discount versus on-demand, for both input and output tokens. The trade is latency: you submit a job, it runs when capacity is available, and you collect results later — not a fit for anything a user is waiting on, ideal for everything they aren't.
The workloads that qualify are more common than teams assume: overnight document classification and enrichment, bulk summarization of a content backlog, embedding or re-processing a corpus, evaluation and regression suites over prompt changes, synthetic data generation, and periodic report generation. Any pipeline where the answer is needed "by morning" rather than "in 800 milliseconds" is leaving half the bill on the table if it runs on-demand. Audit your scheduled and queue-driven Bedrock calls specifically — that's where batch-eligible spend hides.
5. Optimize Tokens and Prompts
Every token is metered twice over in effect — you pay to send context and you pay to generate output — so trimming both directly cuts the bill on every single call, before any caching or tiering. The highest-leverage moves: cap max_tokens to what the task actually needs instead of leaving it wide open, trim retrieved and boilerplate context to what's load-bearing, and stop re-sending static context that could live behind a cache breakpoint instead.
Output tokens are the expensive half — typically 4–5x the input price — so verbose formatting, restated questions, and unbounded generations cost real money at volume. Asking for structured, terse output and bounding length is a pure win. The full playbook, including the mistakes that silently inflate token counts, is in our token optimization field guide.
6. Provisioned Throughput vs. On-Demand
On-demand pricing is the default and the right choice for most workloads: you pay per token with zero commitment, which is perfect for spiky, unpredictable, or low-volume traffic. Provisioned Throughput is the opposite bet — you commit to model units (dedicated capacity) for a term, paying an hourly rate whether or not you use it, in exchange for guaranteed throughput and no per-token metering.
Provisioned Throughput only pays off under steady, high, predictable volume — the utilization has to be high enough that the committed hourly rate beats what the same tokens would cost on-demand. The failure mode is committing capacity for a workload that's bursty or seasonal: you pay for idle model units between peaks, and the "discount" becomes a surcharge. The honest test is to project a few weeks of actual per-model token volume from your invocation logs, price it both ways, and only commit where on-demand consistently exceeds the committed rate with headroom. For most teams, provisioned throughput is justified for one or two hot production models, not the whole fleet.
7. Tame RAG and Knowledge Base Costs
The token bill is only half of a RAG system's cost. Bedrock Knowledge Bases typically back their vector store with Amazon OpenSearch Serverless, which is billed by OpenSearch Compute Units (OCUs) — and OCUs run continuously, independent of query volume. A lightly used knowledge base can quietly cost more in idle OCU capacity than in actual Bedrock inference. Right-size the minimum OCU allocation to your real index size and query load, and consolidate small knowledge bases rather than standing up a separate collection per use case.
On the inference side, RAG cost is driven by how much retrieved context you stuff into each prompt. Two levers matter most: chunking strategy (smaller, well-targeted chunks mean fewer wasted tokens per retrieval) and capping retrieved context (retrieving the top 3 relevant chunks instead of the top 15 can cut input tokens dramatically with little quality loss, and often improves answer precision). Every extra chunk is input tokens on every query, so an over-generous numberOfResults is a recurring tax paid at RAG scale.
8. Choose Regions and Cross-Region Inference Deliberately
Foundation model pricing and availability vary by AWS region, and cross-region inference profiles — which route requests across a set of regions for capacity — can change both your effective price and your data-residency posture. It's worth checking the per-token price of your chosen models in the regions you actually operate in, rather than assuming your default region is cheapest.
Two watch-outs. First, cross-region inference can route traffic to a region with different pricing than you expected, so the blended cost isn't always the number you'd read off your home region's price sheet — reconcile it against the CUR. Second, if you're already moving data or running RAG retrieval in a specific region, keeping inference co-located avoids cross-region data transfer charges that erode any per-token saving. Region choice is a small lever compared to model selection, but it's free to get right and annoying to discover you got wrong.
9. Attribute Spend and Alert on Regressions
Every lever above decays. A team ships a prompt change that doubles context. A deploy reorders tool definitions and resets the cache. Someone bumps a default from a mid to a premium model "just to be safe." Individually invisible, collectively they walk the bill right back up — and without attribution, the first signal is a quarterly billing surprise nobody can explain.
The durable fix is to tie Bedrock spend to the team, application, and experiment that generated it, and to alert when a metric regresses. Effective cost per request, cache hit rate per endpoint, and token volume per application are the numbers that catch a regression the week it ships instead of the quarter it compounds. This is the same attribution discipline that makes every earlier lever measurable: you can't confirm a model-routing change saved money if you can't isolate that application's spend before and after.
Four questions that surface most of the avoidable Bedrock spend:
Which model tier is each application actually using — and has anyone checked whether the tier below it clears the quality bar?
What's the cache hit rate on your highest-volume endpoints this week versus last month?
How much of your scheduled or queue-driven inference could run on batch at half price?
Which model, if any, has steady enough volume to justify Provisioned Throughput — and have you priced it both ways from real token data?
Making It Stick
The fastest Bedrock savings come from the top of this list — visibility, then model routing, then caching — and those three alone routinely cut a bill by half. But the reason Bedrock spend creeps back is that the levers are all configuration, and configuration drifts. The teams that stay optimized are the ones who made the spend legible: cost per model, per application, and per team, with alerts when a metric moves the wrong way.
That's the assembly work behind Amazon Bedrock cost optimization — joining the CUR to invocation logs, attributing every token to the feature and team that spent it, and watching model mix, cache hit rate, and effective cost per request so a regression shows up as an alert instead of a surprise. It's the same engine behind our broader generative AI cost tracking across Bedrock, OpenAI, and Anthropic.