AWS Cost Foundations Series · Part 2
In the previous guide, I showed how to enable AWS Data Exports and configure CUR 2.0.
If you have not enabled Data Exports yet, start with Part 1.The next question is usually: should I use CUR 2.0 or FOCUS?
That is the recommendation. The reason is simple: the two formats are built for different jobs.
AWS-native investigation dataset
Preserves the AWS-specific detail you need when the bill changes and an engineer needs to explain why.
Standardized reporting dataset
Maps provider billing into a common model that works better for finance, dashboards, and cross-cloud views.
FinOps nerd corner: CUR 2.0 currently exposes roughly 115-131 available fields depending on export options and enabled AWS billing features. FOCUS exposes roughly 60 standardized fields.
That sounds like a huge difference, but it is mostly intentional. CUR preserves AWS-specific concepts like resource IDs, Split Cost Allocation, Savings Plan allocation, Reserved Instance allocation, Capacity Reservation attributes, and IAM principal allocation.
FOCUS normalizes cost data into a common schema for AWS, Azure, GCP, and SaaS providers. CUR is trying to describe AWS accurately. FOCUS is trying to describe cloud spending consistently.
What changed?
Historically, AWS customers enabled Cost and Usage Reports (CUR), and that became the billing dataset everyone built around.
Today, AWS Data Exports supports multiple billing schemas, including CUR 2.0 and FOCUS. Both are valid. Both are supported by AWS. Both contain cost and usage data.
The difference is in how that data is represented.
CUR 2.0: the AWS-native dataset
CUR 2.0 keeps the AWS-specific detail. Resource IDs. Split Cost Allocation. Savings Plans and Reserved Instances. Capacity reservations. Service-specific billing attributes.
That detail matters when you are trying to explain a real AWS bill, not just summarize it.
FOCUS: the standardized dataset
FOCUS, the FinOps Open Cost and Usage Specification, takes provider billing data and maps it into a shared schema.
It does not try to preserve every AWS-specific detail. It tries to make costs easier to compare across providers.
That is useful when the audience is finance, leadership, or anyone trying to look across AWS, Azure, Google Cloud, and SaaS spend without learning every provider's billing vocabulary.
A quick example
Finance asks: "How much are we spending across AWS, Azure, and GCP?" Use FOCUS.
An engineer asks: "Why did our EKS platform costs increase 35%?" Use CUR 2.0.
That is the split. CUR helps you answer "why did this happen?" FOCUS helps you answer "what are we spending across everything?"
Practical comparison
| Use case | CUR 2.0 | FOCUS |
|---|---|---|
| EKS/ECS split cost allocation | Strong | Limited |
| Resource-level AWS investigation | Strong | Limited |
| Savings Plans and RI analysis | Strong | Standardized |
| Multi-cloud reporting | Weak | Strong |
| Executive dashboards | Possible | Strong |
| Finance reporting | Possible | Strong |
| Deep AWS forensics | Strong | Weak |
What I recommend
AWS-only environments: enable CUR 2.0 first. Preserve the richest AWS billing dataset available.
Multi-cloud environments: enable CUR 2.0 and FOCUS. Use CUR when you need AWS detail. Use FOCUS when you need a cleaner view across providers.
Storage is inexpensive. Historical billing data is valuable.
You can always simplify billing data later. You cannot recover billing data that was never collected.
What's next
Enabling Data Exports is only the first step. In the next guide, we will look at what to do with CUR data once it starts arriving, including Athena, dashboards, FinOps tooling, and when you might not need any of them yet.
Back to Guides