Specificația FOCUS 1.2: Ghid Practic pentru Standardizarea Costurilor Multi-Cloud în FinOps (2026)

Actualizat: 5 iulie 2026

Specificația FOCUS (FinOps Open Cost and Usage Specification) este un standard deschis, întreținut de FinOps Foundation, care normalizează exporturile de facturare de la AWS, Azure, Google Cloud, Oracle Cloud și SaaS în aceeași schemă tabelară, cu coloane fixe precum BilledCost, EffectiveCost, ListCost, ChargeCategory și SkuId. În 2026, cu FOCUS 1.2 GA și exporturi native din CUR 2.0, Azure Cost Management și BigQuery Billing, poți construi un data lake multi-cloud fără să mai scrii adaptoare custom pentru fiecare furnizor. Honestly, asta e schimbarea cea mai mare pe care am văzut-o în FinOps în ultimii cinci ani. Am migrat trei clienți enterprise pe FOCUS în ultimul an și am tăiat săptămâni de muncă de ETL.

• FOCUS 1.2 (mai 2026) adaugă coloane pentru CapacityReservationId, CommitmentDiscountStatus și clarifică semantica PricingCategory pentru rezervări parțial acoperite.
• AWS oferă export FOCUS 1.0 nativ prin Data Exports (CUR 2.0), Azure prin Cost Management Exports, iar GCP prin BigQuery Billing FOCUS view, toate cu partiționare Parquet și livrare orară.
• Diferența dintre BilledCost (ce plătești pe factură) și EffectiveCost (costul amortizat cu rezervări) e critică pentru showback corect. Folosește EffectiveCost pentru unit economics.
• Unelte ca Vantage, CloudZero, Kubecost și Cloudability au conectoare FOCUS-native, ceea ce elimină nevoia de mapare custom între CUR, Azure EA și BigQuery billing.
• Cu FOCUS plus Athena sau BigQuery poți răspunde la întrebări multi-cloud (cost per echipă, cost per client, acoperire commitment) cu o singură interogare SQL, nu trei.
• Adopția FOCUS este o cerință pre-condițională pentru certificarea FinOps Foundation Practitioner v2 și pentru integrarea cu OpenCost 2.0.

Ce este specificația FOCUS și de ce contează în 2026

FOCUS este o schemă tabelară standardizată (literalmente o listă de coloane cu nume, tipuri și semantică fixate) pe care furnizorii de cloud și SaaS o emit împreună cu datele lor de facturare. Înainte de FOCUS, dacă voiai să răspunzi la o întrebare simplă precum „cât m-a costat echipa Platform luna trecută, pe toate cloudurile", trebuia să scrii trei pipeline-uri ETL diferite. Unul care înțelege lineItem/UnblendedCost din AWS CUR, unul care înțelege Cost și EffectivePrice din Azure EA, și unul care înțelege cost plus credits din BigQuery billing export. Fiecare cu propriile capcane. CUR expune rezervările pe două rânduri (RIFee și amortization), Azure amestecă costurile purchase cu usage, iar GCP publică creditele ca valori negative separate.

FOCUS colapsează toate acestea într-un singur model. Fiecare furnizor conform FOCUS emite aceleași ~50 de coloane, cu aceeași unitate de măsură și aceeași convenție de semne. În specificația oficială FOCUS 1.2, coloanele sunt împărțite în identificatori de facturare (BillingAccountId, SubAccountId), atribute de resursă (ResourceId, ServiceName, ProviderName), atribute de cost (BilledCost, EffectiveCost, ListCost, ContractedCost) și atribute de commitment (CommitmentDiscountType, CommitmentDiscountCategory). În 2026, ecosistemul de tooling FinOps s-a mutat masiv pe FOCUS: OpenCost 2.0, Kubecost, Vantage, CloudZero, Cloudability, ProsperOps și Finout consumă toate FOCUS nativ.

Noutățile din FOCUS 1.2 față de 1.0 și 1.1

FOCUS 1.0 a devenit GA în iunie 2024, 1.1 a adăugat în noiembrie 2024 suport pentru SaaS și clarificări pentru credite, iar FOCUS 1.2 (mai 2026) aduce trei schimbări pe care le simți imediat în interogări. Prima: coloana CapacityReservationId permite atribuirea costurilor Capacity Reservations (AWS ODCR, Azure Capacity Reservations, GCP Reservations) în același mod ca Savings Plans. Până acum, acestea apăreau ca linii separate greu de reconciliat. A doua: CommitmentDiscountStatus distinge explicit între „Used", „Unused" (deșeu de commitment) și „Expired", ceea ce face raportarea de acoperire trivială. A treia: PricingCategory are acum valoarea „Committed" separată de „Standard" pentru cazurile în care instanța e acoperită parțial de Savings Plan și parțial la on-demand.

