FinOps Multi-Cloud en 2026 : Normaliser les Dépenses AWS, Azure, GCP et Kubernetes avec FOCUS 1.0
Découvrez comment les équipes d'ingénierie et financières normalisent les exports de facturation multi-cloud (AWS CUR 2.0, Azure Cost Management, GCP BigQuery, OCI et OpenCost) dans un grand livre FOCUS 1.0 unifié pour l'économie unitaire en temps réel.
- Canonical cost normalization across AWS, Azure, GCP, Kubernetes, and LLM APIs into FOCUS 1.0 schema.
- Real-time COGS and gross margin attribution mapped directly to engineering teams and customer tenants.
- Flat monthly pricing with engineer-executed savings automation, avoiding vendor lock-in or savings tax penalties.
Multi-cloud FinOps in 2026 is the discipline of normalizing disparate cloud billing schemas—spanning AWS Cost and Usage Reports (CUR 2.0), Azure Cost Management exports, Google Cloud Billing BigQuery datasets, Oracle Cloud Infrastructure (OCI) cost reports, Kubernetes OpenCost metrics, and AI/LLM token telemetry—into the FinOps Open Cost and Usage Specification (FOCUS 1.0). By unifying every provider into a single analytical ledger, engineering leaders eliminate cross-cloud blind spots, attribute shared Kubernetes and AI infrastructure down to the unit-customer level, and execute commitment and rightsizing optimizations without manual spreadsheet reconciliation.
For CTOs, VPs of Engineering, and FinOps leads operating across the UK, Europe, and North America, cloud sprawl is rarely a deliberate strategy—it is the natural byproduct of acquisitions, specialized workloads, and AI adoption. Your core workloads might run on AWS EKS, enterprise data warehousing on Snowflake or GCP BigQuery, identity and enterprise workloads on Azure, and customer-facing AI features on OpenAI and Anthropic. When each platform reports usage in incompatible billing dimensions, answering a simple executive question like "What did our margin per enterprise tenant look like last week?" becomes a multi-day data engineering project.
At CostGlass, we built our multi-cloud FinOps platform natively on FOCUS 1.0—combining read-only multi-cloud ingestion across eight cloud providers, Kubernetes, and AI/SaaS APIs with engineer-executed remediation at a flat monthly price. Here is the architectural blueprint for implementing unified FOCUS 1.0 cost normalization across your infrastructure.
Why Native Cloud Billing Schemas Break Multi-Cloud Attribution
Every hyperscaler evolved its billing export around its own internal resource hierarchy and discounting mechanics:
- Inconsistent Cost Metrics: AWS distinguishes between
UnblendedCost,BlendedCost,AmortizedCost, andNetAmortizedCost. Azure separatesActualCostandAmortizedCostacross Enterprise Agreement (EA) and Microsoft Customer Agreement (MCA) schemas. GCP usescostcombined with nestedcreditsarrays for Sustained Use Discounts (SUDs) and Committed Use Discounts (CUDs). - Incompatible Commitment Accounting: Calculating true effective hourly cost requires amortizing AWS Compute Savings Plans, Azure Reserved VM Instances, and GCP resource-based CUDs across dynamic workloads—while isolating unused commitment waste (
UnusedCommitment) from active workload consumption. - Fragmented Tagging and Labels: AWS resource tags (
resource_tags_user_*), GCP labels (lowercase-only keys), Azure resource group tags (which do not always inherit down to child resources automatically), and Kubernetes pod labels rarely align 1:1 in production.
Technical Breakdown: The FOCUS 1.0 Normalization Pipeline
The FinOps Foundation's FOCUS 1.0 specification solves schema fragmentation by defining canonical columns for cost, usage, charge categories, and commitment attribution:
| FOCUS 1.0 Column | Purpose in Unified FinOps Ledger | Native Source Mapping Examples |
|---|---|---|
BilledCost |
Cash-basis invoice amount before amortization | AWS line_item_unblended_cost, Azure CostInBillingCurrency, GCP cost |
EffectiveCost |
True amortized cost after applying RIs, Savings Plans, and CUDs | AWS savings_plan_savings_plan_effective_cost, GCP cost + SUM(credits.amount) |
ListCost |
On-demand public pricing baseline for quantifying discount savings | AWS pricing_public_on_demand_cost, Azure PayGPrice * Quantity |
ChargeCategory |
Classifies line items into Usage, Purchase, Tax, Credit, or Adjustment |
Normalizes upfront RI fees vs. recurring hourly usage |
CommitmentDiscountId |
Links discounted usage back to the exact Savings Plan, RI, or CUD ARN/ID | Enables cross-cloud commitment utilization & expiry tracking |
Virtual Tagging Without Re-Deploying Infrastructure
Even after schema normalization, raw cloud tags are never 100% compliant. Retroactively tagging historical billing rows or mutating production Terraform state just to fix a cost center label introduces unnecessary operational risk.
Instead, modern FinOps architectures apply Virtual Tagging rules at query/ingestion time over the normalized FOCUS dataset. Using deterministic rules across SubAccountId, ServiceName, RegionId, ResourceId patterns, and existing Tags JSONB maps, you can allocate 100% of multi-cloud and untagged shared spend without touching a single production cloud resource.
Code Example: Normalizing Multi-Cloud Spend into FOCUS 1.0 with SQL
Below is a production-grade analytical SQL pattern demonstrating how raw AWS CUR 2.0 and GCP Billing records are transformed into a unified FOCUS 1.0 view with effective commitment amortization:
-- Unified FOCUS 1.0 Cost Normalization View (AWS CUR 2.0 + GCP BigQuery Export)
WITH normalized_focus_ledger AS (
-- 1. AWS CUR 2.0 Normalization
SELECT
DATE_TRUNC('day', line_item_usage_start_date) AS charge_period_start,
'aws' AS provider_name,
line_item_usage_account_id AS sub_account_id,
product_servicecode AS service_name,
product_region_code AS region_id,
line_item_resource_id AS resource_id,
CASE
WHEN line_item_line_item_type IN ('DiscountedUsage', 'SavingsPlanCoveredUsage', 'Usage') THEN 'Usage'
WHEN line_item_line_item_type IN ('Fee', 'RIFee', 'SavingsPlanRecurringFee') THEN 'Purchase'
WHEN line_item_line_item_type = 'Tax' THEN 'Tax'
WHEN line_item_line_item_type = 'Credit' THEN 'Credit'
ELSE 'Adjustment'
END AS charge_category,
CAST(line_item_unblended_cost AS NUMERIC(18, 6)) AS billed_cost,
CAST(
CASE
WHEN line_item_line_item_type = 'SavingsPlanCoveredUsage'
THEN savings_plan_savings_plan_effective_cost
WHEN line_item_line_item_type = 'DiscountedUsage'
THEN reservation_effective_cost
WHEN line_item_line_item_type IN ('SavingsPlanRecurringFee', 'SavingsPlanUpfrontFee', 'RIFee')
THEN COALESCE( reservation_unused_amortized_upfront_fee_for_billing_period
+ reservation_unused_recurring_fee, 0 )
ELSE line_item_unblended_cost
END AS NUMERIC(18, 6)
) AS effective_cost,
CAST(pricing_public_on_demand_cost AS NUMERIC(18, 6)) AS list_cost,
COALESCE(savings_plan_savings_plan_a_r_n, reservation_reservation_a_r_n) AS commitment_discount_id,
resource_tags AS tags
FROM raw_aws_cur_v2
WHERE line_item_usage_start_date >= CURRENT_DATE - INTERVAL '30 days'
UNION ALL
-- 2. GCP Billing Export Normalization
SELECT
DATE_TRUNC('day', usage_start_time) AS charge_period_start,
'gcp' AS provider_name,
project.id AS sub_account_id,
service.description AS service_name,
location.region AS region_id,
resource.global_name AS resource_id,
CASE
WHEN cost_type = 'tax' THEN 'Tax'
WHEN cost_type = 'adjustment' THEN 'Adjustment'
ELSE 'Usage'
END AS charge_category,
CAST(cost AS NUMERIC(18, 6)) AS billed_cost,
CAST(cost + COALESCE(credits_sum.total_credit, 0) AS NUMERIC(18, 6)) AS effective_cost,
CAST(cost_at_list AS NUMERIC(18, 6)) AS list_cost,
credits_sum.commitment_id AS commitment_discount_id,
labels_jsonb AS tags
FROM raw_gcp_billing_export
LEFT JOIN LATERAL (
SELECT
SUM(c.amount) AS total_credit,
MAX(CASE WHEN c.type IN ('COMMITTED_USAGE_DISCOUNT', 'COMMITTED_USAGE_DISCOUNT_DOLLAR_BASE') THEN c.id END) AS commitment_id
FROM UNNEST(credits) AS c
) credits_sum ON TRUE
WHERE usage_start_time >= CURRENT_DATE - INTERVAL '30 days'
)
SELECT
provider_name,
service_name,
SUM(billed_cost) AS total_billed_cost,
SUM(effective_cost) AS total_effective_cost,
SUM(list_cost - effective_cost) AS commitment_and_negotiated_savings,
ROUND(
100.0 * (1.0 - NULLIF(SUM(effective_cost), 0) / NULLIF(SUM(list_cost), 0)),
2
) AS effective_savings_rate_pct
FROM normalized_focus_ledger
WHERE charge_category = 'Usage'
GROUP BY provider_name, service_name
ORDER BY total_effective_cost DESC;Integrating Kubernetes (OpenCost) and AI Token Telemetry
Cloud billing exports tell you that an m6i.4xlarge EKS node or an Azure AKS node pool cost $420 last week—but they do not tell you which microservice or customer tenant consumed those CPU and memory cycles.
To close the loop:
- Kubernetes Cost Allocation via OpenCost: Scrape pod-level CPU, RAM, GPU, and PersistentVolume claims and weight them against the node's
EffectiveCostfrom the FOCUS ledger (so Savings Plan and Spot discounts flow proportionally to the namespaces running on those nodes). - AI & LLM Spend Attribution: Ingest organization-level usage and cost APIs from OpenAI and Anthropic alongside Snowflake and Datadog. Map API keys or workspace IDs to the same Virtual Tag dimensions (
environment,team,product,tenant) used for cloud compute.
Turning Visibility into Engineer-Executed Savings
Dashboards alone do not reduce your cloud bill. Even when a FinOps tool flags orphaned EBS volumes, over-provisioned RDS instances, idle non-production clusters, or expiring Savings Plans, internal platform teams are often too backlogged shipping product features to execute the fixes.
With CostGlass, you connect read-only access across AWS, Azure, Google Cloud, OCI, Alibaba Cloud, DigitalOcean, Linode, Cloudflare, Kubernetes, OpenAI, Anthropic, Snowflake, and Datadog in minutes:
- Unified FOCUS 1.0 Analytics & Virtual Tags: Explore 13 months of history, unit economics, and anomaly alerts routed directly to Slack and email.
- Flat, Predictable Pricing: Never pay a percentage of your cloud spend.
- Done-For-You Engineering Execution: On our Scale and Enterprise plans, CostGlass engineers execute the optimizations you approve—from off-hours scheduling and storage tiering to rightsizing and commitment management—tracked with before-and-after verification in your savings ledger.
Ready to see your multi-cloud, Kubernetes, and AI spend in a single FOCUS 1.0 view? Start free on CostGlass or explore our platform documentation.
FinOps multinube en 2026 es la disciplina de normalizar esquemas dispares de facturación en la nube —abarcando AWS Cost and Usage Reports (CUR 2.0), exportaciones de Azure Cost Management, conjuntos de datos de Google Cloud Billing en BigQuery, informes de costos de Oracle Cloud Infrastructure (OCI), métricas de OpenCost en Kubernetes y telemetría de tokens de IA/LLM— hacia la especificación abierta FOCUS 1.0 (FinOps Open Cost and Usage Specification). Al unificar cada proveedor en un único libro mayor analítico, los líderes de ingeniería eliminan los puntos ciegos entre nubes, atribuyen la infraestructura compartida de Kubernetes e IA hasta el nivel de cliente unitario y ejecutan optimizaciones de compromisos y rightsizing sin conciliaciones manuales en hojas de cálculo.
Para los CTO, VP de Ingeniería y responsables de FinOps que operan en el Reino Unido, Europa y Norteamérica, la proliferación multinube rara vez es una estrategia deliberada: es el resultado natural de adquisiciones, cargas de trabajo especializadas y la adopción de IA. Sus cargas principales pueden ejecutarse en AWS EKS, el almacenamiento de datos empresarial en Snowflake o GCP BigQuery, las cargas de identidad y corporativas en Azure, y las funciones de IA orientadas al cliente en OpenAI y Anthropic. Cuando cada plataforma informa el consumo en dimensiones incompatibles, responder a una pregunta ejecutiva sencilla como "¿Cuál fue nuestro margen por cliente empresarial la semana pasada?" se convierte en un proyecto de ingeniería de datos de varios días.
En CostGlass, construimos nuestra plataforma FinOps multinube de forma nativa sobre FOCUS 1.0, combinando la ingesta de solo lectura en ocho proveedores de nube, Kubernetes y APIs de IA/SaaS con remediación ejecutada por ingenieros a una tarifa mensual fija. A continuación presentamos el plano arquitectónico para implementar la normalización de costos FOCUS 1.0 en su infraestructura.
Por Qué los Esquemas Nativos de Facturación Rompen la Atribución Multinube
Cada hiperescalador desarrolló su exportación de facturación en torno a su propia jerarquía interna de recursos y mecánicas de descuento:
- Métricas de Costo Inconsistentes: AWS distingue entre
UnblendedCost,BlendedCost,AmortizedCostyNetAmortizedCost. Azure separaActualCostyAmortizedCostentre esquemas Enterprise Agreement (EA) y Microsoft Customer Agreement (MCA). GCP utilizacostcombinado con arreglos anidadoscreditspara Descuentos por Uso Sostenido (SUD) y Descuentos por Compromiso de Uso (CUD). - Contabilidad Incompatible de Compromisos: Calcular el costo horario efectivo real requiere amortizar AWS Compute Savings Plans, Instancias Reservadas de Azure y CUD basados en recursos de GCP en cargas dinámicas, aislando al mismo tiempo el desperdicio de compromisos no utilizados (
UnusedCommitment). - Etiquetado Fragmentado: Las etiquetas de recursos de AWS (
resource_tags_user_*), las etiquetas de GCP (solo minúsculas), las etiquetas de grupos de recursos de Azure (que no siempre se heredan automáticamente) y las etiquetas de pods de Kubernetes rara vez coinciden 1:1 en producción.
Desglose Técnico: El Pipeline de Normalización FOCUS 1.0
La especificación FOCUS 1.0 de la FinOps Foundation resuelve la fragmentación de esquemas definiendo columnas canónicas para costos, consumo, categorías de cargos y atribución de compromisos:
| Columna FOCUS 1.0 | Propósito en el Libro Mayor FinOps Unificado | Ejemplos de Mapeo desde Fuentes Nativas |
|---|---|---|
BilledCost |
Importe facturado en base de caja antes de la amortización | AWS line_item_unblended_cost, Azure CostInBillingCurrency, GCP cost |
EffectiveCost |
Costo amortizado real tras aplicar RI, Savings Plans y CUD | AWS savings_plan_savings_plan_effective_cost, GCP cost + SUM(credits.amount) |
ListCost |
Precio público bajo demanda para cuantificar ahorros por descuento | AWS pricing_public_on_demand_cost, Azure PayGPrice * Quantity |
ChargeCategory |
Clasifica las líneas en Usage, Purchase, Tax, Credit o Adjustment |
Normaliza tarifas iniciales de RI frente al uso horario recurrente |
CommitmentDiscountId |
Vincula el uso con descuento al ARN/ID exacto del Savings Plan, RI o CUD | Permite rastrear la utilización y vencimiento de compromisos entre nubes |
Etiquetado Virtual (Virtual Tagging) sin Redirigir ni Redesplegar Infraestructura
Incluso después de normalizar el esquema, las etiquetas nativas nunca cumplen al 100%. Etiquetar retroactivamente filas históricas o modificar el estado de Terraform en producción solo para corregir un centro de costos introduce riesgos operativos innecesarios.
En su lugar, las arquitecturas FinOps modernas aplican reglas de Etiquetado Virtual en tiempo de consulta sobre el conjunto de datos FOCUS normalizado. Mediante reglas deterministas sobre SubAccountId, ServiceName, RegionId, patrones de ResourceId y mapas JSONB Tags, puede asignar el 100% del gasto compartido y no etiquetado sin tocar un solo recurso en producción.
Ejemplo de Código: Normalización del Gasto Multinube en FOCUS 1.0 con SQL
A continuación se muestra un patrón SQL analítico de nivel de producción que transforma registros de AWS CUR 2.0 y GCP Billing en una vista FOCUS 1.0 unificada con amortización efectiva de compromisos:
-- Unified FOCUS 1.0 Cost Normalization View (AWS CUR 2.0 + GCP BigQuery Export)
WITH normalized_focus_ledger AS (
-- 1. AWS CUR 2.0 Normalization
SELECT
DATE_TRUNC('day', line_item_usage_start_date) AS charge_period_start,
'aws' AS provider_name,
line_item_usage_account_id AS sub_account_id,
product_servicecode AS service_name,
product_region_code AS region_id,
line_item_resource_id AS resource_id,
CASE
WHEN line_item_line_item_type IN ('DiscountedUsage', 'SavingsPlanCoveredUsage', 'Usage') THEN 'Usage'
WHEN line_item_line_item_type IN ('Fee', 'RIFee', 'SavingsPlanRecurringFee') THEN 'Purchase'
WHEN line_item_line_item_type = 'Tax' THEN 'Tax'
WHEN line_item_line_item_type = 'Credit' THEN 'Credit'
ELSE 'Adjustment'
END AS charge_category,
CAST(line_item_unblended_cost AS NUMERIC(18, 6)) AS billed_cost,
CAST(
CASE
WHEN line_item_line_item_type = 'SavingsPlanCoveredUsage'
THEN savings_plan_savings_plan_effective_cost
WHEN line_item_line_item_type = 'DiscountedUsage'
THEN reservation_effective_cost
WHEN line_item_line_item_type IN ('SavingsPlanRecurringFee', 'SavingsPlanUpfrontFee', 'RIFee')
THEN COALESCE( reservation_unused_amortized_upfront_fee_for_billing_period
+ reservation_unused_recurring_fee, 0 )
ELSE line_item_unblended_cost
END AS NUMERIC(18, 6)
) AS effective_cost,
CAST(pricing_public_on_demand_cost AS NUMERIC(18, 6)) AS list_cost,
COALESCE(savings_plan_savings_plan_a_r_n, reservation_reservation_a_r_n) AS commitment_discount_id,
resource_tags AS tags
FROM raw_aws_cur_v2
WHERE line_item_usage_start_date >= CURRENT_DATE - INTERVAL '30 days'
UNION ALL
-- 2. GCP Billing Export Normalization
SELECT
DATE_TRUNC('day', usage_start_time) AS charge_period_start,
'gcp' AS provider_name,
project.id AS sub_account_id,
service.description AS service_name,
location.region AS region_id,
resource.global_name AS resource_id,
CASE
WHEN cost_type = 'tax' THEN 'Tax'
WHEN cost_type = 'adjustment' THEN 'Adjustment'
ELSE 'Usage'
END AS charge_category,
CAST(cost AS NUMERIC(18, 6)) AS billed_cost,
CAST(cost + COALESCE(credits_sum.total_credit, 0) AS NUMERIC(18, 6)) AS effective_cost,
CAST(cost_at_list AS NUMERIC(18, 6)) AS list_cost,
credits_sum.commitment_id AS commitment_discount_id,
labels_jsonb AS tags
FROM raw_gcp_billing_export
LEFT JOIN LATERAL (
SELECT
SUM(c.amount) AS total_credit,
MAX(CASE WHEN c.type IN ('COMMITTED_USAGE_DISCOUNT', 'COMMITTED_USAGE_DISCOUNT_DOLLAR_BASE') THEN c.id END) AS commitment_id
FROM UNNEST(credits) AS c
) credits_sum ON TRUE
WHERE usage_start_time >= CURRENT_DATE - INTERVAL '30 days'
)
SELECT
provider_name,
service_name,
SUM(billed_cost) AS total_billed_cost,
SUM(effective_cost) AS total_effective_cost,
SUM(list_cost - effective_cost) AS commitment_and_negotiated_savings,
ROUND(
100.0 * (1.0 - NULLIF(SUM(effective_cost), 0) / NULLIF(SUM(list_cost), 0)),
2
) AS effective_savings_rate_pct
FROM normalized_focus_ledger
WHERE charge_category = 'Usage'
GROUP BY provider_name, service_name
ORDER BY total_effective_cost DESC;Integración de Kubernetes (OpenCost) y Telemetría de Tokens de IA
Las exportaciones de facturación en la nube le indican que un nodo EKS m6i.4xlarge o un grupo de nodos Azure AKS costó $420 la semana pasada, pero no le dicen qué microservicio o cliente consumió esos ciclos de CPU y memoria.
Para cerrar el ciclo:
- Asignación de Costos de Kubernetes mediante OpenCost: Recopile las solicitudes y el consumo real de CPU, RAM, GPU y PersistentVolumes a nivel de pod y pondérelos frente al
EffectiveCostdel nodo en el libro mayor FOCUS (de modo que los descuentos de Savings Plans e instancias Spot fluyan proporcionalmente hacia los namespaces). - Atribución de Gasto en IA y LLM: Ingestione las APIs de uso y costos de OpenAI y Anthropic junto con Snowflake y Datadog, asignando claves de API o espacios de trabajo a las mismas dimensiones de Etiquetas Virtuales (
environment,team,product,tenant).
Convirtiendo la Visibilidad en Ahorros Ejecutados por Ingenieros
Los paneles por sí solos no reducen su factura en la nube. Incluso cuando una herramienta FinOps detecta volúmenes EBS huérfanos, instancias RDS sobredimensionadas, clústeres de desarrollo inactivos o Savings Plans próximos a vencer, los equipos internos de plataforma suelen estar demasiado saturados entregando funcionalidades de producto como para aplicar las correcciones.
Con CostGlass, usted conecta acceso de solo lectura en AWS, Azure, Google Cloud, OCI, Alibaba Cloud, DigitalOcean, Linode, Cloudflare, Kubernetes, OpenAI, Anthropic, Snowflake y Datadog en minutos:
- Analítica FOCUS 1.0 Unificada y Etiquetas Virtuales: Explore 13 meses de historial en el Cost Explorer, economía unitaria y alertas de anomalías enviadas directamente a Slack y correo electrónico.
- Precios Fijos y Predecibles: Nunca pague un porcentaje de su gasto en la nube.
- Ejecución de Ingeniería Llave en Mano: En nuestros planes Scale y Enterprise, los ingenieros de CostGlass ejecutan las optimizaciones que usted aprueba —desde programación fuera de horario y rightsizing hasta gestión de compromisos— con verificación antes y después en su registro de ahorros.
¿Listo para ver su gasto multinube, de Kubernetes y de IA en una única vista FOCUS 1.0? Comience gratis en CostGlass o explore nuestra documentación técnica.
Multi-Cloud FinOps im Jahr 2026 ist die Disziplin, heterogene Cloud-Abrechnungsschemata – von AWS Cost and Usage Reports (CUR 2.0), Azure Cost Management-Exporten, Google Cloud Billing BigQuery-Datasets und Oracle Cloud Infrastructure (OCI)-Kostenberichten bis hin zu Kubernetes OpenCost-Metriken und KI/LLM-Token-Telemetrie – in die FinOps Open Cost and Usage Specification (FOCUS 1.0) zu normalisieren. Durch die Vereinheitlichung aller Anbieter in einem einzigen analytischen Hauptbuch beseitigen Engineering-Führungskräfte Cloud-übergreifende blinde Flecken, ordnen gemeinsam genutzte Kubernetes- und KI-Infrastruktur bis auf die Ebene einzelner Mandanten zu und setzen Commitment- sowie Rightsizing-Optimierungen ohne manuelle Tabellenkalkulationen um.
Für CTOs, VPs of Engineering und FinOps-Verantwortliche in Großbritannien, Europa und Nordamerika ist Cloud-Wildwuchs selten eine bewusste Strategie – er ist das natürliche Nebenprodukt von Übernahmen, spezialisierten Workloads und der Einführung von KI. Ihre Kern-Workloads laufen möglicherweise auf AWS EKS, das Enterprise Data Warehousing auf Snowflake oder GCP BigQuery, Identitäts- und Unternehmens-Workloads auf Azure und kundenorientierte KI-Funktionen auf OpenAI und Anthropic. Wenn jede Plattform die Nutzung in inkompatiblen Abrechnungsdimensionen ausweist, wird die Beantwortung einer einfachen Führungsfrage wie „Wie sah unsere Marge pro Enterprise-Mandant letzte Woche aus?“ schnell zu einem mehrtägigen Data-Engineering-Projekt.
Bei CostGlass haben wir unsere Multi-Cloud-FinOps-Plattform nativ auf FOCUS 1.0 aufgebaut – wir kombinieren schreibgeschützte Multi-Cloud-Ingestion über acht Cloud-Provider, Kubernetes und KI/SaaS-APIs mit durch Ingenieure ausgeführter Optimierung zum monatlichen Festpreis. Hier ist der Architektur-Bauplan für die Einführung einer einheitlichen FOCUS 1.0-Kostennormalisierung in Ihrer Infrastruktur.
Warum Native Cloud-Abrechnungsschemata die Multi-Cloud-Zuordnung Brechen
Jeder Hyperscaler hat seinen Abrechnungsexport rund um seine eigene interne Ressourcenhierarchie und Rabattmechanik entwickelt:
- Inkonsistente Kostenmetriken: AWS unterscheidet zwischen
UnblendedCost,BlendedCost,AmortizedCostundNetAmortizedCost. Azure trenntActualCostundAmortizedCostüber Enterprise Agreement (EA)- und Microsoft Customer Agreement (MCA)-Schemata hinweg. GCP verwendetcostkombiniert mit verschachteltencredits-Arrays für Sustained Use Discounts (SUDs) und Committed Use Discounts (CUDs). - Inkompatible Commitment-Bilanzierung: Die Berechnung der tatsächlichen effektiven Stundenkosten erfordert die Amortisierung von AWS Compute Savings Plans, Azure Reserved VM Instances und ressourcenbasierten GCP-CUDs über dynamische Workloads hinweg – während gleichzeitig ungenutzte Verpflichtungen (
UnusedCommitment) vom aktiven Workload-Verbrauch isoliert werden müssen. - Fragmentiertes Tagging und Labeling: AWS-Ressourcen-Tags (
resource_tags_user_*), GCP-Labels (nur Kleinbuchstaben), Azure-Ressourcengruppen-Tags (die nicht immer automatisch an untergeordnete Ressourcen vererbt werden) und Kubernetes-Pod-Labels stimmen in der Produktion selten 1:1 überein.
Technische Analyse: Die FOCUS 1.0-Normalisierungs-Pipeline
Die FOCUS 1.0-Spezifikation der FinOps Foundation löst die Schema-Fragmentierung durch die Definition kanonischer Spalten für Kosten, Nutzung, Gebührenkategorien und Commitment-Zuordnung:
| FOCUS 1.0-Spalte | Zweck im Einheitlichen FinOps-Ledger | Beispiele für das Native Quell-Mapping |
|---|---|---|
BilledCost |
Rechnungsbetrag auf Cash-Basis vor Amortisierung | AWS line_item_unblended_cost, Azure CostInBillingCurrency, GCP cost |
EffectiveCost |
Wahre amortisierte Kosten nach Anwendung von RIs, Savings Plans und CUDs | AWS savings_plan_savings_plan_effective_cost, GCP cost + SUM(credits.amount) |
ListCost |
Öffentlicher On-Demand-Listenpreis zur Quantifizierung von Rabatteinsparungen | AWS pricing_public_on_demand_cost, Azure PayGPrice * Quantity |
ChargeCategory |
Klassifiziert Posten in Usage, Purchase, Tax, Credit oder Adjustment |
Normalisiert RI-Vorabgebühren gegenüber wiederkehrender Stundennutzung |
CommitmentDiscountId |
Verknüpft rabattierte Nutzung mit der exakten Savings Plan-, RI- oder CUD-ARN/ID | Ermöglicht Cloud-übergreifendes Tracking von Commitment-Auslastung und Ablaufdaten |
Virtuelles Tagging Ohne Infrastruktur-Redeployment
Selbst nach der Schema-Normalisierung sind native Cloud-Tags niemals zu 100 % konsistent. Das rückwirkende Taggen historischer Abrechnungszeilen oder das Ändern des produktiven Terraform-States nur zur Korrektur einer Kostenstelle birgt unnötige Betriebsrisiken.
Stattdessen wenden moderne FinOps-Architekturen Virtual-Tagging-Regeln zur Abfrage- bzw. Ingestionszeit auf dem normalisierten FOCUS-Datensatz an. Mit deterministischen Regeln über SubAccountId, ServiceName, RegionId, ResourceId-Muster und bestehende Tags-JSONB-Maps können Sie 100 % der Multi-Cloud- und nicht getaggten Gemeinkosten zuordnen, ohne eine einzige produktive Cloud-Ressource anzufassen.
Codebeispiel: Multi-Cloud-Ausgaben mit SQL in FOCUS 1.0 Normalisieren
Das folgende produktionsreife analytische SQL-Muster zeigt, wie Rohdaten aus AWS CUR 2.0 und GCP Billing inklusive effektiver Commitment-Amortisierung in eine einheitliche FOCUS 1.0-Ansicht transformiert werden:
-- Unified FOCUS 1.0 Cost Normalization View (AWS CUR 2.0 + GCP BigQuery Export)
WITH normalized_focus_ledger AS (
-- 1. AWS CUR 2.0 Normalization
SELECT
DATE_TRUNC('day', line_item_usage_start_date) AS charge_period_start,
'aws' AS provider_name,
line_item_usage_account_id AS sub_account_id,
product_servicecode AS service_name,
product_region_code AS region_id,
line_item_resource_id AS resource_id,
CASE
WHEN line_item_line_item_type IN ('DiscountedUsage', 'SavingsPlanCoveredUsage', 'Usage') THEN 'Usage'
WHEN line_item_line_item_type IN ('Fee', 'RIFee', 'SavingsPlanRecurringFee') THEN 'Purchase'
WHEN line_item_line_item_type = 'Tax' THEN 'Tax'
WHEN line_item_line_item_type = 'Credit' THEN 'Credit'
ELSE 'Adjustment'
END AS charge_category,
CAST(line_item_unblended_cost AS NUMERIC(18, 6)) AS billed_cost,
CAST(
CASE
WHEN line_item_line_item_type = 'SavingsPlanCoveredUsage'
THEN savings_plan_savings_plan_effective_cost
WHEN line_item_line_item_type = 'DiscountedUsage'
THEN reservation_effective_cost
WHEN line_item_line_item_type IN ('SavingsPlanRecurringFee', 'SavingsPlanUpfrontFee', 'RIFee')
THEN COALESCE( reservation_unused_amortized_upfront_fee_for_billing_period
+ reservation_unused_recurring_fee, 0 )
ELSE line_item_unblended_cost
END AS NUMERIC(18, 6)
) AS effective_cost,
CAST(pricing_public_on_demand_cost AS NUMERIC(18, 6)) AS list_cost,
COALESCE(savings_plan_savings_plan_a_r_n, reservation_reservation_a_r_n) AS commitment_discount_id,
resource_tags AS tags
FROM raw_aws_cur_v2
WHERE line_item_usage_start_date >= CURRENT_DATE - INTERVAL '30 days'
UNION ALL
-- 2. GCP Billing Export Normalization
SELECT
DATE_TRUNC('day', usage_start_time) AS charge_period_start,
'gcp' AS provider_name,
project.id AS sub_account_id,
service.description AS service_name,
location.region AS region_id,
resource.global_name AS resource_id,
CASE
WHEN cost_type = 'tax' THEN 'Tax'
WHEN cost_type = 'adjustment' THEN 'Adjustment'
ELSE 'Usage'
END AS charge_category,
CAST(cost AS NUMERIC(18, 6)) AS billed_cost,
CAST(cost + COALESCE(credits_sum.total_credit, 0) AS NUMERIC(18, 6)) AS effective_cost,
CAST(cost_at_list AS NUMERIC(18, 6)) AS list_cost,
credits_sum.commitment_id AS commitment_discount_id,
labels_jsonb AS tags
FROM raw_gcp_billing_export
LEFT JOIN LATERAL (
SELECT
SUM(c.amount) AS total_credit,
MAX(CASE WHEN c.type IN ('COMMITTED_USAGE_DISCOUNT', 'COMMITTED_USAGE_DISCOUNT_DOLLAR_BASE') THEN c.id END) AS commitment_id
FROM UNNEST(credits) AS c
) credits_sum ON TRUE
WHERE usage_start_time >= CURRENT_DATE - INTERVAL '30 days'
)
SELECT
provider_name,
service_name,
SUM(billed_cost) AS total_billed_cost,
SUM(effective_cost) AS total_effective_cost,
SUM(list_cost - effective_cost) AS commitment_and_negotiated_savings,
ROUND(
100.0 * (1.0 - NULLIF(SUM(effective_cost), 0) / NULLIF(SUM(list_cost), 0)),
2
) AS effective_savings_rate_pct
FROM normalized_focus_ledger
WHERE charge_category = 'Usage'
GROUP BY provider_name, service_name
ORDER BY total_effective_cost DESC;Integration von Kubernetes (OpenCost) und KI-Token-Telemetrie
Cloud-Abrechnungsexporte zeigen Ihnen zwar, dass ein m6i.4xlarge EKS-Knoten oder ein Azure AKS-Nodepool letzte Woche 420 $ gekostet hat – sie verraten Ihnen jedoch nicht, welcher Microservice oder welcher Kundenmandant diese CPU- und Speicherzyklen verbraucht hat.
So schließen Sie die Lücke:
- Kubernetes-Kostenzuweisung über OpenCost: Erfassen Sie CPU-, RAM-, GPU- und PersistentVolume-Ansprüche auf Pod-Ebene und gewichten Sie diese gegen die
EffectiveCostdes Knotens aus dem FOCUS-Ledger (sodass Savings-Plan- und Spot-Rabatte anteilig den Namespaces auf diesen Knoten zugerechnet werden). - KI- & LLM-Ausgabenzuordnung: Integrieren Sie Nutzungs- und Kosten-APIs auf Organisationsebene von OpenAI und Anthropic zusammen mit Snowflake und Datadog. Ordnen Sie API-Schlüssel oder Workspace-IDs denselben Virtual-Tag-Dimensionen (
environment,team,product,tenant) zu wie Ihre Cloud-Compute-Ressourcen.
Sichtbarkeit in durch Ingenieure Umgesetzte Einsparungen Verwandeln
Dashboards allein senken noch keine Cloud-Rechnung. Selbst wenn ein FinOps-Tool verwaiste EBS-Volumes, überdimensionierte RDS-Instanzen, ungenutzte Nicht-Produktions-Cluster oder auslaufende Savings Plans meldet, sind interne Plattform-Teams oft zu stark mit Produkt-Features ausgelastet, um die Optimierungen selbst umzusetzen.
Mit CostGlass verbinden Sie in wenigen Minuten schreibgeschützten Zugriff auf AWS, Azure, Google Cloud, OCI, Alibaba Cloud, DigitalOcean, Linode, Cloudflare, Kubernetes, OpenAI, Anthropic, Snowflake und Datadog:
- Einheitliche FOCUS 1.0-Analytik & Virtuelle Tags: Analysieren Sie 13 Monate Historie im Cost Explorer, Unit Economics und Anomalie-Warnungen direkt in Slack und per E-Mail.
- Transparenter Festpreis: Zahlen Sie niemals einen Prozentsatz Ihrer Cloud-Ausgaben.
- Done-For-You Engineering-Umsetzung: In unseren Scale- und Enterprise-Tarifen setzen CostGlass-Ingenieure die von Ihnen freigegebenen Optimierungen direkt um – von Zeitplänen außerhalb der Geschäftszeiten und Storage-Tiering bis hin zu Rightsizing und Commitment-Management – inklusive Vorher-Nachher-Verifizierung im Einsparungs-Ledger.
Sind Sie bereit, Ihre Multi-Cloud-, Kubernetes- und KI-Ausgaben in einer einzigen FOCUS 1.0-Ansicht zu sehen? Starten Sie kostenlos mit CostGlass oder erkunden Sie unsere Plattform-Dokumentation.
Le FinOps multi-cloud en 2026 est la discipline consistant à normaliser des schémas de facturation cloud disparates — couvrant les rapports AWS Cost and Usage Reports (CUR 2.0), les exports Azure Cost Management, les jeux de données BigQuery de Google Cloud Billing, les rapports de coûts Oracle Cloud Infrastructure (OCI), les métriques Kubernetes OpenCost et la télémétrie de jetons IA/LLM — dans la spécification ouverte FOCUS 1.0 (FinOps Open Cost and Usage Specification). En unifiant chaque fournisseur dans un grand livre analytique unique, les responsables de l'ingénierie éliminent les angles morts inter-cloud, attribuent l'infrastructure partagée Kubernetes et IA jusqu'au niveau du client unitaire, et exécutent des optimisations d'engagements et de rightsizing sans rapprochement manuel sur tableur.
Pour les CTO, VP Engineering et responsables FinOps opérant au Royaume-Uni, en Europe et en Amérique du Nord, la dispersion multi-cloud est rarement une stratégie délibérée : c'est le sous-produit naturel des acquisitions, des charges de travail spécialisées et de l'adoption de l'IA. Vos charges principales peuvent tourner sur AWS EKS, votre entrepôt de données sur Snowflake ou GCP BigQuery, vos charges d'identité et d'entreprise sur Azure, et vos fonctionnalités d'IA sur OpenAI et Anthropic. Lorsque chaque plateforme rapporte l'utilisation selon des dimensions incompatibles, répondre à une question simple de la direction telle que « Quelle était notre marge par client entreprise la semaine dernière ? » devient un projet d'ingénierie des données de plusieurs jours.
Chez CostGlass, nous avons conçu notre plateforme FinOps multi-cloud nativement sur FOCUS 1.0 — en combinant une ingestion en lecture seule sur huit fournisseurs cloud, Kubernetes et les API IA/SaaS avec une remédiation exécutée par nos ingénieurs à un tarif mensuel fixe. Voici le plan architectural permettant d'implémenter une normalisation des coûts FOCUS 1.0 unifiée sur votre infrastructure.
Pourquoi les Schémas Natifs de Facturation Cloud Brisent l'Attribution Multi-Cloud
Chaque hyperscaler a développé son export de facturation autour de sa propre hiérarchie interne de ressources et de ses mécanismes de remise :
- Métriques de Coûts Incohérentes : AWS distingue
UnblendedCost,BlendedCost,AmortizedCostetNetAmortizedCost. Azure sépareActualCostetAmortizedCostentre les schémas Enterprise Agreement (EA) et Microsoft Customer Agreement (MCA). GCP utilisecostcombiné à des tableaux imbriquéscreditspour les remises d'utilisation soutenue (SUD) et les remises sur engagement d'utilisation (CUD). - Comptabilisation Incompatible des Engagements : Calculer le coût horaire effectif réel nécessite d'amortir les AWS Compute Savings Plans, les instances réservées Azure et les CUD GCP sur des charges dynamiques, tout en isolant le gaspillage d'engagement inutilisé (
UnusedCommitment). - Tags et Labels Fragmentés : Les tags de ressources AWS (
resource_tags_user_*), les labels GCP (clés en minuscules uniquement), les tags de groupes de ressources Azure (qui ne sont pas toujours hérités automatiquement) et les labels de pods Kubernetes s'alignent rarement à 1:1 en production.
Analyse Technique : Le Pipeline de Normalisation FOCUS 1.0
La spécification FOCUS 1.0 de la FinOps Foundation résout la fragmentation des schémas en définissant des colonnes canoniques pour le coût, l'utilisation, les catégories de frais et l'attribution des engagements :
| Colonne FOCUS 1.0 | Rôle dans le Grand Livre FinOps Unifié | Exemples de Mappage des Sources Natives |
|---|---|---|
BilledCost |
Montant facturé sur base de trésorerie avant amortissement | AWS line_item_unblended_cost, Azure CostInBillingCurrency, GCP cost |
EffectiveCost |
Coût amorti réel après application des RI, Savings Plans et CUD | AWS savings_plan_savings_plan_effective_cost, GCP cost + SUM(credits.amount) |
ListCost |
Prix public à la demande servant de référence pour quantifier les économies | AWS pricing_public_on_demand_cost, Azure PayGPrice * Quantity |
ChargeCategory |
Classe les lignes en Usage, Purchase, Tax, Credit ou Adjustment |
Normalise les frais initiaux RI par rapport à l'utilisation horaire récurrente |
CommitmentDiscountId |
Relie l'utilisation remisée à l'ARN/ID exact du Savings Plan, RI ou CUD | Permet le suivi inter-cloud du taux d'utilisation et d'expiration des engagements |
Tagging Virtuel Sans Redéploiement d'Infrastructure
Même après normalisation du schéma, les tags cloud bruts ne sont jamais conformes à 100 %. Taguer rétroactivement des lignes de facturation historiques ou modifier l'état Terraform de production uniquement pour corriger un centre de coûts introduit un risque opérationnel inutile.
Les architectures FinOps modernes appliquent plutôt des règles de Tagging Virtuel au moment de l'ingestion ou de la requête sur le jeu de données FOCUS normalisé. À l'aide de règles déterministes sur SubAccountId, ServiceName, RegionId, les motifs de ResourceId et les cartes JSONB Tags existantes, vous pouvez allouer 100 % des dépenses multi-cloud et partagées non taguées sans toucher à une seule ressource de production.
Exemple de Code : Normaliser les Dépenses Multi-Cloud en FOCUS 1.0 avec SQL
Voici un modèle SQL analytique de niveau production montrant comment les enregistrements bruts AWS CUR 2.0 et GCP Billing sont transformés en une vue FOCUS 1.0 unifiée avec amortissement effectif des engagements :
-- Unified FOCUS 1.0 Cost Normalization View (AWS CUR 2.0 + GCP BigQuery Export)
WITH normalized_focus_ledger AS (
-- 1. AWS CUR 2.0 Normalization
SELECT
DATE_TRUNC('day', line_item_usage_start_date) AS charge_period_start,
'aws' AS provider_name,
line_item_usage_account_id AS sub_account_id,
product_servicecode AS service_name,
product_region_code AS region_id,
line_item_resource_id AS resource_id,
CASE
WHEN line_item_line_item_type IN ('DiscountedUsage', 'SavingsPlanCoveredUsage', 'Usage') THEN 'Usage'
WHEN line_item_line_item_type IN ('Fee', 'RIFee', 'SavingsPlanRecurringFee') THEN 'Purchase'
WHEN line_item_line_item_type = 'Tax' THEN 'Tax'
WHEN line_item_line_item_type = 'Credit' THEN 'Credit'
ELSE 'Adjustment'
END AS charge_category,
CAST(line_item_unblended_cost AS NUMERIC(18, 6)) AS billed_cost,
CAST(
CASE
WHEN line_item_line_item_type = 'SavingsPlanCoveredUsage'
THEN savings_plan_savings_plan_effective_cost
WHEN line_item_line_item_type = 'DiscountedUsage'
THEN reservation_effective_cost
WHEN line_item_line_item_type IN ('SavingsPlanRecurringFee', 'SavingsPlanUpfrontFee', 'RIFee')
THEN COALESCE( reservation_unused_amortized_upfront_fee_for_billing_period
+ reservation_unused_recurring_fee, 0 )
ELSE line_item_unblended_cost
END AS NUMERIC(18, 6)
) AS effective_cost,
CAST(pricing_public_on_demand_cost AS NUMERIC(18, 6)) AS list_cost,
COALESCE(savings_plan_savings_plan_a_r_n, reservation_reservation_a_r_n) AS commitment_discount_id,
resource_tags AS tags
FROM raw_aws_cur_v2
WHERE line_item_usage_start_date >= CURRENT_DATE - INTERVAL '30 days'
UNION ALL
-- 2. GCP Billing Export Normalization
SELECT
DATE_TRUNC('day', usage_start_time) AS charge_period_start,
'gcp' AS provider_name,
project.id AS sub_account_id,
service.description AS service_name,
location.region AS region_id,
resource.global_name AS resource_id,
CASE
WHEN cost_type = 'tax' THEN 'Tax'
WHEN cost_type = 'adjustment' THEN 'Adjustment'
ELSE 'Usage'
END AS charge_category,
CAST(cost AS NUMERIC(18, 6)) AS billed_cost,
CAST(cost + COALESCE(credits_sum.total_credit, 0) AS NUMERIC(18, 6)) AS effective_cost,
CAST(cost_at_list AS NUMERIC(18, 6)) AS list_cost,
credits_sum.commitment_id AS commitment_discount_id,
labels_jsonb AS tags
FROM raw_gcp_billing_export
LEFT JOIN LATERAL (
SELECT
SUM(c.amount) AS total_credit,
MAX(CASE WHEN c.type IN ('COMMITTED_USAGE_DISCOUNT', 'COMMITTED_USAGE_DISCOUNT_DOLLAR_BASE') THEN c.id END) AS commitment_id
FROM UNNEST(credits) AS c
) credits_sum ON TRUE
WHERE usage_start_time >= CURRENT_DATE - INTERVAL '30 days'
)
SELECT
provider_name,
service_name,
SUM(billed_cost) AS total_billed_cost,
SUM(effective_cost) AS total_effective_cost,
SUM(list_cost - effective_cost) AS commitment_and_negotiated_savings,
ROUND(
100.0 * (1.0 - NULLIF(SUM(effective_cost), 0) / NULLIF(SUM(list_cost), 0)),
2
) AS effective_savings_rate_pct
FROM normalized_focus_ledger
WHERE charge_category = 'Usage'
GROUP BY provider_name, service_name
ORDER BY total_effective_cost DESC;Intégrer Kubernetes (OpenCost) et la Télémétrie des Jetons IA
Les exports de facturation cloud vous indiquent qu'un nœud EKS m6i.4xlarge ou un pool de nœuds Azure AKS a coûté 420 $ la semaine dernière, mais ils ne vous disent pas quel microservice ou quel client a consommé ces cycles CPU et mémoire.
Pour boucler la boucle :
- Allocation des Coûts Kubernetes via OpenCost : Collectez les réservations et la consommation réelle de CPU, RAM, GPU et PersistentVolume au niveau des pods et pondérez-les par rapport à l'
EffectiveCostdu nœud dans le grand livre FOCUS (afin que les remises Savings Plans et Spot soient répercutées proportionnellement sur les namespaces). - Attribution des Dépenses IA et LLM : Ingérez les API d'utilisation et de coûts d'OpenAI et d'Anthropic aux côtés de Snowflake et Datadog, en associant les clés API ou identifiants d'espace de travail aux mêmes dimensions de Tags Virtuels (
environment,team,product,tenant).
Transformer la Visibilité en Économies Exécutées par des Ingénieurs
Les tableaux de bord seuls ne réduisent pas votre facture cloud. Même lorsqu'un outil FinOps signale des volumes EBS orphelins, des instances RDS surdimensionnées, des clusters hors production inactifs ou des Savings Plans arrivant à expiration, les équipes plateforme internes sont souvent trop sollicitées par la livraison des fonctionnalités produit pour appliquer les correctifs.
Avec CostGlass, vous connectez un accès en lecture seule sur AWS, Azure, Google Cloud, OCI, Alibaba Cloud, DigitalOcean, Linode, Cloudflare, Kubernetes, OpenAI, Anthropic, Snowflake et Datadog en quelques minutes :
- Analytique FOCUS 1.0 Unifiée et Tags Virtuels : Explorez 13 mois d'historique dans le Cost Explorer, l'économie unitaire et les alertes d'anomalies envoyées directement sur Slack et par e-mail.
- Tarification Forfaitaire et Prévisible : Ne payez jamais un pourcentage de vos dépenses cloud.
- Exécution d'Ingénierie Clé en Main : Sur nos forfaits Scale et Enterprise, les ingénieurs CostGlass exécutent les optimisations que vous approuvez — de la planification hors heures ouvrées et du tiering de stockage au rightsizing et à la gestion des engagements — avec vérification avant/après dans votre registre d'économies.
Prêt à visualiser vos dépenses multi-cloud, Kubernetes et IA dans une vue FOCUS 1.0 unique ? Commencez gratuitement sur CostGlass ou explorez notre documentation technique.
Ready to unify your multi-cloud costs?
See your AWS, Azure, GCP, and Kubernetes spend in canonical FOCUS 1.0 in under 15 minutes.
Plus d’articles
Tout voir →
