What Is FOCUS? The Standard for Multi-Cloud Cost Data

FOCUS is the FinOps Open Cost and Usage Specification, an open spec maintained by the FinOps Foundation that defines 65 standardized columns for cloud billing data so cost records from any provider use the same schema. AWS has full native support through CUR 2.0 in FOCUS format, Azure Cost Management exports FOCUS natively to Blob Storage, and GCP is partial: no native export yet, but Google publishes a SQL template that creates a FOCUS-compatible view on top of Detailed billing exports in BigQuery, with a native GCP export in private preview. For multi-cloud teams, that gap makes GCP the current friction point. The payoff of the standardized shape is that a cross-cloud question like total compute spend by provider becomes one GROUP BY on Provider and ServiceCategory instead of three ETL pipelines with per-provider mapping logic.

What FOCUS Actually Is

FOCUS (FinOps Open Cost and Usage Specification) is an open technical specification maintained by the FinOps Foundation, part of the Linux Foundation. It defines a vendor-neutral schema for cloud billing data so that cost and usage records from any provider use the same column names, the same definitions, and the same semantics.

Think of it like this: before FOCUS, every cloud provider invented its own language for billing. AWS calls it a Cost and Usage Report with hundreds of cryptically named columns. GCP pipes billing into BigQuery with its own structure. Azure exports CSVs with yet another schema. If you wanted to answer a simple question like "how much are we spending on compute across all three clouds," you had to build and maintain three separate data pipelines, map concepts manually, and hope you got the definitions right.

FOCUS gives every provider a common output format. When AWS, GCP, and Azure all export FOCUS-formatted data, those three separate pipelines collapse into one.

The Core Schema

As of version 1.2, FOCUS defines 65 standardized columns grouped into categories that cover everything a FinOps practitioner needs.

The Four Cost Columns

This is where FOCUS adds the most clarity. Instead of each provider defining "cost" differently, FOCUS separates it into four distinct measures:

Service Normalization

FOCUS standardizes how services are categorized:

• ServiceName: The provider's name for the service (e.g., "Amazon EC2", "Compute Engine", "Virtual Machines")
• ServiceCategory: A normalized category (Compute, Storage, Network, Database, AI/ML, etc.)
• Provider: Which cloud provider (AWS, GCP, Azure)

Commitment Discount Handling

Every cloud provider handles commitment discounts differently. AWS has Reserved Instances and Savings Plans. GCP has Committed Use Discounts. Azure has Reservations and Savings Plans.

FOCUS normalizes this through CommitmentDiscountStatus and the EffectiveCost column. Instead of parsing provider-specific discount columns, you check whether a line item was covered by a commitment and what the effective cost was after the discount. One pattern works across all three clouds.

Extension Columns

Providers can add cloud-specific columns prefixed with x_. For example: x_gcp_project_id, x_aws_account_id, x_azure_subscription_id. These preserve provider-specific detail without breaking the standard schema. Your cross-cloud queries use the standard columns, and your provider-specific queries can still access the extensions.

Where Each Provider Stands

FOCUS adoption is real but uneven. Here is where things stand as of early 2026:

AWS: Full Native Support

AWS was the first major provider to ship native FOCUS exports. Their CUR 2.0 (Cost and Usage Report version 2) can output FOCUS 1.2 formatted Parquet files to S3. It is generally available and production-ready.

AWS has also published a conformance report documenting known gaps where their implementation deviates from the spec. This transparency is useful because no provider achieves 100% conformance yet, and knowing where the gaps are matters more than pretending they do not exist.

Azure: Full Native Support

Azure Cost Management exports FOCUS-formatted data natively to Blob Storage. Microsoft has been an active contributor to the FOCUS specification and publishes their own conformance report.

If you are already using Azure Cost Management exports, switching to the FOCUS format is straightforward. The schema changes but the export mechanism stays the same.

GCP: Work in Progress

GCP is behind on native FOCUS support. There is no one-click FOCUS export today. Google provides a SQL template that creates a FOCUS-compatible view on top of your existing billing export in BigQuery, but it requires both Detailed and Pricing exports to be enabled, and the mapping is manual.

A native FOCUS BigQuery export is reportedly in private preview, but there is no public GA date. For teams using GCP as their primary or only cloud, this means you either build the mapping yourself using Google's SQL template, use a third-party tool that handles the conversion, or wait.

