FOCUS 1.2 Multi-Cloud Gids (2026)

Q: Ondersteunt FOCUS Kubernetes-kosten?

FOCUS 1.1 introduceerde de CapacityReservationId -kolom die node-pool toewijzing mogelijk maakt, maar echte pod-level allocation komt uit OpenCost of Kubecost, die vervolgens FOCUS-conforme output produceren die je in dezelfde datalake kunt joinen.

Bijgewerkt: 25 augustus 2026

De FOCUS specificatie (FinOps Open Cost and Usage Specification) is een open standaard van de FinOps Foundation die facturatiegegevens van elke cloudprovider omzet naar één uniform schema met vaste kolomnamen en semantiek. In 2026 exporteren AWS, Azure, Google Cloud, Oracle Cloud en IBM Cloud allemaal een FOCUS-conforme dataset, waardoor multi-cloud kostenanalyse eindelijk zonder maatwerk ETL kan. Deze gids laat zien hoe je FOCUS 1.2 exports activeert, de belangrijkste kolommen leest en met één SQL query de kosten over drie clouds tegelijk analyseert.

FOCUS 1.2 (mei 2026) voegt CommitmentDiscountUnit en SkuMeter toe aan de kernkolommen en is achterwaarts compatibel met 1.0/1.1.
AWS levert FOCUS via Data Exports (opvolger van CUR 2.0), Azure via Cost Management exports en GCP via Cloud Billing FOCUS export naar BigQuery of Cloud Storage.
BilledCost, EffectiveCost, ListCost en ContractedCost zijn vier verschillende getallen die vaak door elkaar worden gehaald. Verkeerd kolomgebruik leidt tot rapportages die tot 40% afwijken.
Met FOCUS kun je één DuckDB- of BigQuery-query schrijven die AWS, Azure en GCP tegelijk aggregeert per ServiceCategory en ChargeCategory.
Tools zoals Vantage, CloudZero, OpenCost, Kubecost en Finout hebben in 2026 native FOCUS 1.1+ ingest. Geen custom parsers meer nodig.
Migreren van native billing exports naar FOCUS kost typisch twee tot vier sprints en verlaagt de onderhoudslast van je FinOps-datalake met ongeveer 60%.

Wat is de FOCUS specificatie?

FOCUS is een gemeenschappelijk gepubliceerd, vendor-neutraal datamodel dat cloudfacturatie beschrijft in ongeveer 50 gestandaardiseerde kolommen. De FinOps Foundation FOCUS working group beheert het schema, en versienummers werken zoals een API-contract: 1.0 werd in juni 2024 uitgebracht, 1.1 in mei 2025 en 1.2 in mei 2026. Elke minor release voegt kolommen toe zonder bestaande semantiek te breken. Een export die geldig is voor 1.0, blijft leesbaar door 1.2-consumers.

Vóór FOCUS moest elke FinOps-praktijk zelf ETL bouwen voor drie totaal verschillende bestandsformaten. AWS' Cost and Usage Report (CUR) met ~150 kolommen waarvan de meeste per servicetype andere betekenissen hebben, Azure's Cost Management export met camelCase-namen en subscription-gerichte hiërarchie, en GCP's BigQuery billing export met geneste STRUCT-velden voor labels en credits. Ik heb bij Vantage bijna twee jaar besteed aan het onderhouden van die parsers. Toen FOCUS 1.0 uitkwam kon ongeveer 4.000 regels transformatiecode gewoon weg. Best een goed gevoel, eerlijk gezegd.

De belofte van FOCUS is niet dat facturen goedkoper worden, maar dat de tijd tussen "vraag" en "grafiek" van dagen naar minuten gaat. "Wat kost service X globaal deze maand, over alle providers?" wordt één query in plaats van een sprint werk.

Welke cloud providers ondersteunen FOCUS in 2026?

Alle grote hyperscalers en verschillende SaaS-leveranciers leveren in 2026 een productie-FOCUS export. De onderstaande tabel vat de status samen op het moment van schrijven, augustus 2026.

