FOCUS 1.2 спецификация: Стандартизиране на billing данни от AWS, Azure и GCP (2026)
FOCUS 1.2 нормализира billing данните от AWS, Azure и GCP в единна схема. Научете как да активирате export-а за всеки доставчик, да обедините данните в data lake и кои капани да избегнете при showback.
FOCUS (FinOps Open Cost & Usage Specification) е отворен стандарт, който нормализира billing данните от AWS, Azure, GCP, Oracle Cloud и SaaS доставчиците в единна схема с предвидими имена на колони и единици. С версия 1.2 на спецификацията, излязла в началото на 2026 г., можете да обедините Cost and Usage Reports (CUR 2.0), Azure Cost Management exports и GCP BigQuery billing export в един и същ модел. Така спирате да поддържате три различни ETL пайплайна за едни и същи отчети по екипи, среди и продукти.
FOCUS 1.2 (издадена март 2026 г.) дефинира 50+ задължителни колони (BilledCost, EffectiveCost, ListCost, ContractedCost, ChargeCategory и още), които работят идентично между AWS, Azure и GCP.
AWS публикува FOCUS export директно от Data Exports (наследникът на CUR 2.0); Azure го предлага като Exports във формат Parquet; GCP го изнася в BigQuery като отделна таблица до съществуващия billing export.
BilledCost и EffectiveCost не са едно и също. BilledCost е каквото излиза на фактурата за периода, а EffectiveCost разпределя предплатени RI/Savings Plan суми пропорционално на usage-а.
FOCUS не замества напълно native билинг данните. Service-specific полета (като InstanceType, OperationName) остават в provider-specific колони с префикс x_.
Най-голямата печалба: showback и chargeback модели в multi-account/multi-cloud setup стават спрямо една и съща схема, така че Power BI или Looker дашборд работи за всички доставчици.
Препоръчителният паттерн за 2026 г.: отделен S3 bucket, Storage Account и GCS bucket за FOCUS exports от всеки доставчик, обединяване в data lake (Athena, Synapse, BigQuery) и query слой върху FOCUS колоните.
Какво е FOCUS в FinOps?
FOCUS (FinOps Open Cost and Usage Specification) е отворена техническа спецификация, поддържана от FinOps Foundation към Linux Foundation, която определя точно как доставчикът на облак трябва да структурира файла с разходи и употреба. Преди FOCUS, всеки доставчик имаше собствена схема. AWS използваше lineItem/UsageType/UnblendedCost. Azure използваше MeterCategory и EffectiveCost. GCP пък разчиташе на sku.description с invoice.month. Резултатът? Отделни ETL пайплайни за всеки billing източник и почти нулева възможност да направите централизиран отчет „колко плати екипът Payments в Q1 across all clouds“ без скъпа абстракция отгоре.
Така че FOCUS решава точно това. Спецификацията дефинира няколко десетки задължителни колони с конкретни типове (Decimal, String, EnumString, Datetime), единици (винаги UTC, ISO 4217 валути) и семантика (BilledCost винаги е след отстъпки, ListCost винаги е публичната цена). В моята практика по multi-account AWS Organizations и hub-and-spoke Azure landing zones, единственото истинско предимство, което движи приемането, е, че може да напишете една SQL заявка веднъж и тя да върне валиден отговор за all clouds, а не „главно AWS с малко Azure“.
Какво ново има във FOCUS 1.2 (2026)?
FOCUS 1.0 излезе през юни 2024 г., FOCUS 1.1 дойде септември 2024 г., а FOCUS 1.2 беше ратифициран в март 2026 г. Версия 1.2 не въвежда breaking changes над 1.1, но добавя три неща, които пряко влияят върху ежедневните FinOps процеси:
CapacityReservationId и CapacityReservationStatus: изрични колони, така че да можете да разграничите Unused Reservation (резерв без съответен usage) от Used Reservation, без да dependvate от provider-specific полета.
SkuPriceDetails: структуриран JSON със ставките (rate, tier, currency), използвани за изчисление на ChargedCost. Това е огромно подобрение за audit. Преди трябваше да съпоставяте lineItem-и срещу price list API ръчно.
ServiceSubcategory: допълва ServiceCategory с по-фина класификация (например ServiceCategory=Compute, ServiceSubcategory=Serverless Containers за ECS Fargate, Cloud Run и Container Apps).
AWS, Azure и GCP вече подкрепят FOCUS 1.1 в production. AWS обяви публична поддръжка на FOCUS 1.2 за втората половина на 2026 г., Azure и GCP се очакват по подобен график. Затова, ако стартирате нов pipeline днес, започнете с FOCUS 1.1 като базова версия и плануайте надграждане.
Задължителните колони, които трябва да познавате
Спецификацията дефинира над 50 колони, но в реална работа върху тагване на ресурси за cost allocation и месечни close процеси, използвате около 15. Ето таблица с най-важните:
FOCUS колона
Тип
Какво съдържа
BilledCost
Decimal
Сумата, която реално излиза на фактурата за периода (след отстъпки, преди credits)
EffectiveCost
Decimal
BilledCost плюс amortizirana част от предплатени commitments (RI, Savings Plans)
ListCost
Decimal
Цената без никакви отстъпки (publish rate × quantity)
ContractedCost
Decimal
Цената по EDP/MCA контракт с custom отстъпки
ChargeCategory
EnumString
Usage, Purchase, Tax, Credit, Adjustment
ChargeClass
EnumString
Correction (за rebill записи) или празно
ServiceName
String
Името на услугата (Amazon EC2, Azure Storage, Compute Engine)
ServiceCategory
EnumString
Compute, Storage, Networking, Databases, AI and Machine Learning и т.н.
SubAccountId / SubAccountName
String
AWS account, Azure subscription, GCP project
BillingPeriodStart / BillingPeriodEnd
Datetime
Периодът на фактурата в UTC
ChargePeriodStart / ChargePeriodEnd
Datetime
Периодът, в който е настъпил конкретният usage
Tags
JSON
Resource или cost allocation тагове като ключ-стойност обект
Освен задължителните, всеки доставчик може да добави provider-specific колони с префикс x_: x_aws_line_item_type, x_azure_meter_category, x_gcp_credit_type. Моята препоръка: не строете основни отчети върху x_ колони, защото губите портабилността на заявката.
BilledCost срещу EffectiveCost: разликата на практика
Това е въпросът, който ми задават най-често от финансовите екипи, защото броят излизащ от FOCUS често не съвпада с числото във фактурата, ако се гледа само в EffectiveCost. Накратко:
BilledCost: каквото accounts payable плаща на доставчика. Ако сте купили 1-year All Upfront Savings Plan за $12,000 през януари, BilledCost за януари ще има $12,000 за тази покупка плюс usage за месеца. А за февруари до декември BilledCost от Savings Plan-а ще е $0.
EffectiveCost: amortizirana версия. Същият Savings Plan ще покаже $1,000 в EffectiveCost за всеки от 12-те месеца, независимо кога е платен. Това е числото, което искате за месечен showback по екипи, защото предотвратява изкривяването „екипът, който е startнал инстанцията през януари, носи целия cost“.
На практика, използвайте BilledCost за reconciliation с фактурата, а EffectiveCost за вътрешен chargeback и unit economics. И двете идват от една и съща таблица, така че switch-ът е просто SELECT clause. За дълбочина по теми като Savings Plans срещу Reserved Instances, FOCUS прави сравнението по-чисто, защото и двата инструмента се отчитат с едни и същи имена на колони.
Как да активирате FOCUS export в AWS
AWS публикува FOCUS 1.0 export като опция в AWS Data Exports (наследникът на legacy Cost and Usage Reports). Стъпките:
Влезте в management account на AWS Organizations (не от member account, понеже FOCUS се генерира за цялата организация).
Отидете в Billing and Cost Management → Data Exports → Create export.
Изберете Standard data export → FOCUS 1.0 (preview).
Дайте име, изберете S3 bucket (политиката на bucket-а трябва да позволява billingreports.amazonaws.com).
Изберете compression: Parquet с Snappy за query performance в Athena.
Изчакайте до 24 часа за първия export. След това update-ите идват няколко пъти на ден.
Пример Athena CREATE TABLE statement за партиционирана FOCUS таблица:
Azure поддържа FOCUS 1.0 чрез Cost Management → Exports в Enterprise Agreement (EA) и Microsoft Customer Agreement (MCA) акаунти. От март 2026 г. FOCUS 1.1 е default опцията за нови exports. Документацията е на learn.microsoft.com и е доста подробна.
Scope: Billing Account за multi-subscription view, или конкретен Management Group.
Тип на export: FOCUS cost.
Frequency: Daily export of month-to-date costs. Format: Parquet.
Destination: Storage Account в същия tenant. Задайте Managed Identity на storage account-а за достъп.
След активиране, файловете идват като {billing_period}/{export_name}/{run_id}/part-*.parquet. За Synapse Serverless SQL pool, създайте external table върху Parquet файловете и заявявайте директно без import.
Как да активирате FOCUS export в GCP
GCP предлага FOCUS export от май 2025 г. като отделна BigQuery destination до съществуващия Cloud Billing export. Конфигурация:
В Cloud Console отидете на Billing → Billing export.
Активирайте секцията FOCUS export и изберете BigQuery dataset (препоръката ми е отделен dataset, не съществуващият billing_export).
Дайте на service account service-{billing_account}@gcp-sa-cloud-billing.iam.gserviceaccount.com ролята BigQuery Data Editor върху dataset-а.
Първият export пристига в рамките на 24 часа. Ежедневни актуализации след това.
Таблицата се казва focus_v1_billing_export и съдържа точните FOCUS колони plus x_gcp_* разширения. Пример заявка за топ 10 услуги по EffectiveCost този месец:
SELECT
ServiceName,
SUM(EffectiveCost) AS total_effective_cost
FROM `my-billing-project.focus_dataset.focus_v1_billing_export`
WHERE BillingPeriodStart = TIMESTAMP('2026-06-01')
AND ChargeCategory = 'Usage'
GROUP BY ServiceName
ORDER BY total_effective_cost DESC
LIMIT 10;
Обединена SQL заявка през трите доставчика
Тук е истинската стойност на FOCUS. Една и съща заявка работи срещу всички таблици. Предполагайки, че сте обединили AWS, Azure и GCP FOCUS exports в Snowflake (или Databricks Unity Catalog), ето как изглежда month-to-date спендване по екип, който ползва тага cost_center на всички три облака:
WITH unified AS (
SELECT 'aws' AS provider, ServiceCategory, EffectiveCost,
JSON_EXTRACT_PATH_TEXT(Tags, 'cost_center') AS cost_center,
ChargePeriodStart
FROM focus.aws_export
UNION ALL
SELECT 'azure', ServiceCategory, EffectiveCost,
JSON_EXTRACT_PATH_TEXT(Tags, 'cost_center'),
ChargePeriodStart
FROM focus.azure_export
UNION ALL
SELECT 'gcp', ServiceCategory, EffectiveCost,
JSON_EXTRACT_PATH_TEXT(Tags, 'cost_center'),
ChargePeriodStart
FROM focus.gcp_export
)
SELECT
cost_center,
provider,
ServiceCategory,
SUM(EffectiveCost) AS mtd_cost
FROM unified
WHERE ChargePeriodStart >= DATE_TRUNC('month', CURRENT_DATE)
AND cost_center IS NOT NULL
GROUP BY cost_center, provider, ServiceCategory
ORDER BY mtd_cost DESC;
Преди FOCUS, същата заявка изискваше три различни CTE с провайдер-специфични имена на колони (UnblendedCost vs EffectiveCost vs cost), три различни начина да парснете тагове и custom logic за всеки ServiceCategory mapping. Спестените дни инженерска работа са истинският ROI на FOCUS.
Showback и chargeback върху FOCUS
FOCUS-базиран showback е по-чист по три причини:
EffectiveCost е по дефиниция amortizirano. Не е нужно да пишете custom logic, която разпределя Savings Plan amortization по екип.
Tags колоната е стандартизирана като JSON. Един и същ JSON_EXTRACT работи срещу AWS, Azure и GCP. Преди трябваше да парсвате resource_tags_user_cost_center в AWS CUR, отделна Tags колона в Azure, и labels в GCP.
SubAccountId/SubAccountName са унифицирани. Chargeback по account, subscription или project става тривиален.
Препоръчителна chargeback архитектура за 2026 г.: dbt модел над FOCUS таблиците, който прибавя hierarchy от ServiceNow CMDB или Atlassian Compass (team → product → cost_center), материализира месечен showback fact table и експортира към ERP (NetSuite, SAP) за вътрешен journal entry. За проследяване на аномалии вижте също AWS Cost Explorer, Budgets и Cost Anomaly Detection, който работи отлично заедно с FOCUS като secondary signal.
Капани, които съм виждала в production
Няколко практически бележки от ротации в multi-account FinOps екипи. Първият проект, в който shipнах FOCUS pipeline на пълен Enterprise scale, изяде около месец повече, отколкото бях планирала, точно заради тези капани:
Грешка #1: третиране на BilledCost като source of truth за amortization. Винаги използвайте EffectiveCost за месечен showback, иначе генерирате spikes в месеците на покупка на RI/SP. Хванах този бъг минути преди да пусна Q1 chargeback ревюто (някои екипи изглеждаха като че са изгорели целия си бюджет за един месец).
Грешка #2: игнориране на ChargeCategory. Filtering без ChargeCategory IN ('Usage', 'Purchase') ще включи Tax и Credit редове, които изкривяват dashboards.
Грешка #3: предположението, че Tags колоната винаги е попълнена. Untagged ресурси са най-голямата дупка в cost allocation. Преди да тръгнете към FOCUS, инвестирайте в tag governance: AWS Resource Groups Tag Policies, Azure Policy за required tags, GCP Org Policy за required labels.
Грешка #4: опора на x_ колони. Те са portable между версии на провайдера, но не между провайдери. Ако ще пишете заявка, която иска да знае EC2 instance type, абстрахирайте го в dbt layer.
Грешка #5: забравяне на currency. BillingCurrency може да е USD за US акаунти, EUR за европейски, JPY за японски. Ако имате multi-region presence, конвертирайте до една reporting валута на ниво dbt модел с monthly exchange rates.
Често задавани въпроси
Кои облачни доставчици поддържат FOCUS?
Към юни 2026 г. AWS, Microsoft Azure, Google Cloud, Oracle Cloud Infrastructure и редица SaaS доставчици (Datadog, Snowflake, MongoDB Atlas) предлагат FOCUS-conformant export. AWS и Azure поддържат FOCUS 1.1. GCP поддържа FOCUS 1.0 и обяви upgrade към 1.1 за H2 2026.
FOCUS замества ли CUR 2.0 в AWS?
Не. CUR 2.0 продължава да съществува паралелно с FOCUS export-а в AWS Data Exports. CUR 2.0 е по-detailen за provider-specific анализи (например usage type discounts, BlendedCost), докато FOCUS е оптимизиран за cross-cloud и cross-source aggregation. Препоръката ми: генерирайте и двата.
Каква е разликата между BilledCost и EffectiveCost във FOCUS?
BilledCost е сумата, която доставчикът ви фактурира за периода, и включва upfront заплащания изцяло в месеца на покупка. EffectiveCost amortizra тези upfront суми пропорционално в живота на commitment-а, така че месечните разходи отразяват реалната usage за месеца, а не cash flow timing.
Колко струва активирането на FOCUS export?
Самият export е безплатен във всички major облаци. Плащате само за storage (S3, Blob или GCS) и query compute (Athena, Synapse или BigQuery). За средно по размер организация (около $500K на месец cloud spend) очаквайте под $50 на месец за storage и $20-100 на месец за query compute, в зависимост от честотата на дашбордите.
Мога ли да ползвам FOCUS за обединена бюджетна аномалия детекция?
Да, и това е един от най-силните use cases. Стандартизираните колони ви позволяват да тренирате един anomaly detection модел (Prophet, isolation forest) върху EffectiveCost за всички доставчици, вместо да правите три отделни. Резултатът е по-малко false positives и една унифицирана alerting тръба към PagerDuty или Slack.
Практическо ръководство за намаляване на data transfer (egress) разходите в AWS, Azure и GCP през 2026: VPC Endpoints, CloudFront, NAT Gateway оптимизация, cross-AZ трафик и алтернативи с нулев egress като Cloudflare R2 и Backblaze B2.
Пълно ръководство за AWS Cost Explorer, AWS Budgets и Cost Anomaly Detection — три безплатни инструмента на AWS за мониторинг и контрол на облачните разходи. С примери за CLI, Python и CloudFormation.