How to Track Amazon Bedrock Costs by Model (and Cut Them)
Your Bedrock bill went up again this month, and finance wants to know why. You open the console and see one number: Amazon Bedrock, total spend. You can't tell them whether the jump came from the Claude model running your support agent or the Nova model doing bulk summarization, so you can't tell them which team to go talk to.
On October 8, 2026, AWS gave Cost Explorer dedicated model-level cost attributes for Bedrock, which makes this kind of breakdown far easier to pull than before. This post covers how to track Amazon Bedrock costs by model, what the new attributes still don't show you, and what to actually do once you can see the number.
To track Amazon Bedrock costs by model, open Cost Explorer and group by the Model product attribute. Check which service names actually show up in your account before narrowing to a single Service filter, since some Bedrock-related charges can appear under other service listings. This covers usage reported under these attributes in Cost Explorer, Dashboards, and Budgets, with no extra charge for using the console itself.
Can You See This Today?
Before you go looking for the breakdown, check whether it applies to your account. AWS's October 2026 announcement excludes AWS GovCloud (US), China (Beijing), and China (Ningxia), and doesn't call out a separate support-plan restriction beyond that. It's live across Cost Explorer and Dashboards, and Budgets can filter on the same attributes to scope an alert.
The practical limit is history, and it comes with a caveat worth stating plainly: AWS's own announcement doesn't publish a historical start date. A hands-on test by the practitioner site dev.classmethod.jp found that attribute data starts from usage on September 1, 2026, and that querying earlier dates returns an API error. Treat that date as reported by independent testing, not as something AWS has confirmed directly, until AWS documents it.
Before this update, getting a model-level number meant digging through usage-type strings or reconciling model-specific billing line items by hand. The new attributes don't make that analysis possible for the first time. They make it a lot faster.
How to Track Bedrock Costs by Model in Cost Explorer
Pulling the breakdown takes a few steps, and none of them need the CLI unless you want to automate it later.
Open Cost Explorer in the Billing and Cost Management console.
Group by the Model product attribute. This is the main step, start here rather than filtering by service.
Check which service names actually appear in your results. A hands-on test by dev.classmethod.jp found that filtering to "Amazon Bedrock" alone excluded some Claude and OpenAI model charges billed under other service names, so confirm the full picture before you narrow with a Service filter.
Set your date range to September 2026 or later. Earlier ranges may return no attribute data or an error.
What comes back is a line per model: Claude Sonnet, Claude Haiku, Nova Micro, whatever you've actually called. Group by Model Provider instead if you want the Anthropic-versus-Amazon-versus-Meta split before drilling into individual models. Usage Type can also encode model and token information, it's just a denser string to read. The Model attribute just gets you the same comparison faster, without parsing usage-type codes by hand.
That's the model view. But "model" in this report means something narrower than it sounds like.
What Counts as a Model, and What Doesn't
Cost Explorer's Model attribute identifies which model was billed. It doesn't identify the application feature, endpoint, or business workflow that called it. If you call Claude Sonnet from three different parts of your app, a chat endpoint, a summarization job, and an internal tool, Cost Explorer sums all three into one Claude Sonnet line.
That's a real gap if the question you're answering is which feature is expensive rather than which model is expensive. For application-level billed cost, use application inference profiles: create a profile, tag it, and reference its ARN in your API calls so Cost Explorer and CUR can roll spend up by that tag. For request-level detail, like how many tokens one specific call used, enable model invocation logging, covered in Bedrock's own cost management documentation. That gives you per-request token counts in your logs, not a native per-request dollar figure inside Cost Explorer itself; you still have to apply the pricing yourself to turn those tokens into a cost. Model attribution, application attribution, and request-level logging answer three different questions, and the October update only answers the first one.
There's a second gap worth knowing about before you report this number upward.
Model Tells You What, Not Which Identity Called It
Since April 2026, Bedrock has supported attributing inference costs to the IAM user or role that made the call. Two practical limits are worth knowing before you trust this number: tags you activate aren't applied retroactively to past usage, and a newly activated tag can take up to 24 hours to appear in your cost reports.
There's also a case that can quietly undercut this: if multiple people call Bedrock through the same shared gateway role or service account, Cost Explorer shows you that role's identity, not each person behind it. Model attribution answers a what question: which model is expensive. IAM attribution answers which identity made the call, not necessarily which person or team. Most teams end up needing both once finance starts asking follow-up questions.
Once you have one or both views, the next question is what you actually do with the number.
The Number Is Only Useful If You Act On It
Seeing which model costs the most doesn't save you anything by itself. The useful question comes right after. Is every call to your most expensive model actually doing work that needs it?
Terry Camerlengo, director of technology at Wellpointe Labs, made this point directly in a 2026 interview on LLM cost visibility: if an agent defaults to the latest, most expensive model for every task, and the task itself is simple, you're paying frontier prices for work a cheaper, older model could handle just as well. His advice: route the simple cases to a less expensive model, and save the premium model for the calls that actually need it. On a process that runs thousands of times a week, that difference compounds fast.
This is where the Cost Explorer breakdown earns its keep. Once you can see how much a model costs in aggregate, that's a signal to go look at what it's actually doing, not proof on its own. Cost Explorer gives you billed dollars by model; it doesn't give you a request count, so pairing it with invocation logs is how you'd actually check whether routine, low-value calls are hitting your most expensive model.
This is the same blind spot FinOps teams have been dealing with outside AI spend for years. Bedrock just gave it a new name.
The Same Blind Spot Shows Up Outside AI Spend
We've seen this exact problem on traditional cloud bills: a team knows the total is too high, but nobody can point to the workload driving it. When we worked with a GCC-based e-commerce company on their AWS spend, that was the starting problem. Nobody owned a number because nobody could see where it came from. We've written before about getting one view across AWS, Azure, and GCP bills, and the same principle applies inside a single service like Bedrock.
Once we built that visibility across the GCC company's accounts, the result was roughly $6,000 a month in savings, the figure we report on that case study. Bedrock's new model breakdown doesn't do the cutting for you, same as that visibility work didn't cut costs by itself. It gives you the starting point: a number broken down enough that someone can own it.
Before you act on that number, though, it's worth being clear about what a cost calculator can and can't tell you.
What an AWS Bedrock Cost Calculator Can't Tell You
A pricing calculator estimates what a workload should cost before you build it. Plug in expected tokens per model, get a monthly projection. That's useful for planning, but it's a forecast, not a bill. It can't tell you that your support agent is quietly calling Claude Opus for yes-or-no questions, because it has no idea what your agent is actually doing at runtime.
Cost Explorer's per-model breakdown gives you a practical, after-the-fact view of actual billed spend by model. For deeper analysis, a Cost and Usage Report or your model invocation logs can fill in the request-level detail Cost Explorer doesn't show. Use a calculator before you ship a new Bedrock integration. Use Cost Explorer's model view after, to check whether reality matched the plan. If you want help setting that review up, our FinOps solutions team does this kind of audit regularly.
Bedrock Cost Tracking FAQs
How do I track Bedrock costs?
Open AWS Cost Explorer and group by the Model attribute to see spend broken out by model. Confirm which service names appear in your account before applying a Service filter, since some model charges can appear under other service listings. For costs by application or team instead of by model, use application inference profiles or IAM principal attribution.
Is AWS Cost Explorer free?
The Cost Explorer console is free to use, including the new Bedrock product attributes. If you pull this data through the Cost Explorer API instead of the console, that's billed separately: $0.01 per request on the primary billing view, including each page of paginated results.
Does the Cost Explorer model breakdown work in Budgets too?
Yes. The same product attributes can be used to filter a budget, so you can set an alert scoped to one specific model instead of your whole Bedrock bill.
Can I see Bedrock costs by model for usage before September 2026?
Independent testing found no attribute data available before September 1, 2026, with earlier date ranges returning an API error. AWS's own announcement doesn't state a historical start date, so treat September 2026 as the earliest confirmed point from outside testing, not an official AWS cutoff.
Does this cover Provisioned Throughput the same way?
AWS's announcement highlights on-demand inference and reranker usage as examples, but it doesn't spell out a full coverage matrix. If you run Provisioned Throughput commitments, check your Cost Explorer report against your provisioned capacity directly rather than assuming the same attribute coverage applies.
Setting this up is something most teams can do themselves in the time it takes to read this post: group by Model, check which service names and figures actually show up, and go find out why one model costs more than the rest. Where it gets harder is doing this every month without someone owning it, or connecting the Bedrock number to the rest of your AWS spend so finance gets one picture instead of three. That's the point where a FinOps review earns its time.
Still guessing which model is driving your Bedrock bill, or ready to see the real number?
Book a Free Cloud Cost Review with our team. We'll pull your actual Bedrock spend by model, flag where routing to a cheaper model makes sense, and show you where the rest of your AWS bill has the same blind spot.
Every model you add to production adds another line item nobody's watching. The question is whether you catch it before finance does.
About the Author
Techieonix International helps SaaS and e-commerce teams get control of what their cloud actually costs, AI workloads included. From Bedrock and multi-cloud cost visibility to the DevOps work that keeps spend predictable, we handle the parts most teams don't have time to build in-house.
Learn more about our FinOps Solutions | Explore DevOps Solutions
Ready to reduce Amazon Bedrock costs and optimize your AI spending?
At Techieonix, we help businesses track AWS Bedrock costs by model, improve AI cost allocation, optimize model usage, and implement FinOps strategies that reduce cloud waste. Contact us today for a free cloud cost review and take control of your AWS and AI infrastructure costs.
Talk to an ExpertKnow which model drives your costs. Make every AI dollar count.