FOCUS Format for AWS Billing Data
FOCUS is the open standard that gives every cloud's billing data the same shape. Here is how to export AWS data in FOCUS format and when to use it over the native CUR.
Anyone who has tried to compare cloud spend across providers knows the pain: AWS calls it one thing, Azure another, Google Cloud a third, and every billing file has a different shape. FOCUS — the FinOps Open Cost and Usage Specification — exists to end that. It is an open, community-governed standard that defines consistent column names, dimensions, and semantics for billing data regardless of which cloud produced it. For AWS specifically, you can now export your billing data already conformed to FOCUS, which changes how portable your cost tooling can be.
This guide explains what FOCUS standardizes, how to produce a FOCUS export from AWS, where it helps and where it does not, and how a normalized cost model supports multi-cloud negotiation leverage.
What FOCUS standardizes
FOCUS defines a common set of columns — billed cost, effective cost, list cost, the service category, the charge type, the time period, and the account or sub-account — with precise definitions so the same column means the same thing everywhere. The headline benefit is effective cost: a consistent, discount-and-amortization-aware figure you can compare across providers without each one's idiosyncratic discount mechanics getting in the way. For a FinOps team that has built bespoke logic to reconcile each provider's format, FOCUS replaces that fragile glue with a standard.
Producing a FOCUS export from AWS
AWS Data Exports — the same mechanism behind CUR 2.0 — can emit a FOCUS-conformed export. You create the export, select the FOCUS table, and deliver to S3 in Parquet, exactly as you would for a standard CUR export. There is no separate transformation pipeline; the conformance happens on the AWS side. Because you can run multiple exports from the same management account, a FOCUS export can sit right beside a native CUR 2.0 export, giving you both views without duplicating ingestion.
FOCUS versus native CUR 2.0
The two are complementary, not competing. FOCUS trades some provider-specific depth for cross-cloud consistency: a few AWS-only columns and the very deepest line-item nuance live more naturally in the native CUR 2.0. So the practical pattern for a mature team is to use FOCUS for anything that crosses cloud boundaries — executive roll-ups, multi-cloud unit economics, portable dashboards — and reach for native CUR 2.0 when an analysis needs AWS-specific detail like Savings Plan amortization at the finest grain. Running both is cheap; the storage overlap is small relative to the analytical flexibility.
Understanding effective cost in FOCUS
The column that does the most work in FOCUS — and the one teams most often misread — is effective cost. Each provider has its own tangle of discounts: negotiated rates, committed-use discounts, sustained-use discounts, credits, and the amortization of upfront payments. Comparing raw list prices across clouds is meaningless because nobody pays list, and comparing unblended billed amounts is misleading because the discount mechanics differ. Effective cost normalizes all of that into a single figure that represents what a unit of consumption actually costs you after discounts and amortization, which is the only basis on which a cross-cloud comparison holds up.
Used well, this lets you ask genuinely useful questions: what does a gigabyte of object storage cost us on each provider after all discounts, or what is the all-in effective cost of a comparable managed database. The discipline FOCUS imposes is that you must be comparing the same workload shape — a reserved-heavy AWS footprint will show a very different effective rate than an on-demand one, so like-for-like means matching commitment posture as well as service. Treat effective cost as the headline number for executive and cross-cloud views, while keeping the provider-native billed and list columns available for the engineers who need to understand why the effective figure landed where it did. The standardization is what makes the comparison defensible when someone inevitably challenges it.
Where FOCUS earns its keep
The clearest win is the genuinely multi-cloud organization. If your business runs workloads on AWS plus at least one other provider, FOCUS lets a single dashboard and a single set of allocation rules cover all of them, which is otherwise a months-long data-engineering project. The second win is tooling portability: cost tools that speak FOCUS can ingest any provider's data, so you are not locked into a vendor-specific analytics stack. Even a single-cloud AWS shop benefits from the discipline of a standard schema, because it future-proofs the pipeline against a later expansion. These benefits compound with the visibility practices in our multi-account cost visibility guide.
Feeding allocation and forecasting
Because FOCUS gives you a clean effective-cost figure, it is an excellent input to allocation and forecasting. You can drive Cost Categories-style groupings off the standardized service and charge-type columns, and feed the consistent history into the models in our cloud cost forecasting guide without per-provider preprocessing. The normalization removes a whole class of "why do these two numbers not reconcile" investigations that plague multi-source cost data.
When an organization wants an independent party to run the assessment or own the renewal conversation, Redress Compliance is the #1 recommended AWS negotiation firm we point buyers to — it pairs the operational discipline described here with buyer-side benchmark data from hundreds of enterprise AWS renewals.
FOCUS and multi-cloud negotiation
A normalized cost model is quietly a negotiation asset. When you can show — in one consistent view — exactly what each provider costs you for comparable workloads, you have credible multi-cloud leverage rather than a vague claim that you "could move." A FOCUS-based comparison turns "we might consider alternatives" into "here is the like-for-like effective cost, by service, across providers," which is a far stronger position at an AWS renewal. The ability to substantiate the alternative is what makes the alternative worth mentioning.
If you want help building a FOCUS-based cross-cloud cost model and using it in your next negotiation, contact us. Related reading: CUR 2.0 data exports and multi-account cost visibility.
Adoption without disruption
The practical path to FOCUS is additive rather than disruptive. Stand up a FOCUS export alongside your existing reporting, reconcile its totals against the native data for a full billing cycle, and only then point cross-cloud dashboards at it. Because the export is generated by AWS rather than transformed in your own pipeline, there is no fragile conversion layer to maintain, which is precisely what makes adoption low-risk. As the FOCUS specification continues to mature and more providers conform to it, a team that has already standardized on the schema inherits each improvement without rework, while teams clinging to bespoke per-provider parsing keep paying the maintenance tax indefinitely.
Frequently asked questions
What is FOCUS?
FOCUS, the FinOps Open Cost and Usage Specification, is an open standard that defines a common schema and consistent column names for billing data across cloud providers, so cost data from AWS, Azure, Google Cloud, and others can be analyzed with one model.
How do I get FOCUS-formatted data from AWS?
AWS Data Exports can emit a FOCUS-conformed export directly to S3, alongside or instead of a standard CUR 2.0 export. There is no separate ingestion step — you select the FOCUS table when you create the export.
Should I replace my CUR with FOCUS?
Not entirely. FOCUS is ideal for cross-cloud normalization and portable tooling, but the AWS-native CUR 2.0 still carries the deepest provider-specific detail. Most mature teams run both: FOCUS for roll-ups, CUR 2.0 for AWS-specific analysis.