Getting more value from Amazon Bedrock

Amazon Bedrock gives you more cost data than most teams have time to use. AWS reports cost by model and by day, and it offers a long list of features that change what a workload costs, from batch and caching to routing and distillation. What your team adds on top is the view of each workload: who owns it, what it produces, and which of those features fits it.

We suggest working in that order. Start with what AWS already reports, give each dollar an owner, choose the features that fit, and then check on the bill that each change did what you expected. Prices change, so the figures here are from each vendor's own pages in October 2026.

What AWS already tells you

AWS reports Bedrock use in two places, and both do their job well.

• Usage, in CloudWatch. The AWS/Bedrock namespace counts invocations, input and output tokens, and cache reads and writes, for each model. It also shows latency, errors and throttles. See the runtime metrics guide.
• Cost, in Cost Explorer and the Cost and Usage Report. Each charge has a usage type that names the region, the model, the token type, the service tier and the routing, for example USE1-Claude4.6Sonnet-output-tokens-cross-region-global. AWS's guide to Bedrock in the Cost and Usage Report explains that totals match the bill only when all four token types are counted: input, output, cache read and cache write.

The second bill

AWS's Bedrock FAQ says customers "will see an AWS Marketplace bill" for certain Bedrock models, because third parties sell them. We saw this on our own AWS account in September 2026, where every Claude charge was a Marketplace product named "Claude … (Amazon Bedrock Edition)". A report filtered to the Amazon Bedrock service can miss all of it, so when you add up Bedrock spend, add the Marketplace lines for each model you call.

What the reports leave out

The Cost and Usage Report adds up cost by usage type over an hour or a day, so it has no row for a single request. CloudWatch knows the model, but not the team that called it. And neither one is meant to know what the call produced, whether that was a resolved ticket, a merged change or an answered question. The bill can tell you that Claude Sonnet cost more this month. Which team spent it, and whether the work was worth it, is the part your own data has to answer.

Valistry is built for that part: it puts Bedrock spend beside every other AI bill, gives each dollar an owner by rules you set, and joins it to results from your own systems.

Give each dollar an owner

You can give every Bedrock dollar an owner without storing any prompts. AWS offers three ways to do it, and each one reaches the bill as a tag.

1. 1Application inference profiles, for calls through InvokeModel and Converse. Create one profile per team and model, tag it with the team, and call the profile in place of the model ID. AWS's guide to application inference profiles says each profile is tied to one model, so a new model version needs a new profile.
2. 2Projects, for the Responses and Chat Completions APIs on the bedrock-mantle endpoint, where application inference profiles do not work.
3. 3The caller's identity. Since April 9, 2026, Bedrock cost can be split by the IAM user or role that made the call. Tag your roles by team, and create a new CUR 2.0 export with caller identity selected. If calls go through a shared gateway role, they all have the same caller, so this split works only when each team calls with its own role.

Then activate the tags as cost allocation tags in the Billing console. A tag counts only for the time the profile carried it: the management account can backfill activated tags for up to twelve months, but only for months when the tag was already on the resource. That is why you should tag each profile on the day you create it.

What invocation logging adds. Invocation logging is off by default. When you turn it on, it writes one record per call: the caller, the key-value pairs you set on the request, the token counts, and the request and response bodies for the data types you select. That per-request detail is useful for debugging. It also stores the text of your prompts and answers unless you leave text out, and you do not need it for cost by team, because the three ways above already put a team on every dollar of the bill.

The levers AWS offers, and what each saves

AWS offers these levers in five groups. The figure on each tile is the one the vendor publishes, and the text below links to its page.

Model choice.