Pentru echipe care rulează deja FOCUS 1.0, migrarea la 1.2 e non-breaking, coloanele noi fiind aditive. Dar rescrie interogările tale de acoperire commitment: în 1.0, calculai coverage cu un JOIN pe CommitmentDiscountId IS NOT NULL. În 1.2, întrebi direct WHERE CommitmentDiscountStatus = 'Used'. E mai rapid și mai clar. Am rescris un dashboard Vantage la un client care avea 40 de query-uri de coverage și l-am colapsat în 8.

Coloanele cheie FOCUS explicate cu exemple

Nu toate cele ~50 de coloane FOCUS sunt egal de utile. În experiența mea, 12-15 acoperă 95% din întrebările reale. Iată setul minim pe care îl folosesc în orice model semantic FinOps:

Coloană	Tip	La ce răspunde
BilledCost	decimal	Cât a fost pe factura reală, inclusiv taxe de rezervare upfront
EffectiveCost	decimal	Cost amortizat pe perioada rezervării, bun pentru showback
ListCost	decimal	Prețul on-demand fără discount, util pentru „savings vs list"
ContractedCost	decimal	Prețul negociat prin EDP/MCA înainte de commitment discounts
ServiceName	string	Nume standardizat („Amazon EC2", „Azure Virtual Machines")
ServiceCategory	string	Grupare la nivel înalt („Compute", „Storage", „AI and Machine Learning")
ChargeCategory	string	Usage, Purchase, Tax, Credit, Adjustment
PricingCategory	string	Standard, Spot, Committed, Dynamic
CommitmentDiscountId	string	ID-ul Savings Plan / RI / CUD care aplică discount
SkuId / SkuPriceId	string	Identificatorul SKU pentru maparea la catalogul de prețuri
ResourceId	string	ARN / Resource ID pentru attribution la nivel de resursă
Tags	map	Tag-uri normalizate (Azure „tags", AWS „resourceTags", GCP „labels")

Coloana Tags merită atenție specială. În CUR clasic, tag-urile veneau ca sute de coloane individuale, una per cheie de tag. În FOCUS, e o singură coloană map<string,string>, ceea ce simplifică enorm schema în Parquet și permite Athena/BigQuery să facă unnest fără DDL nou de fiecare dată când adaugi un tag. Dacă folosești deja o strategie serioasă de tagging, vezi ghidul nostru pe alocarea costurilor cloud prin etichetare cu Terraform pentru a te asigura că cheile tale sunt consistente între clouduri.

Cum activezi exportul FOCUS din AWS Data Exports

În AWS, FOCUS 1.0 (și în curând 1.2, când AWS îl adoptă complet) este disponibil ca export prin serviciul Data Exports din Billing and Cost Management console. Nu mai activezi CUR clasic; creezi un „Data Export" cu tabelul FOCUS_1_0_AWS. Iată configurația practică pe care o folosesc pentru toți clienții:

# Terraform: activare FOCUS 1.0 export via aws_bcmdataexports_export
resource "aws_bcmdataexports_export" "focus" {
  export {
    name = "focus-multi-account-2026"

    data_query {
      query_statement = "SELECT * FROM FOCUS_1_0_AWS"
      table_configurations = {
        FOCUS_1_0_AWS = {
          INCLUDE_MANUAL_DISCOUNT_COMPATIBILITY = "FALSE"
        }
      }
    }

    destination_configurations {
      s3_destination {
        s3_bucket = aws_s3_bucket.finops.id
        s3_prefix = "focus/"
        s3_region = "eu-central-1"

        s3_output_configurations {
          overwrite   = "OVERWRITE_REPORT"
          format      = "PARQUET"
          compression = "PARQUET"
          output_type = "CUSTOM"
        }
      }
    }

    refresh_cadence {
      frequency = "SYNCHRONOUS"  # actualizare la fiecare 15 min pe ziua curenta
    }
  }
}

După activare, primești fișiere Parquet partiționate zilnic în S3. Le poți interoga direct cu Athena sau le poți crawla cu Glue. AWS-ul emite acum și o coloană x_CostCategories (prefixul x_ înseamnă extensie proprietară în FOCUS) care conține Cost Categories definite în console, util dacă ai deja o taxonomie construită acolo. Pentru documentația oficială vezi FOCUS 1.0 table dictionary în AWS docs.

Cum configurezi exportul FOCUS din Azure Cost Management

Azure a lansat FOCUS export ca GA în octombrie 2024 pentru MCA (Microsoft Customer Agreement) și EA. Configurarea e mai puțin drag-and-drop decât în AWS, dar recomand să o faci prin Bicep pentru repetabilitate:

// Bicep: export FOCUS din Azure Cost Management la Storage Account
resource focusExport 'Microsoft.CostManagement/exports@2025-03-01' = {
  name: 'focus-export-2026'
  scope: '/providers/Microsoft.Billing/billingAccounts/${billingAccountId}'
  properties: {
    format: 'Parquet'
    partitionData: true
    dataOverwriteBehavior: 'OverwritePreviousReport'
    schedule: {
      status: 'Active'
      recurrence: 'Daily'
      recurrencePeriod: {
        from: '2026-07-01T00:00:00Z'
        to: '2030-12-31T00:00:00Z'
      }
    }
    definition: {
      type: 'FocusCost'         // cheia: FocusCost, nu ActualCost sau AmortizedCost
      timeframe: 'MonthToDate'
      dataSet: {
        granularity: 'Daily'
        configuration: {
          dataVersion: '1.0'    // 1.2 va fi disponibil dupa Q3 2026
        }
      }
    }
    deliveryInfo: {
      destination: {
        resourceId: storageAccount.id
        container: 'focus'
        rootFolderPath: 'exports'
      }
    }
  }
}

Un lucru care mi-a luat câteva iterații: câmpul dataVersion controlează versiunea FOCUS emisă. Dacă nu îl setezi, Azure îți dă cea mai veche versiune suportată, ceea ce poate fi 1.0-preview la unele tenanturi vechi. Setează-l explicit la 1.0 sau 1.1 ca să eviți surprize la deploy. De asemenea, Azure emite un fișier per zi pe MonthToDate, deci trebuie să deduplici pe ChargePeriodStart dacă rulezi ingerarea de mai multe ori pe zi.

Cum obții datele FOCUS din GCP BigQuery Billing

GCP e cel mai elegant din cei trei. Nu ai nevoie de export separat: activezi FOCUS ca view peste BigQuery Billing Export standard. Dacă ai deja billing export activat pentru facturare detaliată în BigQuery, poți crea imediat un view FOCUS 1.0:

-- BigQuery: creare view FOCUS peste billing export standard
-- Documentat de Google in Cloud Billing FOCUS docs
CREATE OR REPLACE VIEW `finops.focus_1_0` AS
SELECT
  billing_account_id           AS BillingAccountId,
  project.id                   AS SubAccountId,
  service.description          AS ServiceName,
  sku.description              AS SkuId,
  CASE
    WHEN service.description LIKE 'Compute%' THEN 'Compute'
    WHEN service.description LIKE 'BigQuery%' THEN 'Analytics'
    WHEN service.description LIKE 'Cloud Storage%' THEN 'Storage'
    ELSE 'Other'
  END                          AS ServiceCategory,
  usage_start_time             AS ChargePeriodStart,
  usage_end_time               AS ChargePeriodEnd,
  cost                         AS BilledCost,
  cost + IFNULL((SELECT SUM(amount) FROM UNNEST(credits)),0) AS EffectiveCost,
  cost_at_list                 AS ListCost,
  CASE
    WHEN EXISTS(SELECT 1 FROM UNNEST(credits) c WHERE c.type = 'COMMITTED_USAGE_DISCOUNT')
      THEN 'Committed' ELSE 'Standard'
  END                          AS PricingCategory,
  labels                       AS Tags,
  currency                     AS BillingCurrency
FROM `PROJECT.DATASET.gcp_billing_export_resource_v1_XXXXXX`;

Google publică deja un template oficial de view FOCUS în Cloud Billing FOCUS schema docs. Folosește-l în producție în loc să-l scrii de la zero. Pentru costurile de transfer date care apar pe FOCUS ca ChargeCategory = 'Usage' cu ServiceName = 'Cloud Storage' sau 'VPC Egress', vezi ghidul nostru dedicat pe reducerea costurilor de transfer date cloud.

Interogări SQL practice peste datele FOCUS unificate

Puterea reală vine când unifici cele trei surse într-o singură tabelă (sau UNION ALL view) și rulezi întrebări multi-cloud. Iată trei query-uri pe care le pornesc întotdeauna pentru un client nou:

-- Q1: Cost efectiv per echipa, ultimele 30 zile, cross-cloud
SELECT
  Tags['team']         AS team,
  ProviderName,
  ROUND(SUM(EffectiveCost), 2) AS effective_cost_usd
FROM focus_unified
WHERE ChargePeriodStart >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  AND ChargeCategory = 'Usage'
GROUP BY team, ProviderName
ORDER BY effective_cost_usd DESC;

-- Q2: Acoperire commitment (procent din compute pe Committed vs Standard)
SELECT
  ProviderName,
  ServiceCategory,
  ROUND(100.0 * SUM(CASE WHEN PricingCategory='Committed' THEN EffectiveCost END)
              / NULLIF(SUM(EffectiveCost),0), 1) AS pct_committed
FROM focus_unified
WHERE ServiceCategory = 'Compute'
  AND ChargePeriodStart >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY ProviderName, ServiceCategory;

-- Q3: Waste de commitment (Savings Plans/RI/CUD nefolosite)
SELECT
  CommitmentDiscountId,
  ProviderName,
  ROUND(SUM(BilledCost - EffectiveCost), 2) AS unused_commitment_usd
FROM focus_unified
WHERE CommitmentDiscountStatus = 'Unused'
  AND ChargePeriodStart >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
GROUP BY CommitmentDiscountId, ProviderName
HAVING unused_commitment_usd > 100
ORDER BY unused_commitment_usd DESC;

Query 3 e cel care mi-a salvat cel mai mulți bani în ultimele 12 luni. Detectează Savings Plans pe care le-ai cumpărat dar nu le acoperi cu usage, semnal clar că fie ai over-committed, fie au dispărut workloads. Pentru context strategic pe cumpărarea corectă vezi ghidul practic de commitment multi-cloud pe Reserved Instances și Savings Plans.

BilledCost vs EffectiveCost vs ListCost: când folosești fiecare

Cele mai frecvente erori pe care le văd în implementări FOCUS vin din alegerea greșită între aceste trei coloane. Regulile pe care le predau echipelor mele:

BilledCost reflectă exact ce plătești pe factură într-o lună. Dacă ai cumpărat un Savings Plan de 1 an upfront pentru 12.000 $, BilledCost va arăta 12.000 $ în luna cumpărării și 0 $ pentru consumul acoperit în lunile ulterioare. Asta e corect pentru cash accounting, dar nu e corect pentru chargeback. Echipa care beneficiază în lunile 2-12 nu vede niciun cost, ceea ce distorsionează unit economics.

EffectiveCost amortizează costul commitment-ului pe toată durata lui. În exemplul de mai sus, ai vedea 1.000 $ pe lună timp de 12 luni. Asta permite alocare corectă la echipe și produse. E și baza pe care o folosesc consumatorii FOCUS ca Vantage și CloudZero pentru unit economics (cost per client, cost per tranzacție).

ListCost e prețul on-demand public, fără nicio reducere. E util pentru două lucruri: (1) calculul „efectiv discount procentual" negociat prin EDP/MCA și (2) benchmarking-ul deciziei de commitment. Dacă EffectiveCost / ListCost este ~0.55, ai realizat 45% discount, ceea ce e în linie cu un Savings Plan 3-year all-upfront pentru compute.

Ce unelte FinOps consumă FOCUS nativ

Ecosistemul de tooling a fost cel mai rapid catalizator al adopției FOCUS. Iată ce funcționează în 2026 fără mapare custom:

• Vantage: conectori FOCUS-native pentru AWS, Azure, GCP; adaugă și Snowflake, MongoDB Atlas.
• CloudZero: bazat pe FOCUS pentru unit economics; are propriile extensii x_ pentru Kubernetes cost allocation.
• Kubecost / OpenCost 2.0: emite FOCUS 1.1 pentru costurile K8s, ceea ce înseamnă că poți face UNION cu FOCUS de cloud provider pentru o vedere completă.
• Cloudability (IBM): a rescris pipeline-ul intern pe FOCUS în 2025; disponibil ca sursă opțională de date.
• ProsperOps: folosește FOCUS pentru optimizarea automată de commitment portfolio.
• Finout: cost data warehouse construit direct peste FOCUS și tag-uri custom.

Dacă construiești in-house, dbt are pachete comunitare (dbt-focus) care oferă modele semantice standard peste FOCUS. Le-am folosit la un client cu 50+ conturi AWS ca să scot un dashboard Superset în 3 zile. Chiar merită efortul.

Migrarea de la CUR clasic la FOCUS: pași concreți

Nu e o migrare de tip „big bang". Recomand următoarea secvență, testată pe 3 clienți enterprise:

1. Activează exportul FOCUS în paralel cu CUR-ul existent. Rulează ambele timp de o lună.
2. Construiește o reconciliere zilnică: SELECT SUM(BilledCost) FROM focus vs SUM(line_item_unblended_cost + amortization) FROM cur. Diferența trebuie să fie sub 0.5%.
3. Portează pipeline-urile analitice pe FOCUS unul câte unul. Începe cu chargeback-ul, unde EffectiveCost îți simplifică viața enorm.
4. Migrează dashboards Quicksight/Grafana/Superset. Aproape toate au conectori S3+Parquet care merg direct pe FOCUS.
5. Dezactivează CUR-ul clasic după 2-3 luni de paritate. Menține o copie arhivată în Glacier pentru audit istoric.

Capcane frecvente și cum le eviți

Din trei implementări reale, iată erorile pe care le repetă lumea:

• Confuzie între ChargePeriodStart și BillingPeriodStart. Primul e când s-a consumat resursa, al doilea e ciclul de facturare. Pentru dashboards zilnice, folosește ChargePeriodStart.
• Ignorarea PricingCategory = 'Spot'. Instance Spot apar cu PricingCategory='Spot' și cu EffectiveCost deja discount-at. Dacă filtrezi doar 'Standard', pierzi ~30% din compute la clienți care rulează batch pe Spot. Vezi și ghidul de Spot Instances multi-cloud.
• Duplicarea rândurilor MonthToDate din Azure. Azure re-emite lunar exportul complet la fiecare rulare, nu incremental. Trebuie să deduplici pe (ChargePeriodStart, ResourceId, SkuId).
• Ignorarea coloanei ChargeClass. În FOCUS 1.1+, ChargeClass='Correction' marchează credite retroactive și ajustări. Dacă le omiți, rapoartele de forecast vor fi off.
• Presupunerea că toate SaaS-urile suportă FOCUS. Momentan doar Snowflake, MongoDB Atlas, Databricks și Datadog au anunțat public export FOCUS pentru 2026. Restul necesită continuare cu adaptoare custom.

Întrebări frecvente

Ce înseamnă FOCUS în FinOps?

FOCUS înseamnă FinOps Open Cost and Usage Specification, un standard deschis întreținut de FinOps Foundation care definește o schemă unificată de coloane pentru datele de cost și utilizare de la orice furnizor cloud sau SaaS. Scopul e ca AWS, Azure, GCP și SaaS-urile să emită aceleași câmpuri, ceea ce elimină nevoia de mapare custom în FinOps tooling.

Care e diferența între BilledCost și EffectiveCost?

BilledCost reflectă exact ce plătești pe factura reală într-o lună (cash accounting), inclusiv taxe upfront pentru rezervări. EffectiveCost amortizează costurile de commitment pe durata rezervării, oferind o vedere corectă pentru showback și unit economics. Pentru chargeback intern folosește EffectiveCost; pentru reconcilierea cu contabilitatea folosește BilledCost.

Suportă AWS, Azure și GCP exportul nativ FOCUS?

Da. AWS suportă FOCUS 1.0 prin Data Exports (CUR 2.0), Azure prin Cost Management Exports cu type=FocusCost, iar GCP prin BigQuery Billing views documentate în docs oficiale. FOCUS 1.2 este disponibil ca preview la unele conturi în Q3 2026; adopția completă e prevăzută pentru toți cei trei până la finalul anului.

FOCUS înlocuiește complet AWS CUR?

Nu neapărat. FOCUS oferă un subset standardizat și normalizat. CUR clasic (via Data Exports 2.0) rămâne util când ai nevoie de coloane AWS-specifice precum reservation/AmortizedUpfrontCostForUsage sau tag-uri raw pe coloane individuale. În practică, mulți clienți enterprise rulează ambele în paralel: FOCUS pentru dashboards multi-cloud și CUR pentru investigații AWS-specifice.

Cum se corelează FOCUS cu OpenCost pentru Kubernetes?

OpenCost 2.0 emite datele Kubernetes cost allocation în format FOCUS 1.1, ceea ce înseamnă că poți face un UNION între FOCUS-ul de la cloud provider (costul EC2/AKS/GKE nodes) și FOCUS-ul de la OpenCost (alocarea pe namespace/deployment/pod) în același data warehouse. E cea mai curată metodă în 2026 pentru unit economics pe workloads containerizate.

Cât durează implementarea FOCUS end-to-end?

La un client cu 3 clouduri și ~200 de conturi/subscriptions, am ajuns la primul dashboard multi-cloud în 2 săptămâni: 3 zile pentru configurarea exporturilor (Terraform/Bicep), 4 zile pentru pipeline-ul de ingestie și UNION view, restul pentru validarea reconcilierii cu facturile. Migrarea completă (portarea tuturor rapoartelor existente) a durat ~2 luni.