Amazon Bedrock cost audit
Bedrock lands in Cost Explorer alongside your other AWS spend, which makes it feel governable with habits your platform team already has. Most of those habits 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: create one per workload or team, tag it, and route invocations through it rather than calling the model id directly.
Teams that skipped this have one untagged Bedrock line in Cost Explorer and no way to split it afterwards, because tags apply from creation forward. Reconstructing attribution for months already billed means CloudTrail or your own request logs, which is why the profile inventory is the first thing we ask for.
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 what a saturated one costs. Two failure modes recur: capacity bought for a launch that never reached its projected volume, and units left running against a superseded model version after a migration.
The audit compares committed capacity with actual token throughput per hour across a representative month. Low utilisation on non-spiky traffic means on-demand is 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. That is a good default, and it quietly changes the billing picture: spend appears in regions nobody deployed to, per-region prices differ, and residency assumptions written into a compliance document need re-reading against the profile's real behaviour.
This rarely produces a large saving by itself. It produces a correct baseline, without which 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 usual rules: identical prefix, reused inside the window. The audit looks for asynchronous workloads still on the synchronous path and for stable system prompts that never get cached, because both fixes are 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, in 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.
Running OpenAI or Vertex AI alongside Bedrock? That is the common case, and the audit covers them together - the same workload priced in two places is usually the most useful finding in the document. Book the audit.
FAQ
How do you apply cost allocation tags to Bedrock spend?
Through application inference profiles. A foundation model is not a resource you own, so there is nothing to tag directly; you create a profile per workload or team, tag the profile, and route invocations through it instead of calling the model id.
Can Bedrock spend be attributed retroactively?
No. Tags apply from creation forward, so months already billed under an untagged setup cannot be split in Cost Explorer. Reconstructing that history means going to CloudTrail or your own request logs.
Why does Bedrock spend appear in regions we never deployed to?
Cross-region inference profiles route to whichever region has capacity, so tokens are billed where they are served. Per-region prices differ and any data-residency assumption in a compliance document should be re-read against what the profile actually does.
When is provisioned throughput cheaper than on-demand?
Only when committed model units run at high utilisation. An idle unit costs the same as a saturated one, so if realised throughput sits well below the commitment and traffic is not spiky, on-demand is usually cheaper outright.