The FOCUS Specification for Kubernetes and AI Costs, Explained

Key takeaways

• FOCUS 1.4, ratified June 4, 2026, is the current version of the FinOps Open Cost and Usage Specification.
• It standardises cloud billing data at the invoice layer: column names, cost definitions, timestamps, and region identifiers become consistent across providers.
• For Kubernetes, FOCUS cleans up node-level billing data. It does not distribute node cost across namespaces or workloads.
• FOCUS 1.3 added split cost allocation columns that support EKS and ECS pod- and task-level attribution, but provider support is opt-in and not yet universal.
• FOCUS 1.4 introduced the Invoice Detail dataset for invoice reconciliation and expanded ServiceCategory to include “AI and Machine Learning.” No major AI API provider has published a formal FOCUS conformance statement as of September 2026. Token-level unit economics are planned for FOCUS 1.5, targeting December 2026.
• AWS offers native FOCUS 1.2 export (GA since November 2025). Azure supports up to FOCUS 1.2 natively. GCP offers a stable FOCUS 1.0 mapping view for BigQuery and a FOCUS 1.2 preview export.

Cloud billing exports from AWS, Azure, and GCP describe the same underlying concepts in completely different ways. Comparing spend across providers means writing a translation layer before you can write a single query. The FinOps FOCUS specification exists to end that. It defines a common schema for cloud billing data: consistent column names, consistent units, and consistent definitions across every provider that adopts it.

For Kubernetes teams, FOCUS is relevant but partial. It normalises the billing data that arrives from the cloud at the node level. It does not, by itself, attribute that cost to the namespaces, teams, or workloads sharing the node. Understanding both what FOCUS covers and what it does not is the starting point for a complete cloud FinOps practice.

What FOCUS is and who maintains it

FOCUS stands for FinOps Open Cost and Usage Specification. The FinOps Foundation published the initial version in November 2023. Since then the spec has moved through five releases: 1.0 (November 2023), 1.1 (November 2024), 1.2 (May 2025), 1.3 (December 2025), and 1.4 (June 4, 2026). The specification lives at github.com/FinOps-Open-Cost-and-Usage-Spec and runs as a Joint Development Foundation project under the Linux Foundation.

Governance sits with the FOCUS Steering Committee, whose members include AWS, Google Cloud, Microsoft, Walmart, IBM Cloudability, Adobe, Datadog, and Capital One. That list is not incidental. These organisations produce the billing exports FinOps teams parse every month. Their involvement means the standard reflects actual export formats rather than an idealised model that vendors then have to retrofit.

In practical terms, FOCUS defines the schema that a compliant billing export must follow. It specifies column names, data types, allowed values for controlled-vocabulary fields, and the units in which quantities appear. A tool or analyst that can query one compliant export can query any other without rewriting the data model.

The problem it solves: three providers, three billing schemas

Before FOCUS, comparing cloud spend across providers meant building a translation layer before writing any query. Three concrete examples illustrate why.

Amortized cost. AWS separates amortized and unblended cost into distinct columns. Azure calls the equivalent figure “Effective Cost,” and the field name shifts depending on agreement type. GCP embeds comparable data in nested JSON. FOCUS resolves all three into a single EffectiveCost column with a consistent definition.

Timestamps. AWS exports use UsageStartDate and UsageEndDate. Azure uses different field names. GCP relies on BigQuery-native timestamp formats. FOCUS standardises both to ChargePeriodStart and ChargePeriodEnd in ISO 8601, so time-series queries work without date parsing gymnastics.

Region identifiers. AWS says us-east-1. Azure says eastus. GCP says us-east1. FOCUS maps each to a normalised RegionId and preserves the provider’s original label in RegionName. Cross-provider region comparisons stop requiring a lookup table.

These are not edge cases. Every multi-cloud cost query touches at least one of them. Without FOCUS, the choices were a fragile ETL job maintained per provider, or separate FinOps tooling for each cloud.

What FOCUS standardises: the core columns

FOCUS defines columns across seven functional groups. Version 1.4 added 47 new columns, 6 new attributes, and 2 new datasets (Invoice Detail and Billing Period), which signals how quickly the spec is maturing beyond its initial scope.

ChargeCategory uses a controlled vocabulary: Usage, Purchase, Credit, Adjustment, Tax. That means credit line items, reserved instance purchases, and standard usage all sort cleanly without provider-specific string matching in your queries.

