The Bedrock Bill Trap: Capping GenAI Costs on AWS in 2026

GenAI moved from experiment to production line item faster than any service in cloud history. Gartner projects 80.8% growth in GenAI model spending in 2026. For most teams on AWS, that growth lands on the Bedrock line in Cost Explorer, and it lands without the cost-governance scaffolding that took years to build around EC2 and S3.

The pattern shows up in every audit. A team ships a feature backed by Claude or Nova. Usage scales faster than expected. Three months later, finance flags a six-figure annual run rate on a single Bedrock invocation pattern that nobody knew existed. The instinct is to throttle the feature. The right move is to rebuild the cost surface.

This guide is the playbook for that rebuild. It assumes you already have Bedrock in production and the bill is climbing. We will cover the highest-leverage controls first: prompt caching, batch inference, and model laddering. Then the cost allocation work that turns aggregated spend into team-level accountability. Then the waste patterns that show up once you start looking.

Prompt caching is the most underused cost feature in Bedrock. When you mark a portion of a prompt as cacheable, Bedrock saves the model's internal state at that checkpoint. Subsequent requests that share the same prefix skip the recomputation entirely. You pay roughly 10% of the standard input token rate for cached content. That is a 90% reduction on whatever portion of your prompt you can stabilize.

In January 2026, AWS extended the cache TTL from 5 minutes to 1 hour for Claude Sonnet 4.5, Haiku 4.5, and Opus 4.5. This sounds like a small change. It is not. A 5-minute TTL only helped tight conversational loops. A 1-hour TTL turns prompt caching into a default for any RAG system, agent loop, or document QA workload where the same context gets reused multiple times per hour.

A worked example. An enterprise document QA system handles 1,000 queries per day against 10 documents averaging 20,000 tokens each. Each document gets roughly 100 queries. Without caching, you pay full input rate for 20,000 tokens on every query. With prompt caching enabled at the document boundary, the first query writes to cache and the next 99 queries read at the cached rate. At standard Sonnet 4.5 input pricing, that single configuration change saves roughly $20,000 per year on that workload alone.

Bedrock offers five distinct pricing modes. Most teams default to on-demand because it is the entry point in the console. The teams getting cost right combine modes based on workload shape.

Model choice is the second-largest cost lever after caching. The current Claude 4.x lineup spans a 5x difference in per-token cost between Haiku 4.5 ($1/$5 per million input/output tokens) and Opus 4.5+ ($5/$25), with Sonnet 4.x sitting in the middle at $3/$15. Most production workloads run on the most expensive model the team had access to during prototyping, not the model that actually fits the task.

A laddering strategy routes each invocation to the cheapest model that meets quality requirements. Classification, extraction, summarization, and most routing tasks run on Haiku without measurable quality loss. Multi-step reasoning, code generation, and nuanced writing benefit from Sonnet. Opus is reserved for genuinely hard problems where the output quality justifies the price gap.

The implementation pattern is simple. Build a router layer in front of Bedrock invocations that selects the model based on task type and complexity heuristics. For RAG systems, route retrieval and reranking through Haiku, generation through Sonnet. For agent loops, use Haiku for tool selection and Sonnet for synthesis. Measure quality on a held-out evaluation set before and after; the cost shift is usually significant and the quality delta is usually invisible.

The most common Bedrock cost allocation failure mode looks like this: finance sees a single line item for Bedrock InvokeModel totaling $40K per month and has no way to attribute it back to the three product teams sharing the account. Cost Explorer tags do not help because IAM users and roles do not appear at the model invocation level.

Application Inference Profiles solve this. An inference profile is a wrapper around a model that you can tag with team, project, environment, or feature. Invocations made through the profile inherit the tags, which then surface in Cost and Usage Reports and FOCUS exports. Without profiles, you are flying blind. With them, you can build a chargeback model.

AWS Data Exports now expose Bedrock at the operation level. Cost and Usage Reports and FOCUS 1.0 exports include granular operation names like InvokeModelInference and InvokeModelStreamingInference. This means you can attribute model spend not just to a team via profiles, but to specific call patterns within that team. Streaming versus non-streaming invocations show up as separate cost lines.

Once you have caching, batching, and laddering in place, the next layer of cost is structural waste. The same patterns appear in nearly every Bedrock account once usage gets above a few thousand dollars per month.

Most teams can compress this whole agenda into a focused four-week sprint. The order matters: visibility first, then high-leverage controls, then the structural cleanup. Skipping visibility leads to optimization without measurement, which leads to optimization without proof.

Bedrock cost optimization sits alongside the broader FinOps work, not inside it. Commitment programs, right-sizing, and Reserved Instances optimize the steady-state compute and storage layers. None of those tools reach into model invocations. That gap is why GenAI cost is showing up as a board-level concern in 2026: the existing FinOps muscle does not flex against it.

The teams getting this right treat Bedrock as a distinct cost domain with distinct controls. Prompt caching, model selection, and inference profiles are the levers. Application Inference Profiles and FOCUS exports are the reporting layer. Invocation logging is the audit trail. None of those exist in the EC2 toolbox.

If your AWS bill is growing on the Bedrock line and the existing cost controls are not catching it, that is normal. The cost surface for GenAI is new, and most teams are still building the muscle to manage it. The 30-day sprint above is the starting point. The harder work is making the controls stick: profiles enforced by IAM, evals run on every model change, KB cleanup as a quarterly ritual.

Upload your most recent AWS bill and we will tell you exactly how much of it is Bedrock, where the caching wins are hiding, and which workloads are still on the wrong model. No commitment, no infrastructure access required.