Provider	Export mechanisme	FOCUS versie	Frequentie	Bestemming
AWS	Data Exports (FOCUS 1.0 view)	1.1 (GA), 1.2 (preview)	Dagelijks, herrekend	S3 (Parquet of CSV)
Microsoft Azure	Cost Management FOCUS export	1.2 (GA)	Dagelijks	Azure Blob Storage
Google Cloud	Cloud Billing FOCUS export	1.1 (GA), 1.2 (preview)	Streaming naar BigQuery of dagelijks naar GCS	BigQuery of Cloud Storage
Oracle Cloud (OCI)	FOCUS Cost Reports	1.1 (GA)	Dagelijks	OCI Object Storage
IBM Cloud	FOCUS Billing Report	1.0 (GA)	Maandelijks	IBM Cloud Object Storage
Snowflake	Native ACCOUNT_USAGE FOCUS view	1.1 (GA)	Real-time	Snowflake tabel

Belangrijk om te weten: AWS levert FOCUS 1.1 via de nieuwe Data Exports service, niet meer via de klassieke Cost and Usage Reports (CUR) legacy endpoint. Als je nog CUR 2.0 draait, blijft die werken, maar nieuwe accounts krijgen alleen Data Exports te zien in de Billing console.

De Alibaba Cloud FOCUS export staat volgens de FinOps Foundation roadmap voor Q4 2026 gepland, en er zijn community-onderhouden adapters voor DigitalOcean, Linode en Hetzner die de billing API's naar een FOCUS 1.1 Parquet-bestand vertalen.

De kernkolommen van FOCUS 1.2 uitgelegd

Een FOCUS 1.2 dataset heeft 50 gedefinieerde kolommen, gegroepeerd in acht categorieën. De belangrijkste die je vrijwel altijd gebruikt in analytics:

Identifiers: BillingAccountId, SubAccountId, InvoiceIssuerName, ProviderName, PublisherName. Voor AWS is BillingAccountId het payer-account en SubAccountId het linked account. Voor Azure is het respectievelijk de billing account en subscription.
Tijd: ChargePeriodStart en ChargePeriodEnd (wanneer de service werd verbruikt), BillingPeriodStart en BillingPeriodEnd (de factuurmaand).
Kosten: BilledCost, EffectiveCost, ListCost, ContractedCost. Zie de aparte sectie verderop, want dit is de meest verwarrende groep.
Service classificatie: ServiceCategory (bijv. "Compute", "Storage", "AI and Machine Learning"), ServiceSubcategory (nieuw in 1.1) en ServiceName (bijv. "Amazon Elastic Compute Cloud").
Charge classificatie: ChargeCategory, één van "Usage", "Purchase", "Tax", "Credit" of "Adjustment". Dit is de kolom waarop je moet filteren om alleen echte verbruikkosten te zien.
Prijsstelling: PricingCategory ("Standard", "Committed", "Spot", "Reserved"), PricingQuantity, PricingUnit. FOCUS 1.2 voegt SkuMeter toe voor fijnere sub-SKU disambiguatie.
Commitments: CommitmentDiscountType, CommitmentDiscountName, CommitmentDiscountStatus, en in 1.2 nieuw CommitmentDiscountUnit. Alle Reserved Instances, Savings Plans en CUDs vallen hieronder.
Tags: Tags is één JSON-kolom met key-value paren. Dit betekent dat je in queries JSON_VALUE(Tags, '$.environment') gebruikt in plaats van dedicated kolommen.

FOCUS exports activeren in AWS, Azure en GCP

Hieronder staan de commando's die ik zelf gebruik om een FOCUS export in te schakelen. Voor productie zou ik dit in Terraform vastleggen, maar de CLI-vorm is nuttig om snel te testen.

AWS: Data Exports met FOCUS 1.1