ServiceCategory is similarly controlled. It includes “AI and Machine Learning” as a defined value, so AI API charges from supported providers already receive consistent categorisation in a compliant export.

The four cost columns in the Costs group (BilledCost, EffectiveCost, ListCost, ContractedCost) represent four price points for the same charge. Together they let you compute discount coverage, commitment utilisation, and list-price waste without joining external rate card data.

CommitmentDiscountCategory, CommitmentDiscountId, CommitmentDiscountType, and CommitmentDiscountStatus have been part of the FOCUS specification since 1.0. For FinOps teams managing reserved capacity and committed use discounts across Kubernetes infrastructure, these columns standardise tracking of Reserved Instance, Savings Plan, and CUD coverage in a single schema, across AWS, Azure, and GCP. Discount utilisation and coverage queries run against a consistent column set regardless of which provider’s commitment product is in use. FOCUS 1.3 also introduced the Contract Commitment dataset: a separate, standalone dataset for tracking commitment contract terms, expiry dates, and coverage periods for RI, Savings Plan, and CUD agreements.

What it means for Kubernetes cost allocation

A Kubernetes cluster running on EC2 or Azure VMs appears in cloud billing exports as compute charges at the node level. FOCUS normalises those charges at the billing boundary. The result is cleaner node-level data when it arrives in your data warehouse or FinOps tool: consistent column names, consistent cost definitions, no provider-specific aliases to account for.

What FOCUS does not change is how that node cost distributes across workloads. A cluster with five namespaces still appears as one line item per node per charge period. The node-level cost lands correctly in a FOCUS-compliant export. The question of how much each namespace contributed to that cost lives entirely outside the FOCUS schema.

FOCUS 1.3 introduced SplitCostAllocationData. This column maps to AWS’s Split Cost Allocation Data feature, which covers both EKS and ECS workloads. It lets the cloud provider attribute pod- or task-level charges back to specific workloads before the data reaches your export. For EKS and ECS teams with this feature enabled, that is a real improvement: attribution flows through a FOCUS-compliant column rather than a proprietary side table.

Two constraints limit how far this goes. First, it requires the cloud provider to perform the split: GCP and Azure do not offer equivalent attribution at the provider layer yet. Second, EKS split cost allocation itself requires opt-in configuration. Teams running GKE or AKS do not get equivalent FOCUS-native coverage today.

For a deeper view of what Kubernetes cost allocation actually requires at the cluster level, see our post on Kubernetes cost allocation.

What FOCUS does not cover: in-cluster allocation

FOCUS solves the invoice normalisation problem. It does not solve the Kubernetes cost allocation problem. Being clear about that distinction prevents false confidence in what a FOCUS export can answer.

The gaps that remain after FOCUS adoption:

• Pod-level billing. No FOCUS column captures per-pod cost. Pods share nodes and therefore share cost by definition at the billing layer.
• Namespace-to-team attribution. Mapping namespace spend to engineering teams, cost centres, or product lines requires tooling that understands Kubernetes resource metadata — not just billing exports.
• Idle capacity. Overprovisioned nodes generate real cost. FOCUS records that cost at the node level but does not classify any portion of it as idle or wasted capacity.
• Workload-level views. Deployment, DaemonSet, and Job-level cost breakdowns sit outside FOCUS scope entirely.

These are not criticisms of FOCUS. The specification targets billing export normalisation, not cluster-level observability. The two concerns operate at different layers, and addressing both requires different tooling. For teams implementing chargeback and showback, see our post on Kubernetes chargeback and showback.

Where AI, token and inference spend sit today

FOCUS 1.2 added handling for virtual currencies, including tokens and credits. AI API invoices sometimes express cost in token units before converting to a dollar amount. With 1.2, those figures can appear in billing data with proper currency normalisation rather than landing in a catch-all field.

FOCUS 1.4 introduced the Invoice Detail dataset for invoice reconciliation, covering payment terms, due dates, and purchase order numbers. FOCUS 1.4 also expanded the ServiceCategory vocabulary to include “AI and Machine Learning” as a valid charge category, and uses AI API providers as worked examples in the spec documentation. However, no major AI API provider has published a formal FOCUS conformance statement as of September 2026, direct AI token billing remains outside the scope of what today’s FOCUS implementations normalise.

