Bedrock cost optimization: nine levers that cut the bill.

IWhy Bedrock bills run away

Bedrock spend creeps: a frontier model for every request, a long system prompt re-sent each call, real-time APIs doing overnight work, uncapped output, reserved capacity nobody watches.

Text models bill per token for input (prompt, system instruction, history, retrieved context) and output, at a rate set by the model. Output usually costs several times more than input. On top of that sit the pricing modes (on-demand, batch, Provisioned Throughput, prompt caching) and separate charges for embeddings, customization and custom-model hosting. Details are on the Bedrock pricing page and AWS's own pricing page.

Two variables dominate every bill: which model you call and which pricing mode you buy it through. Nearly every cost cut moves one of those, or reduces the tokens flowing through them.

Work in this order: measure, act, watch. Attribution (lever 9) saves nothing by itself, but it tells you where to act. Then pull levers roughly by impact per hour of work. Figures on this page are representative; confirm current rates before budgeting.

IILever 1: model right-sizing and routing

Most systems use one capable model for every request and pay frontier prices for work a small model would handle.

Mechanism. Bedrock hosts a ladder of models (Amazon Nova Micro, Lite, Pro and Premier; Claude Haiku, Sonnet and Opus classes; Llama; Mistral; Cohere) whose per-token rates differ widely. Right-sizing picks the cheapest model that meets the bar for a task. Routing makes that choice per request: easy traffic (classification, extraction, short answers, simple chat turns) goes to a small model, and hard requests escalate to a frontier model. Escalation can be rule-based (length, task type) or model-based (the small model tries first; a check decides whether to retry larger).

Typical effect. Because much real traffic is easy, moving it to a small model often cuts inference cost several-fold with little quality loss. The exact figure depends on your traffic mix.

When to use it. Almost always, and first. Build a small evaluation set and confirm the small model holds the bar on each task before routing it down.

IIILever 2: prompt caching for repeated context

If requests share a large prefix (system prompt, instructions, a reference document, tool definitions), you pay full input price for it every call. Caching stops that.

Mechanism. Bedrock caches a marked prefix so later requests that reuse it are billed at a discounted rate for those tokens. The cache has a short time-to-live, and some models also charge to write it. Put stable content first and per-request content last. See the prompt caching guide for supported models.

Typical effect. AWS says prompt caching can reduce costs by up to 90% for supported models. The bill-level effect depends on how much input is shared: a long system prompt with short questions benefits a lot; fully unique requests do not.

When to use it. Chatbots with long fixed prompts, RAG with recurring instructions, and agents with large tool definitions. See the prompt caching page.

IVLever 3: batch inference for offline work

Anything that can run in the background (overnight enrichment, bulk classification, corpus summarization, evaluations) is overpaying on the real-time API.

Mechanism. Submit many requests as one job (a file in S3); Bedrock processes them asynchronously and writes results back. AWS prices batch at 50% lower than on-demand for select models. Same model, same output.

When to use it. High-volume work that is not latency-sensitive: enrichment, embedding a corpus, classification and extraction at scale, labeling, offline evaluations. Not for chat or live agents. See the batch inference page.

VLever 4: output-token reduction (and input trimming)

Output tokens are the expensive direction, and output length is the variable teams control least.

Mechanism. Set a sensible max-output-token limit. Ask for concise, structured output (JSON, short fields) instead of prose that restates the question. On the input side, trim retrieved chunks, window or summarize long history, and prune bloated system prompts.

Typical effect. Large on workloads where generations were unbounded or verbose, and on chats that resend growing history. Small on read-heavy workloads.

When to use it. Everywhere, as basic hygiene. It is configuration, not engineering, and stacks with every other lever.

VILever 5: RAG instead of long context

Pasting a large document into every request makes each call pay for knowledge it mostly does not use.

Mechanism. Retrieval-augmented generation fetches only the few relevant chunks per question, so input stays small as the knowledge base grows. In RAG systems, retrieved context usually dominates input cost, so fetching fewer, better chunks is a cost lever as well as a quality one.

When to use it. Whenever the knowledge is larger than a small, stable set of facts. Keep long context for small or one-off inputs. See RAG on AWS.

VIILever 6: model distillation

For a high-volume, narrow task, train a small model to do what a large one does.

Mechanism. Distillation trains a smaller "student" model on responses from a larger "teacher" for a specific task (see the Bedrock distillation guide). You pay a one-time training cost, then run the task at the student's lower rate.

When to use it. When the task is high-volume and narrow enough that the per-token saving repays training. For low-volume or broad tasks, routing and prompt work on a base model usually win. See Bedrock fine-tuning and distillation.

VIIILever 7: Provisioned Throughput, only past break-even

Provisioned Throughput saves money above its break-even and wastes money below it.

Mechanism. You reserve model units for a term and pay a flat hourly rate regardless of tokens. It is cheaper than on-demand only when steady volume would cost more on-demand than the hourly charge. Below that, you pay for idle capacity.

When to use it. Steady, high, predictable volume, where on-demand throttling is a real risk, and as one way to serve fine-tuned models (some base models also allow on-demand deployment of a fine-tune). Keep spiky or low traffic on on-demand. See Provisioned Throughput for the break-even math.

IXLever 8: embeddings and the vector store

Embeddings are cheap per token, until you embed a large corpus, re-embed on every change, and pay for a vector store.

Mechanism. Embedding models (Amazon Titan Text Embeddings, Cohere Embed) bill on input tokens only. The cost comes from volume and churn, plus the standing cost of the vector store.

What to do. Run corpus embedding as a batch job. Re-embed only what changed. Chunk sensibly to avoid redundant overlap. Size the vector store to the workload.

XLever 9: monitoring, attribution and alerts

This lever saves no money on its own, but every other lever depends on it.

Attribution: break spend down by model, feature, pricing mode and team, using tags, application inference profiles and per-request token logging. Monitoring: track tokens, cost and latency with CloudWatch and model invocation logging. Alerts: AWS Budgets and cost anomaly detection catch a runaway agent loop, a ballooned prompt or a forgotten reservation in hours, not at month-end.

When to use it. Before you start optimizing, and permanently after.

XIThe nine levers ranked by impact and effort

Do the top rows first. Lower rows are situational or take more engineering.

XIIWho can fund a Bedrock cost-tuning project

Bedrock spend draws down AWS credits automatically, and cost-tuning is real engineering work.

Partner-filed funding: a vetted AWS partner can file POC (proof of concept) funding to test a new GenAI workload, or incremental workload (IW) funding if you already run on AWS and are launching new work. For startups this is typically $50K to $150K. Depends on the workload; AWS approves.

AWS Activate: you apply yourself. Activate Founders gives self-funded startups $1,000 to start, up to $5,000. Activate Portfolio gives up to $200,000 with the Org ID from your VC, accelerator or angel group, if it is an Activate Provider. A consulting partner cannot file Activate for you.

With credits in place, the nine levers make them last longer. CloudRoute matches you with one vetted AWS partner who can build the router, caching, batch pipelines and attribution, and check which funding fits. Startups pay CloudRoute nothing. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.