# Vereist: management/payer account, AWS CLI v2.15+
aws bcm-data-exports create-export \
  --region us-east-1 \
  --export '{
    "Name": "focus-1-1-daily",
    "DataQuery": {
      "QueryStatement": "SELECT * FROM FOCUS_1_0_AWS",
      "TableConfigurations": {
        "FOCUS_1_0_AWS": {
          "INCLUDE_MANUAL_DISCOUNT_COMPATIBILITY": "FALSE",
          "TIME_GRANULARITY": "DAILY"
        }
      }
    },
    "DestinationConfigurations": {
      "S3Destination": {
        "S3Bucket": "acme-finops-focus",
        "S3Prefix": "aws-focus/",
        "S3Region": "us-east-1",
        "S3OutputConfigurations": {
          "OutputType": "CUSTOM",
          "Format": "PARQUET",
          "Compression": "PARQUET",
          "Overwrite": "OVERWRITE_REPORT"
        }
      }
    },
    "RefreshCadence": { "Frequency": "SYNCHRONOUS" }
  }'

De export verschijnt binnen 24 uur in de bucket, gepartitioneerd op BillingPeriod=YYYY-MM. Let op: de tabelnaam is nog steeds FOCUS_1_0_AWS omdat AWS de view versioneert los van de FOCUS-versie die eronder ligt. Op het moment van schrijven levert dit een FOCUS 1.1-conforme dataset.

Azure: Cost Management FOCUS export

# Vereist: az CLI 2.60+, rol "Cost Management Contributor"
az costmanagement export create \
  --name "focus-1-2-daily" \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000" \
  --storage-account-id "/subscriptions/.../resourceGroups/finops-rg/providers/Microsoft.Storage/storageAccounts/acmefinops" \
  --storage-container "azure-focus" \
  --storage-directory "daily" \
  --definition-type "FocusCost" \
  --definition-timeframe "MonthToDate" \
  --schedule-status "Active" \
  --schedule-recurrence "Daily" \
  --recurrence-period from="2026-08-01T00:00:00Z" to="2030-01-01T00:00:00Z" \
  --format "Parquet"

Voor billing account-scope in plaats van subscription-scope gebruik je --scope "/providers/Microsoft.Billing/billingAccounts/{id}". Azure exporteert direct FOCUS 1.2 sinds de mei 2026 GA. Zie de officiële Microsoft Learn documentatie voor de volledige schemareferentie.

Google Cloud: BigQuery FOCUS export

# In de Cloud Console: Billing → Billing export → FOCUS export → Edit
# Of via gcloud (public preview van de CLI-flag):
gcloud billing accounts update 01ABCD-234567-89EFGH \
  --focus-export-bigquery-dataset=projects/acme-finops/datasets/billing \
  --focus-export-schema-version=1.1

# Vervolgens verifieer:
bq query --use_legacy_sql=false '
SELECT ProviderName, ServiceCategory, SUM(EffectiveCost) AS cost
FROM `acme-finops.billing.focus_billing_export`
WHERE ChargePeriodStart >= "2026-08-01"
  AND ChargeCategory = "Usage"
GROUP BY 1, 2
ORDER BY cost DESC
LIMIT 10;'

De view focus_billing_export wordt automatisch aangemaakt in de doeldataset. GCP schrijft nog steeds ook de "detailed_billing_export" tabel, die kun je laten staan voor legacy dashboards.

Multi-cloud kostenanalyse met SQL queries

Zodra alle drie de providers naar Parquet-bestanden exporteren met identieke kolomnamen, wordt cross-cloud analytics een kwestie van UNION ALL. Het onderstaande DuckDB-voorbeeld draait op mijn laptop tegen drie S3/Blob/GCS buckets en produceert een geconsolideerde kostenweergave per ServiceCategory.

-- DuckDB 1.3+, met de httpfs en aws extensies geladen
INSTALL httpfs; LOAD httpfs;
INSTALL aws;   LOAD aws;

CREATE OR REPLACE VIEW focus_multi_cloud AS
SELECT
  'AWS'   AS source_cloud,
  BillingAccountId, SubAccountId, ChargePeriodStart, ChargePeriodEnd,
  ServiceCategory, ServiceName, ChargeCategory, PricingCategory,
  BilledCost, EffectiveCost, ListCost, ContractedCost,
  Tags
FROM read_parquet('s3://acme-finops-focus/aws-focus/**/*.parquet', hive_partitioning=1)

UNION ALL