What 1.4 does not do is bridge the gap between AI API spend and Kubernetes workload spend. If your inference service runs in a Kubernetes namespace and calls an external LLM API, the Kubernetes node cost and the API token cost remain in separate billing streams. Joining them requires instrumentation at the application layer. FOCUS schema normalisation does not close that join.

The FOCUS 1.5 roadmap, announced at FinOps X 2026, includes native token and unit economics tracking with a planned December 2026 target. That work is not yet shipped. Until it arrives, token-level cost attribution inside Kubernetes workloads remains a tooling problem outside the standard’s current scope. For the current practical approach, see our post on AI token cost management in Kubernetes.

Adoption: which providers and tools support it

AWS offers native FOCUS 1.2 export, generally available since November 2025, through Data Exports (formerly Cost and Usage Reports). Files land in an S3 bucket as Parquet. CUR 2.0 aligns more closely with the FOCUS schema than the original CUR format, though it predates the specification and is not fully FOCUS-compliant.

Azure supports native FOCUS export up to version 1.2 via Cost Management. Exports deliver CSV or Parquet to Blob Storage. Microsoft has announced plans to extend support to FOCUS 1.4.

GCP does not yet offer a native FOCUS export as generally available. For stable coverage, teams can apply the FOCUS 1.0 mapping view from the specification’s GitHub repository to their BigQuery billing dataset. GCP also offers a FOCUS 1.2 preview BigQuery export for teams that want to evaluate the newer schema ahead of GA availability.

Other providers. OCI and Tencent both offer FOCUS 1.0 exports. SaaS vendors including Datadog, Cloudflare, Snowflake, and Fastly expose FOCUS-aligned data, though full schema export coverage varies by vendor and version.

FinOps tools. Apptio, Cloudfix, and Flexera all ingest FOCUS-formatted data. OpenCost has FOCUS ingestion on its roadmap.

What to do now

Enabling FOCUS export is straightforward on AWS and Azure. GCP requires one additional step, with a preview path available for teams that want FOCUS 1.2 schema coverage now.

AWS

1. Open AWS Data Exports in the console.
2. Create or modify a Cost and Usage Report.
3. Select FOCUS as the export format (exports FOCUS 1.2).
4. Data lands in your designated S3 bucket as Parquet files.

Azure

1. Open Cost Management in the Azure portal.
2. Navigate to Exports.
3. Select FOCUS as the export format.
4. Data delivers to Blob Storage as CSV or Parquet.

GCP

GCP offers two paths. For the stable FOCUS 1.0 view:

1. Enable BigQuery billing export in the GCP console.
2. Clone the FOCUS 1.0 mapping view from github.com/FinOps-Open-Cost-and-Usage-Spec.
3. Apply the view to your billing dataset in BigQuery.

For teams that want FOCUS 1.2 schema coverage now, GCP also offers a FOCUS 1.2 preview BigQuery export. Enable it through the same BigQuery billing export settings and opt in to the preview dataset. Treat it as pre-GA: schema may shift before the feature becomes generally available.

Once FOCUS data flows into your data warehouse or FinOps tool, multi-cloud cost queries can use consistent column names rather than provider-specific aliases. That is the immediate, concrete win. For the layer below — namespace attribution, chargeback, and workload-level cost allocation — see our post on Kubernetes cost monitoring.

Conclusion

FOCUS is the most significant infrastructure piece the FinOps community has produced to date. By giving billing data a common shape, it turns multi-cloud cost analysis from a translation problem into a query problem. That matters most for teams running workloads across AWS, Azure, and GCP who previously maintained bespoke ETL logic for each provider.

For Kubernetes teams specifically, FOCUS cleans up the invoice layer. It does not solve in-cluster cost attribution. A shared cluster with five namespaces still lands as node-level line items in a FOCUS export. Knowing which team owns which spend inside that cluster requires a separate layer that understands Kubernetes resource metadata.

Cast AI operates in exactly that gap. Where FOCUS normalises what the cloud invoice says about your nodes, Cast AI attributes that cost to the namespaces, teams, and workloads running inside them. It also handles pod rightsizing and autonomous scaling so the total node cost that FOCUS records is lower to begin with. Together they cover the full FinOps stack: FOCUS handles the billing boundary, Cast AI handles everything inside the cluster.

Frequently Asked Questions