How many months of data do I need?

At minimum, 2 billing periods in the file. BillSpike compares your two most recent periods to identify what changed.

Is my raw billing file stored?

No. Your file is uploaded directly to S3 via presigned URL, processed, then permanently deleted. Only the analysis findings are retained. BillSpike never stores your raw billing data.

What is the difference between vol and price in the results?

vol means you used more of the service — your usage volume increased. price means the effective unit cost went up, often because a Reserved Instance or Savings Plan expired and the workload fell back to on-demand rates.

Does BillSpike need IAM access to my AWS account?

No. BillSpike only needs the exported CUR or FOCUS file. You export it from your cloud console and upload it. No credentials, no IAM roles, no cloud account access required.

What file formats does BillSpike support?

AWS CUR 1.0 and 2.0 (CSV and Parquet), FOCUS 1.x exports from AWS, Azure, and GCP, gzipped CSV (.csv.gz), and Parquet (.parquet, .snappy.parquet). Format and cloud provider are auto-detected on upload.

2026-04-01 · FinOps

What Is the FinOps FOCUS Specification?

Cloud billing data has always been a mess for multi-cloud teams. AWS uses its Cost and Usage Report. Azure exports billing data in a completely different format. GCP has its own BigQuery billing export schema. Column names, cost categories, and even basic concepts like usage amount are defined differently across all three.

FOCUS is an attempt to fix that. It stands for FinOps Open Cost and Usage Specification, an open standard developed by the FinOps Foundation that defines a common schema for cloud billing data across providers.

What FOCUS Actually Defines

FOCUS specifies a set of column names, data types, and semantics that billing exports should conform to. Instead of line_item_usage_amount on AWS, Quantity on Azure, and usage.amount on GCP, all three would use UsageQuantity. Instead of different cost column names that mean slightly different things, FOCUS defines BilledCost, ListCost, ContractedCost, and EffectiveCost with clear semantics for each.

The specification covers billing periods and charge periods, service and resource identification, cost columns and their definitions, usage quantity and units, commitment discounts like Reserved Instances and Savings Plans, and tags and labels.

The Cost Column Problem

One of the most confusing parts of multi-cloud cost analysis is figuring out which cost column to use. AWS has unblended_cost, amortized_cost, net_amortized_cost, and others. Azure has CostInBillingCurrency, CostInPricingCurrency, and PayGPrice. GCP has cost, credits, and several sub-fields.

These columns do not mean the same things, and the differences matter. Amortized cost spreads Reserved Instance and Savings Plan fees across the usage they cover. Net cost applies negotiated discounts on top of that. Using the wrong column gives you misleading numbers when comparing spending across services or accounts.

FOCUS defines this cleanly. BilledCost is what actually gets charged to your invoice. EffectiveCost is the amortized and discounted view. ListCost is the rack rate before any discounts. The semantic definitions are part of the specification, so every provider implementing FOCUS has to mean the same thing by each column.

Where FOCUS Is Today

AWS added FOCUS-compatible exports to its Data Exports feature in late 2023. Azure and GCP have both published plans and partial implementations. The FinOps Foundation maintains the spec on GitHub and releases versioned updates.

As of early 2026, FOCUS 1.0 is the stable release. AWS's FOCUS export is the most mature implementation. Azure's implementation covers the core columns but has gaps in some areas. GCP's support is still in progress.

For most teams, the practical impact of FOCUS today is on tooling. FinOps tools that support FOCUS can ingest exports from multiple providers without building custom adapters for each one.

What It Means For Your Analysis

If you are running cost analysis on a single cloud provider, FOCUS does not change much right now. The existing native exports have more detail than the FOCUS schema, and most analysis tools already understand them.

Where FOCUS matters is in two scenarios: you are managing costs across multiple cloud providers and want a consistent view, or you are building internal tooling and want to avoid tying it to a single provider's schema.

For the multi-cloud case, a team spending $200k per month across AWS and Azure today needs to reconcile two completely different data formats to get a combined view. A FOCUS-native export from both providers makes that significantly simpler.

How FOCUS Compares to CUR 2.0

AWS CUR 2.0, introduced in late 2023, was partially designed to align with the FOCUS specification. Many of the column names and semantic definitions carry over. The key difference is that CUR 2.0 still contains a large number of AWS-specific columns that FOCUS does not define, because FOCUS is intentionally provider-agnostic.

If you are starting a new billing pipeline and have a choice between legacy CUR 1.0, CUR 2.0, and the AWS FOCUS export, CUR 2.0 is generally the best default for AWS-only analysis. The FOCUS export makes more sense if you are building tooling intended to work across providers.

BillSpike and FOCUS

BillSpike supports AWS CUR 1.0 and 2.0 and FOCUS 1.x exports from AWS, Azure, and GCP. The same variance analysis runs on all three providers because the underlying cost decomposition logic works against the FOCUS schema regardless of which cloud generated the data. As FOCUS adoption matures and provider implementations fill in the remaining gaps, multi-cloud analysis becomes a matter of uploading the right export files rather than building provider-specific pipelines.

If you are evaluating your billing export strategy, FOCUS is worth understanding now even if you are not acting on it yet. The schema is cleaner than legacy formats, the semantics are well documented, and the tooling ecosystem around it is growing quickly.

Analyze your own AWS cost spike at billspike.io