Bedrock spend looks like AWS spend, and that is the problem.
Bedrock lands in Cost Explorer with your other AWS costs, which makes it feel governable using habits your platform team already has. Those habits mostly do not transfer, and the gaps are specific.
1. There is nothing to tag until you create something to tag
Cost allocation tags are the standard AWS attribution mechanism, and on Bedrock a foundation model is not a resource you own, so there is nothing to attach them to. The handle is the application inference profile: you create one per workload or per team, tag that, and route invocations through it instead of calling the model id directly.
Teams that skipped this step have a single untagged Bedrock line in Cost Explorer and no way to split it after the fact, because the tag applies from creation forward and not retroactively. Reconstructing attribution for months already billed means going to CloudTrail or your own request logs, which is why we ask for the profile inventory first.
2. Provisioned throughput bills whether or not you use it
Provisioned throughput is bought in model units on an hourly commitment, and an idle unit costs exactly as much as a saturated one. Two failure modes recur: a unit bought for a launch that never reached its projected volume, and units left running on a superseded model version after a migration.
The audit compares committed capacity against actual token throughput per hour across a representative month. If utilisation sits low and the traffic is not spiky, on-demand is usually cheaper outright, and that comparison is a spreadsheet rather than an experiment.
3. Cross-region inference moves where the tokens are billed
Cross-region inference profiles improve availability by routing to whichever region has capacity, which is a good default and quietly changes your billing picture. Spend appears in regions no one on your team deployed to, per-region prices differ, and any data-residency assumption written into a compliance document needs to be re-read against what the profile actually does.
This rarely produces a large saving on its own. It produces a correct baseline, and without one the rest of the numbers are unreliable.
4. Batch and caching are left on the table
Bedrock's batch inference runs at a substantial discount for work that tolerates a completion window, and prompt caching is supported on a subset of models with the same rules as everywhere else: identical prefix, reused within the window. The audit looks for asynchronous workloads still on the synchronous path and for stable system prompts that never get cached, because the fix for both is configuration rather than architecture.
What the audit needs from you
- Cost Explorer access, or a Cost and Usage Report export for the last 90 days filtered to Bedrock.
- Your inference profile inventory and current tagging scheme, whatever state it is in.
- Provisioned throughput commitments: what is running, on which model, since when.
- For your top workloads: a representative request and any documented latency requirement.
About a week, ending in a written document with a ranked savings list and an effort cost against each item. Free, and implementable without us.