AWS CUR 2.0 for FinOps: From Bedrock Cost Data to Ownership

Amazon Bedrock can now tell you more about who is using what.

That is useful. It is not the same as knowing who owns the cost.

AWS CUR 2.0 can include the IAM principal behind a Bedrock inference request. In other words, the cost data may now show the IAM user, role or federated identity that made the call.

For a FinOps team, that is a meaningful step forward.

It is also where the real work begins.

An IAM principal can identify a technical caller. It does not automatically tell Finance whether the cost belongs to a product, a customer, a shared platform service or an experiment that should have ended three weeks ago.

This is the practical challenge behind AWS CUR 2.0 FinOps: turning richer source data into a cost view that people can actually use to make decisions.

What AWS CUR 2.0 changes

AWS recommends Cost and Usage Report 2.0, delivered through AWS Data Exports, as its detailed cost and usage data source. Compared with the original CUR, it has a more consistent schema, nested data and additional columns. AWS documents the differences here.

For Amazon Bedrock, the detail can go further.

CUR 2.0 provides line-item information for inference requests, including separate entries for different token types. When caller identity allocation data is enabled, it can also include the IAM principal responsible for the request. AWS explains how to read the Bedrock data here.

AWS also allows teams to tag IAM users and roles with dimensions such as team, project or cost centre, then use those tags to analyse Bedrock inference costs. Its Bedrock attribution announcement shows how this works.

That creates much better Amazon Bedrock cost data than one monthly total.

It does not remove the need for FinOps.

Technical attribution is not business ownership

A role called ProductionAppRole may be useful to an engineer. It is not necessarily useful to a Finance partner who needs to understand which product or customer is carrying the cost.

That final connection still needs business context.

• Which product or workload is this supporting?
• Is the cost direct, shared or customer-facing?
• Does the caller identity map cleanly to one team, or does it represent a platform used by several?
• What should happen when that usage changes?

This is not a flaw in AWS data. It is simply the line between a technical identifier and a financial operating model.

The FinOps Foundation describes FinOps as a cross-functional practice where Engineering, Finance and Product share responsibility for technology value. That shared ownership is the point. Better cost data helps the conversation. It does not have the conversation for you.

The CUR 2.0 readiness check

Before treating new Bedrock data as ready for reporting, allocation or chargeback, run this short check:

One practical caveat: enabling caller identity data can create more rows in the export. That is expected. AWS notes this in its CUR 2.0 implementation guidance, so teams should plan for the added data volume rather than discovering it after the fact. AWS’s hands-on setup guide is useful for the AWS configuration itself.

The harder part is not turning the setting on.

It is deciding what the resulting data should mean inside the organisation.

Reliable cost data is an operating responsibility

Cost data sits underneath more decisions than people realise.

It feeds allocation, unit economics, budgets, forecasts, showback, chargeback and optimisation priorities. When a provider changes the source data, someone needs to confirm that those downstream decisions still rest on the same logic.

That maintenance work is easy to overlook when teams decide whether to build or buy parts of their FinOps stack.

A custom data pipeline can be the right choice when the business logic is genuinely unique. But the team also needs to own schema changes, ingestion updates, validation, historical consistency and every downstream dependency.

That is the question behind Build vs Buy in FinOps: not only “can we build this?”, but “do we want to keep operating it?”

For AI, this matters even more. Bedrock usage can now be attributed more precisely, but the business still needs to decide whether a given model call belongs to a feature, a customer, a platform team or an internal use case. That is the same ownership problem explored in AI Cost Management Should Not Sit Outside FinOps.

What Umbrella support for CUR 2.0 means in practice

Umbrella supports AWS CUR 2.0 for new AWS accounts and brings the richer Amazon Bedrock cost and usage data into Umbrella AI Cost.

Where the AWS export includes caller-identity information, Umbrella can bring that detail into the same FinOps environment teams use for cloud cost. From there, it can be interpreted alongside business mapping, allocation logic and the broader cost picture.

Migration support for existing AWS accounts is coming next.

The value is not simply that another data export is connected.

It is that when AWS makes the data more useful, Umbrella customers can use it without turning every provider update into a new internal data project.

More detail should lead to a better decision

AWS CUR 2.0 gives FinOps teams more useful Bedrock detail.

The real test is whether that detail helps answer a decision:

• Is this spend expected?
• Who is accountable for it?
• What business activity does it support?
• Is there a next action?

If the data stops at a technical identity, the organisation has more columns but not necessarily more clarity.

If it connects to ownership and business context, it becomes a much better starting point for FinOps.

See how Umbrella connects cloud and AI cost data to the business context and workflows behind it.