• Intelligent Prompt Routing sends each request to one of two models from the same family, and uses the smaller one when it is enough. AWS says it can cut costs by up to 30% "without compromising on accuracy". It works with the model pairs AWS lists, so check that yours are among them.
• Model Distillation trains a smaller model on a larger model's answers for one narrow task. AWS says distilled models are up to 75% less expensive, with less than 2% accuracy loss for use cases like RAG, where answers come from your own documents. It suits a stable task that runs at high volume.
• The global endpoint for Claude. For Claude Sonnet 4.5, Haiku 4.5, Opus 4.5 and later models, Anthropic's pricing page says regional endpoints "include a 10% premium over global endpoints". AWS's global inference guide says the same: about 10% less than geographic routing. Where your data rules require a region, the regional endpoint is the right choice; elsewhere, the global endpoint costs less. On the bill, global calls end in -cross-region-global.

Caching.

• Prompt caching reads the part of a prompt that repeats, such as a long system prompt or a document, from a cache. AWS says it can reduce costs by up to 90% and latency by up to 85%.
• A cache that is written and never read. As AWS's report guide notes, a cache write costs more than a normal input token. So compare the cache-write and cache-read usage types for each model: if writes are large and reads are small, the cache costs more than no cache would. AWS does not publish a figure for this one.

How calls run.

• Batch inference suits work that nobody is waiting on, such as nightly summaries, evaluations, or processing old records again. The Bedrock price list states a "50% lower price compared to on-demand".
• Flex and Priority tiers. On the rows for many open models (DeepSeek, Mistral AI, Qwen, OpenAI's gpt-oss and others), the same price list states Flex at a 50% discount to Standard and Priority at a 75% premium. For other models, the service tiers page says only "discounted" and "Standard rate + premium". If you see usage types that end in -priority, check that the workload's speed is worth the premium.

Buying. Provisioned Throughput is priced per model unit per hour, for a one-month or six-month term. The Reserved tier is a fixed monthly price per 1,000 tokens a minute. AWS does not publish a saving against on-demand for either, so to see whether a commitment fits, compare the hours you pay for with the invocations CloudWatch counts on that model.

Infrastructure.

• The vector store behind a knowledge base. An OpenSearch Serverless classic collection is billed for at least 2 OCUs, at $0.24 per OCU-hour in US East, says the OpenSearch pricing page. With no queries at all, that is about $350 a month (our arithmetic: 2 × $0.24 × 730 hours). AWS says S3 Vectors cuts the cost of storing and querying vectors by up to 90%, and it works with Bedrock Knowledge Bases.
• Bedrock Guardrails. Content filters and denied topics cost $0.15 per 1,000 text units on the price list, so it is worth running only the policies each use needs. AWS does not publish a saving figure.
• AgentCore Runtime. You pay per second for the CPU and memory an agent uses, and CPU is not billed while the agent waits for a model or a tool, says the AgentCore pricing page. AWS does not publish a saving figure.

How to know a change worked

You know a change saved money when the bill shows it. The clearest way to see that is to measure each change on one workload, in four steps.

1. 1Pick a workload with its own owner tag. If it shares a profile or role with other work, its result mixes with theirs.
2. 2Write down the baseline. Note its daily cost from the bill, with all four token types and both bills, its number of calls, and its outcome, such as the tickets it resolved or the changes it helped merge. Divide the cost by the outcomes to get the cost of one successful outcome.
3. 3Change one thing at a time. If you make two changes at once, you cannot tell their effects apart.
4. 4Measure the same workload again, over the same number of days. Compare cost per successful outcome rather than the total, because volume moves on its own.

Quality is part of the test. If a cheaper model resolves fewer tickets, or its calls retry more often, the cost per successful outcome goes up even while the token bill goes down, and the change has not done what you wanted.

A saving counts when the same work costs less on the bill, and the work is as good.

Check against the bill rather than an estimate, because tokens times a list price leave out your discounts, credits and private pricing, and the bill includes them.

What Valistry adds

Valistry reads Bedrock's metrics and both bills with a read-only role, and never reads a prompt. It shows how much of your Bedrock spend your tags already cover, suggests the lever that fits each workload, and after each change, measures the result against the same workload's outcomes. The Amazon Bedrock page lists what it reads.

Whether you use Valistry or not, the order stays the same: give each dollar an owner, choose the lever, and let the bill show whether it worked.