SELECT
  'Azure' AS source_cloud,
  BillingAccountId, SubAccountId, ChargePeriodStart, ChargePeriodEnd,
  ServiceCategory, ServiceName, ChargeCategory, PricingCategory,
  BilledCost, EffectiveCost, ListCost, ContractedCost,
  Tags
FROM read_parquet('azure://acme-finops.blob.core.windows.net/azure-focus/**/*.parquet')

UNION ALL

SELECT
  'GCP'   AS source_cloud,
  BillingAccountId, SubAccountId, ChargePeriodStart, ChargePeriodEnd,
  ServiceCategory, ServiceName, ChargeCategory, PricingCategory,
  BilledCost, EffectiveCost, ListCost, ContractedCost,
  Tags
FROM read_parquet('gs://acme-finops-focus/gcp-focus/**/*.parquet');

-- Top 10 services per cloud in augustus 2026, alleen echte verbruikkosten
SELECT source_cloud, ServiceCategory, ServiceName,
       ROUND(SUM(EffectiveCost), 2) AS effective_cost_usd
FROM focus_multi_cloud
WHERE ChargePeriodStart >= DATE '2026-08-01'
  AND ChargePeriodStart <  DATE '2026-09-01'
  AND ChargeCategory = 'Usage'
GROUP BY 1, 2, 3
ORDER BY effective_cost_usd DESC
LIMIT 10;

Bij Vantage heb ik dit type federated query zien lopen op datasets van 200GB Parquet met sub-secondaire response, doordat DuckDB filter en projectie naar het bestandsniveau pusht. Voor productie dashboards duw je dezelfde SQL in BigQuery of Snowflake; de query blijft syntactisch identiek omdat FOCUS kolomnamen niet veranderen.

Eerlijk? Voor teams die commitments over meerdere clouds moeten optimaliseren, scheelt dit gewoon enorm veel werk. Onze Reserved Instances vs Savings Plans vergelijking gebruikte tot vorig jaar per-provider CSV exports; nu draait dezelfde analyse op één FOCUS-datalake.

BilledCost vs EffectiveCost vs ContractedCost

Vier kostenkolommen leiden tot vier verschillende getallen die tot 40% kunnen verschillen voor exact dezelfde workload. Ik zie ze regelmatig door elkaar gebruikt in dashboards. Zo lees je ze:

ListCost: publieke on-demand prijs, alsof je geen enkele korting had. Nuttig voor "wat als"-analyses en om de waarde van commitments te laten zien aan finance.
ContractedCost: prijs die zou zijn betaald met je onderhandelde contractkortingen (EDP, MACC, CUDs), maar zonder gebruik-geïnduceerde kortingen zoals gebruik-tier discounts.
BilledCost: wat er op de factuur staat voor de ChargePeriod. Dit bevat upfront payments voor commitments in de maand waarin ze zijn aangeschaft, dus BilledCost is spikey rondom RI/SP purchases.
EffectiveCost: geamortiseerde kosten waarbij commitment-upfronts uitgesmeerd zijn over de looptijd. Dit is de kolom die je bijna altijd wilt voor trending en showback.

Praktische regel: gebruik EffectiveCost voor alles wat naar teams gaat (showback, budgets, forecasting) en BilledCost alleen voor kas- en factuurreconciliatie met finance. In een cost anomaly detection pipeline levert BilledCost anders false positives op, elke keer dat er een RI wordt gekocht. Zie onze gids voor cloud cost anomaly detection voor de details.

FOCUS-compatibele tools en ecosysteem

In 2026 hebben vrijwel alle serieuze FinOps-platforms native FOCUS ingest. De belangrijke spelers:

Vantage: FOCUS-first sinds oktober 2024. Kan je AWS Data Exports, Azure FOCUS export en GCP FOCUS export als bron gebruiken en levert een enkele geconsolideerde weergave.
CloudZero: ondersteunt FOCUS 1.1 als zowel input als output (voor customer chargebacks).
Finout: FOCUS 1.2 sinds juli 2026, met de mogelijkheid om Kubernetes-kosten uit OpenCost via FOCUS-annotated exports te importeren.
OpenCost / Kubecost: OpenCost 1.115 emit een FOCUS 1.1-conforme allocation stream, waardoor Kubernetes-toewijzingen naast raw cloud billing in dezelfde datalake landen. Ik draag hier zelf sporadisch aan bij.
Apache Superset en Grafana: beide hebben community-plugins die een FOCUS-tabel automatisch omzetten naar een default dashboard set.