For multi-cloud teams that include GCP, this gap is the biggest practical obstacle to a fully standardized cost data pipeline today.

Version History

FOCUS has moved quickly for an industry specification:

What This Means in Practice

Single Query Across Clouds

The most immediate benefit is that you can drop AWS, Azure, and GCP cost data into the same warehouse with the same column names. A query like "show me total compute spend by provider for the last 6 months" works without any transformation code.

Before FOCUS, that query required three separate ETL pipelines, a mapping table, and ongoing maintenance every time a provider changed their billing format. With FOCUS, it is a GROUP BY on Provider and ServiceCategory.

Standardized KPIs

Cost projections, anomaly detection, and commitment discount utilization analysis all work consistently regardless of provider. You build the logic once against the FOCUS schema, and it applies everywhere.

Tooling Convergence

FinOps platforms, BI tools, and internal dashboards are increasingly built to ingest FOCUS natively. If you are evaluating cost management tools in 2026, asking "do you support FOCUS?" is a reasonable baseline question. A vendor without a FOCUS strategy is a yellow flag.

Adding New Providers

If your organization adds Oracle Cloud, Alibaba Cloud, or any other provider that exports FOCUS-formatted data, your existing analytics and dashboards work without schema changes. This future-proofing is one of the strongest practical arguments for adopting FOCUS now rather than building provider-specific pipelines.

Common Misconceptions

"FOCUS replaces CUR/billing exports." No. FOCUS is an output format that providers map their native data into. You still enable billing exports the same way you always have. FOCUS standardizes what the output looks like.

"FOCUS means all providers report data the same way." Not yet. Conformance is not 100% for any provider. There are edge cases, gaps, and interpretation differences. Always review each provider's published conformance report before assuming the data is perfectly normalized.

"You need FOCUS to do multi-cloud cost management." You do not need it, but without it you are building and maintaining the normalization layer yourself. FOCUS eliminates that work for teams that adopt it.

"FOCUS is only for large enterprises." The specification is open and free. The biggest beneficiaries are actually smaller teams that cannot afford to build custom ETL pipelines for each cloud provider. If you have two or three engineers managing costs across clouds, FOCUS saves you from building infrastructure that larger companies staff entire teams for.

Getting Started

If you want to start using FOCUS today:

1. AWS: Enable CUR 2.0 with FOCUS format in the Billing and Cost Management console. Data exports to S3 in Parquet format.
2. Azure: Configure Cost Management exports with the FOCUS schema. Data exports to Blob Storage.
3. GCP: Enable Detailed billing export and Pricing export to BigQuery, then apply Google's FOCUS SQL template to create a compatible view. Watch for the native export to reach GA.
4. Centralize: Land all FOCUS data in a single warehouse (BigQuery, Redshift, Snowflake, or any analytics platform). The standard schema means no transformation is needed between providers.
5. Query: Use ServiceCategory, EffectiveCost, Provider, and Region as your primary dimensions. Most cross-cloud questions can be answered with these four columns.

The Bottom Line

FOCUS is not a theoretical standard. AWS and Azure already export it natively. GCP is catching up. The FinOps Foundation is actively developing it with input from the major providers.

For teams managing cloud costs across multiple providers, the question is not whether to adopt FOCUS but when. Every month you spend building or maintaining custom billing data pipelines is a month you could have spent on analysis and optimization instead.

The standard is not perfect. Conformance gaps exist. GCP's native support is not ready yet. But the direction is clear, and the earlier you align your cost data infrastructure with FOCUS, the less migration work you face later.

Struggling to make sense of cloud billing data across providers? Brain Agents AI normalizes your cost data using the FOCUS specification and delivers actionable insights across GCP and AWS, without the ETL headache. (FOCUS itself is a multi-cloud spec that covers Azure as well; our beta ships GCP and AWS with Azure on the roadmap.)

Related Articles:

• Multi-Cloud Cost Management: How to Stop Losing Money Across AWS, Azure, and GCP
• AWS Cost Optimization Guide: Practical Strategies That Actually Work
• Azure Cost Optimization Guide: Practical Strategies That Actually Work
• GCP Billing Export to BigQuery: Complete Setup Guide