AWS dropped two updates recently that make AI costs more visible and attributable.
I’m a big believer in not only keeping cloud costs under control, but also tying them to business outcomes. This way can you see what’s giving you the best ROI and make better, more informed, decisions.
It can be pretty difficult to do this with AI costs compared with regular cloud costs. Thankfully, these two updates get us a little closer.
CloudWatch coding agent insights
I attended a talk recently where someone asked a CTO if he ever plans to limit the amount of AI tokens that engineers can use. He replied no, not at all. Engineers are more productive and shipping faster; they can continue using AI as much as they want.
So, I get it, you don’t want to stifle your team’s productivity. However as someone coming from FinOps, this is definitely not my point of view. I think that engineers can use AI productively yet economically, and that using the most expensive model for every task doesn’t equal more output.
Even if your engineers are more productive overall, wouldn’t you want to understand the return on investment? Or know which teams use the most tokens, and which are using hardly any?
Coding agent insights from CloudWatch lets you do this. It’s built on OpenTelemetry metrics emitted by your coding agents, and it integrates with Claude apps gateway and also supports Codex and GitHub Copilot.
So what can you do with this info? Well, a few things.
You could decide where to limit token consumption, or to enable teams who are not making the most of AI. You can also set billing alerts for tokens, and correlate agent adoption with the number of pull requests. You can also identify the models delivering the best cost-to-output ratio for your workloads.
I think the view of this CTO is pretty common right now. However I also think these days of being allowed, or even encouraged, to use as many tokens as possible are not going to last.
When companies decide to be more aware of what value coding agents bring and want to base it on more than a gut feeling, this will be a useful tool.
Bedrock standardized product metadata
On a similar note for a different problem: AWS announced standardized product metadata for Bedrock in AWS Data Exports.
Ok, what does this mean and why should you care?
Up until now if you wanted to get at that metadata and know, for example, how much you spent on input versus output tokens, you had to write and maintain a parser.
With Bedrock's standardized metadata, you can query the CUR data in Athena and break Bedrock spend down by model, provider, and inference type.
There is also now a unified "Amazon Bedrock" product family name that consolidates all Bedrock costs.
Basically, it now works how you would expect it to in the CUR.
This, together with Bedrock supporting cost allocation by IAM user and role, means that you're much closer to real unit economics for Bedrock workloads.
You can split Bedrock spend by who (IAM principal) and what (model, token type, serving mode) without writing custom parsing logic. Now add the business unit and you have your unit cost, e.g. cost per customer served or per document processed.
These two updates are a sign that AI cost visibility is catching up to what we expect from the rest of the cloud. Throw in a business metric and you now know what value Bedrock is giving you backed by numbers instead of a feeling.