Voor teams die zelf een lakehouse bouwen zijn de FOCUS Converters, een open-source Python-library van de FinOps Foundation, handig om oudere billing exports (CUR 1, Azure EA) om te zetten naar FOCUS-formaat zonder tot de eerstvolgende maandwissel te wachten.

Migratiestrategie: van native billing exports naar FOCUS

Als je nog draait op AWS CUR, Azure EA export en GCP gcp_billing_export_v1, dan is de migratie geen big-bang. De aanpak die ik teams bij drie klanten heb zien werken:

Sprint 1, enable en observeer: schakel FOCUS exports parallel aan bestaande exports. Doe niets met de data behalve monitoren dat er dagelijkse rijen binnenkomen.
Sprint 2, reconciliation: schrijf één reconciliation-query per provider die SUM(EffectiveCost) uit FOCUS vergelijkt met de equivalente kolom uit de legacy export. Verschillen > 0.5% zijn een teken van foute join op tag/scope; zoek dit uit voordat je verdergaat.
Sprint 3, dashboard cutover: point je interne showback dashboards naar de FOCUS-tabel. Anomaly detection, budgets en team-attribution horen hier bij.
Sprint 4, decommission: eindig de legacy exports (of laat ze in Glacier/Archive staan voor 12 maanden compliance). De lifecycle-regels voor de oude bucket zijn een goede aanleiding om je algemene S3 storage optimalisatiestrategie te reviewen.

Bij één klant hebben we tussen sprint 2 en 3 een discrepantie van 3.1% ontdekt op AWS-kant. Bleek uitgelegd te worden door de manual discount compatibility-flag die ik in het CLI-voorbeeld hierboven op FALSE heb gezet: met TRUE lopen twee soorten kortingen dubbel mee en klopt de EffectiveCost niet meer met wat Cost Explorer laat zien. Dat is precies waarom die reconciliation-sprint bestaat.

Veelgestelde vragen

Wat is het verschil tussen FOCUS en AWS CUR?

CUR is AWS-specifiek en heeft ongeveer 150 kolommen met per-service afwijkende betekenissen. FOCUS is een provider-neutrale specificatie met ongeveer 50 kolommen die dezelfde semantiek hebben over AWS, Azure, GCP en anderen. AWS levert een FOCUS-view bovenop CUR, dus je kunt beide naast elkaar draaien.

Kost een FOCUS export extra?

De export zelf is bij AWS, Azure en GCP gratis. Je betaalt alleen voor de opslag van de resulterende Parquet-bestanden (typisch minder dan €5 per maand voor een middelgroot bedrijf) en voor eventuele query-kosten in BigQuery of Athena.

Ondersteunt FOCUS Kubernetes-kosten?

FOCUS 1.1 introduceerde de CapacityReservationId-kolom die node-pool toewijzing mogelijk maakt, maar echte pod-level allocation komt uit OpenCost of Kubecost, die vervolgens FOCUS-conforme output produceren die je in dezelfde datalake kunt joinen.

Hoe vaak wordt FOCUS bijgewerkt?

De FinOps Foundation streeft naar één minor release per jaar (1.1 in 2025, 1.2 in 2026). Minor versies zijn achterwaarts compatibel: kolommen worden toegevoegd, nooit verwijderd of van semantiek veranderd binnen een major versie.

Moet ik meteen naar FOCUS migreren?

Als je multi-cloud draait: ja, de ROI is binnen één kwartaal terugverdiend door verminderde ETL-onderhoud. Ben je single-cloud AWS-only en tevreden met CUR-gebaseerde tooling, dan is FOCUS optioneel. Activeer 'm dan wel parallel, zodat je later niet aan een backfill vastzit.