Modèles de coûts FinOps : ce que facturent AWS, Azure et GCP — et ce que VCF calcule

La direction financière pose la question en une phrase : « est-ce que ça nous coûterait moins cher chez un hyperscaler ? ». Vous avez de quoi y répondre — une allocation par namespace sur vks-fret-01, et un écart connu entre capacité réservée et capacité consommée. Sauf que la question compare un tarif à un calcul, et que le tableau à deux colonnes qu’on attend de vous est faux avant d’être rempli.

Cet article établit ce que facture réellement chaque plateforme — Amazon EKS, Azure AKS, Google GKE — puis ce que VCF Operations calcule à la place. Il pose les quatre hypothèses sans lesquelles aucune comparaison n’existe, publie la formule avec ses variables, et montre laquelle décide du résultat. Il ne publie aucun montant, et c’est un choix, pas une lacune.

TL;DR

• La décision : ne produisez pas un chiffre de comparaison, produisez un intervalle accompagné de sa fiche d’hypothèses. Trois des quatre plateformes publient un prix sans méthode ; la quatrième publie une méthode sans prix. Ce ne sont pas deux niveaux de transparence, ce sont deux natures de chiffre.
• L’arbitrage qui coûte : établir l’unité facturée de chaque plateforme prend une demi-journée de lecture de documentation, et le résultat vous interdit le tableau à quatre colonnes que tout le monde attend.
• Lundi matin : relevez la valeur configurée d’Expected CPU Utilization dans VCF Operations. Ce paramètre est au dénominateur des taux de base publiés par l’éditeur — c’est lui qui décide du coût unitaire privé, et probablement personne ne sait quelle valeur y est câblée.

Le contrat de chiffre de cet article

Cette section s’adresse à vous, pas au rédacteur : un article de coût se lit différemment selon ce qu’il s’autorise à chiffrer. Il publie des structures de facturation citées mot pour mot, des durées, des dates et des SLA publiés, les formules de Broadcom telles quelles, des formules posées par l’article et étiquetées comme reconstitutions avec leurs variables visibles, des noms de champs d’API et de colonnes FOCUS.

Il refuse tout montant en toute devise, tout pourcentage d’économie — y compris ceux publiés par AWS et Microsoft sur leurs propres pages —, tout montant d’illustration même annoncé comme fictif, toute colonne alignant des montants de plateformes différentes, et toute conclusion désignant une plateforme comme la moins chère.

Ce refus est contre-intuitif, donc il se justifie. Le 2026-08-16, la page tarifaire publique d’Amazon EKS a bien rendu ses montants — mais elle ne nomme aucune région, n’affiche aucune date d’effet et ne porte aucune réserve de variation régionale. Un montant sans région ni date n’est pas un prix, c’est un souvenir. La règle ne dit donc pas « la page ne charge pas », elle dit « la page ne suffit pas ».

Si votre dossier a besoin d’un montant, relevez-le par API et publiez-le sous cette forme : <montant> <devise> / <unité> — <région>, tarif public à la demande relevé le <AAAA-MM-JJ> via <API nommée>, hors remise contractuelle. Un montant qui n’a pas les quatre est supprimé, pas corrigé. Enfin, pour être franc sur les limites de ce texte : aucun lab n’a été exécuté, aucune facture n’a été lue.

Ce que facture chaque plateforme

On établit l’objet facturé, ensuite seulement on se demande s’il est comparable à un autre.

Amazon EKS — un cluster-heure indexé sur le calendrier

La documentation publie la structure en une phrase : « Amazon EKS has per cluster pricing based on Kubernetes cluster version support, pricing for Amazon EKS Auto Mode, and per vCPU pricing for Amazon EKS Hybrid Nodes. » Puis celle qui compte pour un modèle : « When using Amazon EKS, you pay separately for the AWS resources you use to run your applications on Kubernetes worker nodes. » L’exemple publié nomme trois services pour une seule ligne de charge — EC2, EBS, adresse IPv4 VPC. Attention, la phrase de structure n’est pas exhaustive : la liste de liens de la même page et la page tarifaire nomment un quatrième axe, Amazon EKS Capabilities.

Le point le plus intéressant du modèle EKS est structurel, pas monétaire : le tarif du cluster dépend de l’âge de sa version de Kubernetes. Support standard pendant 14 mois après la sortie, puis support étendu pendant 12 mois « at an additional cost per cluster hour », activé par défaut sur les clusters neufs comme existants. La bascule a une date publiée à l’avance, avec son fuseau : « Billing for extended support starts at the beginning of the day that the version reaches end of standard support, in the UTC+0 timezone. » Autrement dit, une ligne de facture change parce que le temps passe, sans que personne n’ait rien déployé.

Version	Sortie amont	Sortie EKS	Fin support standard EKS	Fin support étendu EKS
1.36	2026-04-22	2026-06-02	2027-08-02	2028-08-02
1.35	2025-12-17	2026-01-27	2027-03-27	2028-03-27
1.34	2025-08-27	2025-10-02	2026-12-02	2027-12-02

Notez l’écart : kubernetes.io donne la fin de vie de 1.35 au 2027-02-28, EKS la fin de support standard au 2027-03-27. Le cycle de vie d’un fournisseur managé n’est pas le cycle de vie amont — et c’est un poste d’hypothèse à part entière.

Azure AKS — un palier de gestion, pas une ressource

AKS facture trois paliers de gestion de cluster, et la description du palier gratuit dit exactement ce qui est gratuit : « Free cluster management. Pay as you go for consumed resources. »

Palier	Ce qui est publié	Nœuds	SLA
Free	« Includes all current AKS features. […] No financially backed uptime SLA. »	≤ 1 000	best-effort
Standard	« Uptime SLA enabled by default. Higher reliability profile. »	≤ 5 000	99,95 % avec zones, 99,9 % sans
Premium	Maintenance Microsoft au-delà du support communautaire, support long terme 24 mois	≤ 5 000	99,95 % avec zones, 99,9 % sans

Ce qu’on achète en montant de palier n’est donc pas du calcul : c’est un engagement de disponibilité et une durée de support. Les ressources consommées restent facturées à part dans les trois paliers.

Google GKE — deux modèles de facturation dans le même cluster

La facturation par pod couvre « Pods that run on the container-optimized compute platform in Autopilot clusters or Standard clusters » ainsi que « Pods that select the Balanced or Scale-Out built-in ComputeClasses in Autopilot clusters ». La facturation par nœud couvre le reste : « Pods that select specific hardware, such as Compute Engine machine series or hardware accelerators, use a node-based billing model. In this model, you pay for the underlying hardware and a node management premium. »

Conséquence lourde : deux pods du même cluster peuvent relever de deux unités facturées différentes, selon ce que demande leur spécification. L’unité de coût est une propriété du pod, pas du cluster — un modèle GKE qui raisonne « par nœud » est faux pour une partie des charges. Trou assumé : la page tarifaire GKE est restée tronquée au chargement, deux fois. Ni la prime de gestion de nœud, ni un comparatif Autopilot / Standard n’ont pu être établis ; cet article n’en construit aucun.

VCF — il ne facture pas, il calcule

Dix cost drivers sont publiés pour le type d’infrastructure vCenter : Server Hardware: Traditional, Server Hardware: Hyper-Converged, Storage, License, Applications, Maintenance, Labor, Network, Facilities, Additional Cost. La mécanique tient en une phrase : « The total cost set by you is distributed across resources in the data center. » Trois de ces drivers n’ont aucun équivalent dans le prix d’une instance publique — Labor, Facilities, Network. Ils reviendront comme quatrième hypothèse.

La chaîne de calcul VCF, étage par étage

Étage 1 — l’entrée est un montant saisi, celui des dix cost drivers, puis distribué sur les objets du datacenter.

Étage 2 — le matériel s’amortit, avec une formule publiée : « Yearly straight line depreciation = [(original cost - accumulated depreciation) / number of remaining depreciation years] ». Deux méthodes sont proposées, Straight Line et Max of Double or Straight, « you can set the depreciation period from two to five years », et « The default discount % value is zero. »

Étage 3 — le taux de base, avec le taux d’occupation au dénominateur : « Per GHz CPU base rate = (Cluster Total CPU Cost) / (Expected CPU Utilization * Cluster CPU Capacity in gHZ) », et son équivalent mémoire. L’origine des pourcentages attendus est publiée — « These percentages are arrived based on historical actual use of clusters » — de même que leur périodicité : « The base rates are monthly rates. »

Étage 4 — l’agrégation vers Kubernetes : « VCF Operations calculates the cost for VKS cluster, supervisor cluster, and Kubernetes node, by aggregating the cost of the supporting VMs. » Le coût Kubernetes de VCF Operations est donc un coût d’infrastructure remonté, pas un coût de consommation descendu : l’inverse exact du chemin d’OpenCost, décrit dans OpenCost : voir avant d’agir sur les coûts K8s. Les deux produisent un chiffre par objet Kubernetes ; ils ne le fabriquent pas dans le même sens.

Les notes de version 9.1 ajoutent un costing « across your entire Kubernetes ecosystem, including nodes, clusters, vSphere namespaces, projects, and organizations » et un chargeback « specifically for VMware Kubernetes Service (VKS) nodes in addition to the traditional VM pricing ».

Le tableau licite : des propriétés, pas des montants

Les colonnes sont des plateformes, mais les lignes sont des propriétés du modèle. C’est ce qui rend le tableau défendable — et pourquoi il n’a aucune ligne de prix.

	Amazon EKS	Azure AKS	Google GKE	VCF / VCF Operations
Objet facturé	le cluster, à l’heure	le palier de gestion	le pod ou le nœud, selon le pod	non facturé — coût saisi puis distribué
Déclencheur du montant	existence du cluster + âge de sa version	le choix de palier	la spécification du pod	l’écriture des cost drivers
Ce qui est inclus	plan de contrôle géré ; trafic côté plan de contrôle absorbé	fonctionnalités complètes dans les 3 paliers ; SLA dès Standard	matériel + prime de gestion en modèle nœud	rien — tout est un driver
Facturé à part	EC2, EBS, IPv4 VPC, trafic côté client, Auto Mode, Hybrid Nodes, Capabilities	toutes les ressources consommées	selon le modèle applicable au pod	sans objet
Qui fixe le montant	le fournisseur	le fournisseur	le fournisseur	l’exploitant
Ce dont il dépend	région, version, durée	palier, région	modèle applicable, matériel	amortissement, occupation attendue, ratio de coût
Granularité publiée	ressource facturée	ressource facturée	pod (modèle pod)	nœud / vSphere namespace
Méthode publiée	non — un tarif, pas une formule	non	non	oui — taux de base et agrégation

La dernière ligne inverse l’intuition. Les hyperscalers publient un prix sans méthode ; VCF publie une méthode sans prix. Un prix n’a pas besoin de méthode : il est opposable, c’est ce qui sera facturé. Une méthode sans prix ne l’est pas — elle ne devient un chiffre qu’une fois qu’on y a versé ses propres montants. D’où la non-commensurabilité en une phrase : un chiffre EKS est le résultat d’un contrat, un chiffre VCF le résultat d’un calcul dont l’exploitant fournit les entrées. Les mettre côte à côte sans le dire, c’est comparer un relevé bancaire à un budget.

Le seul pont honnête : engagement contre amortissement

Les trois hyperscalers publient un mécanisme d’engagement. AWS : « Savings Plans provide savings beyond On-Demand rates in exchange for a commitment of using a specified amount of compute power (measured per hour) for a one or three year period », avec un tarif verrouillé sur la durée. Azure applique automatiquement la remise selon le SKU, la région et la portée. GCP engage sur un montant horaire minimal ou sur une quantité de ressources éligibles, et publie la clause qui définit le risque : « Any overage usage that takes your hourly spend amount over your committed amount is charged at the on-demand rate. »

Un engagement pluriannuel n’est pas une remise : c’est un transfert de risque contre une baisse de tarif, exactement la structure d’un achat de matériel amorti sur deux à cinq ans. La seule comparaison naturellement commensurable n’est donc pas « à la demande contre privé », c’est engagement contre amortissement — avec la même pénalité en cas de mauvaise prévision : l’engagement non consommé d’un côté, le taux d’occupation qui ne monte pas de l’autre.

Les quatre hypothèses, la formule, la sensibilité

Ces hypothèses ne sont pas un cadre académique plaqué sur un produit : deux d’entre elles sont des paramètres publiés de VCF Operations, donc contestables sur pièce plutôt que sur avis.

# fiche d'hypothèses — ⚠️ ce bloc n'est PAS un manifeste Kubernetes : ni apiVersion, ni kind.
# Il accompagne tout chiffre sorti du modèle. Un chiffre sans sa fiche est retiré, pas corrigé.
hypotheses:
  - id: H1
    nom: "durée d'amortissement du matériel"
    variable: REPLACE_WITH_DEPRECIATION_YEARS
    borne_publiee: "2 à 5 ans — Cost Settings for Financial Accounting Model"
    methode_publiee: "Straight Line | Max of Double or Straight"
    porte_sur: "la part matérielle seule ; licence, maintenance, main-d'oeuvre, immobilier restent récurrents"
  - id: H2
    nom: "taux d'occupation attendu de la plateforme privée"
    variable: REPLACE_WITH_UTILIZATION_RATE
    statut_publie: "Expected CPU/Memory Utilization est au DÉNOMINATEUR des taux de base publiés"
    note: "le coût unitaire privé varie en 1/H2 ; le tarif public ne varie pas avec H2"
  - id: H3
    nom: "durée de vie et profil de charge"
    variable: REPLACE_WITH_WORKLOAD_PROFILE
    valeurs: [permanent, elastique, saisonnier, projet_borne]
    note: "permanent → engagement vs amortissement ; élastique → tarif à la demande vs capacité déjà achetée"
  - id: H4
    nom: "périmètre de coût retenu de chaque côté"
    variable: REPLACE_WITH_SCOPE
    liste_privee: "les dix cost drivers, dont Labor, Facilities et Network"
    liste_publique: "ce qu'une réservation ne couvre pas ; ce qu'EKS facture à part"
    regle: "un poste présent d'un côté et absent de l'autre est ajouté des deux côtés, ou retiré des deux"

La formule qui suit est une reconstitution : elle enchaîne des pages officielles, elle n’est publiée telle quelle nulle part, et aucune de ses variantes ne produit un résultat publiable. Elle produit un intervalle, accompagné de sa fiche.

# côté public — coût unitaire d'un vCPU-heure sur un cluster managé
COUT_UNITAIRE_PUBLIC_VCPU_HEURE =
    (   REPLACE_WITH_NODE_HOURLY_RATE
      + REPLACE_WITH_CLUSTER_HOURLY_FEE / REPLACE_WITH_NODES_PER_CLUSTER
      + REPLACE_WITH_ATTACHED_STORAGE_HOURLY
      + REPLACE_WITH_DATA_TRANSFER_HOURLY
      + REPLACE_WITH_MANAGED_ADDONS_HOURLY )
    / REPLACE_WITH_NODE_VCPU_COUNT
# ∀ terme ! provenir d'un relevé daté, sur REPLACE_WITH_REGION, à REPLACE_WITH_LOOKUP_DATE
# REPLACE_WITH_CLUSTER_HOURLY_FEE dépend de la version du cluster (support standard ou étendu)
#   ∴ ce terme change avec le calendrier, pas avec la charge

# côté privé — la chaîne publiée par VCF Operations, réécrite en variables
COUT_COMPUTE_CLUSTER = COUT_INFRA_TOTAL - COUT_STOCKAGE - COUT_VM_DIRECT
AMORTISSEMENT_ANNUEL_LINEAIRE =
    ( REPLACE_WITH_HARDWARE_CAPEX - AMORTISSEMENT_CUMULE ) / ANNEES_RESTANTES
    # ANNEES_RESTANTES borné par REPLACE_WITH_DEPRECIATION_YEARS ∈ [2..5]
TAUX_BASE_CPU_PAR_GHZ = COUT_CPU_CLUSTER / ( REPLACE_WITH_UTILIZATION_RATE * CAPACITE_CPU_GHZ )
TAUX_BASE_RAM_PAR_GO  = COUT_RAM_CLUSTER / ( REPLACE_WITH_UTILIZATION_RATE_MEM * CAPACITE_RAM_GO )
COUT_NOEUD_VKS   = SOMME( cout des VM support du noeud )
COUT_CLUSTER_VKS = SOMME( COUT_NOEUD_VKS )
# ⚠️ la chaîne publiée s'arrête ici : ni pod, ni conteneur

# le point de bascule est un TAUX, pas une économie
TAUX_OCCUPATION_DE_BASCULE =
    COUT_UNITAIRE_PRIVE_A_OCCUPATION_100 / COUT_UNITAIRE_PUBLIC_VCPU_HEURE

Sans un seul montant, ces formules donnent un sens de variation, et il est décisif. La courbe privée en fonction de l’occupation est une hyperbole : le coût unitaire varie en 1/H2. La droite publique est horizontale — le tarif d’une instance ne change pas parce que votre cluster est à moitié vide. Un cluster privé sous-occupé n’est donc pas « un peu plus cher » : il est d’autant plus cher que l’occupation est faible, sans plancher. C’est ce que le rightsizing avec VPA et KRR rend mesurable : la capacité réservée et jamais consommée dégrade H2.

La sensibilité à H1 est décroissante mais plafonnée : H1 ne porte que sur la part matérielle, et licence, maintenance, main-d’œuvre et immobilier sont récurrents. Un modèle qui ne devient favorable au privé qu’en allongeant l’amortissement repousse une décision, il ne la justifie pas. Ces deux courbes ne sont pas des mesures : ce sont les formes imposées par les formules publiées. On peut connaître le sens de variation d’un modèle sans connaître un seul de ses montants.

Relever soi-même : les trois APIs et le vocabulaire FOCUS

Deux valeurs se fixent d’abord et ne bougent plus : REPLACE_WITH_REGION et REPLACE_WITH_LOOKUP_DATE. Une comparaison porte une région et une date, comme une facture porte un mois.

# AWS — Price List Query API, action GetProducts ; requête signée SigV4 ∴ compte AWS requis
aws pricing get-products \
  --service-code AmazonEC2 --format-version aws_v1 --max-results 100 \
  --filters \
      Type=TERM_MATCH,Field=instanceType,Value=REPLACE_WITH_INSTANCE_TYPE \
      Type=TERM_MATCH,Field=operatingSystem,Value=REPLACE_WITH_OS \
      Type=TERM_MATCH,Field=tenancy,Value=Shared
# conserver : terms.OnDemand[].priceDimensions[].pricePerUnit, unit, description,
#   effectiveDate, publicationDate, et l'attribut produit location qui porte la région en clair
# ⚠️ aucun nom de champ de filtre régional n'est publié : lire la région dans les attributs,
#   ⊥ inventer un nom de champ plausible

# Azure — Retail Prices API, non authentifiée
curl -s -G "https://prices.azure.com/api/retail/prices" \
  --data-urlencode "api-version=2023-01-01-preview" \
  --data-urlencode "\$filter=serviceName eq 'Virtual Machines' \
      and armRegionName eq 'REPLACE_WITH_REGION' \
      and armSkuName eq 'REPLACE_WITH_INSTANCE_TYPE' \
      and priceType eq 'Consumption'"
# casse sensible depuis 2023-01-01-preview ; 1 000 enregistrements max par page + NextPageLink ;
#   les tarifs d'engagement ne sortent que sur cette préversion

# GCP — Cloud Billing Catalog API, services.skus.list
curl -s "https://cloudbilling.googleapis.com/v1/services/REPLACE_WITH_SERVICE_ID/skus?currencyCode=REPLACE_WITH_CURRENCY" \
  -H "Authorization: Bearer REPLACE_WITH_ACCESS_TOKEN"
# filtrer côté client sur serviceRegions[] == REPLACE_WITH_REGION
# tarif = tieredRates[].unitPrice.units + tieredRates[].unitPrice.nanos / 1e9
# startTime/endTime bornés à un même mois calendaire

Microsoft publie une réserve de devise qu’il faut relayer : « The currency that Microsoft uses to price all Azure services is USD. […] Other non-USD prices returned by the API are for your reference to help you estimate budget expenses. » Un montant sorti de cette API dans une autre devise est une estimation de conversion, pas un tarif.

Reste à dire de quel coût on parle, et FOCUS donne les mots exacts. La spécification 1.4, ratifiée le 2026-06-04, publie : « BilledCost represents the cash-based view […]. EffectiveCost represents the accrual-based view: costs recognized when resources are consumed, services are used, or contract commitments are recognized. ListCost provides the pre-discount baseline. ContractedCost reflects pricing after negotiated discounts. »

Chiffre	Colonne FOCUS	Où on le rencontre
ce qu’OpenCost affiche par défaut — « the on-demand list pricing »	ListCost	article 1
ce que produit la réconciliation avec la facture négociée	ContractedCost, puis EffectiveCost	article 1, palier commercial
ce que vous voyez sur votre facture	BilledCost	cet article
ce qu’un engagement change	colonnes CommitmentDiscount*	cet article

Deux précisions honnêtes sur FOCUS et VCF. Le fait d’abord : un billet du blog VCF de Broadcom, daté du 2026-06-03, annonce « we are aligning VCF 9.1 with the FinOps Open Cost & Usage Specification (FOCUS) » — mais aucune page de documentation produit chargée ne le confirme, aucune version de FOCUS n’y est nommée, et la page d’adoption fournisseurs du site FOCUS n’a rendu aucune liste. On n’écrit donc ni « VCF est conforme FOCUS », ni « VCF ne produit pas de jeu FOCUS » : on écrit l’annonce datée et l’absence de confirmation.

La limite de fond ensuite, qui survivra à n’importe quelle mise à jour produit : FOCUS normalise le schéma, pas la nature du chiffre. Un export FOCUS parfaitement conforme d’un coût VCF porterait une colonne BilledCost — mais personne n’a facturé ce montant : il a été saisi en cost drivers, puis distribué. Les colonnes seraient identiques, le sens ne le serait pas.

Pièges & points de vigilance

• Le montant d’exemple d’une documentation d’API. Les exemples de réponse contiennent de vrais montants, périmés par construction : GetProducts porte une effectiveDate de 2017, les exemples Azure des effectiveStartDate de 2019 à 2021.
• Le pourcentage d’économie du fournisseur. AWS et Microsoft publient chacun un plafond d’économie sur leurs pages d’engagement. Ces chiffres comparent un tarif d’engagement au tarif à la demande du même fournisseur, sur une charge permanente : ce n’est pas un gain contre votre état actuel. Un gain se raconte en mécanisme — un nœud retiré, une capacité non achetée — jamais en pourcentage.
• Comparer un tarif remisé d’un côté et un tarif public de l’autre. Un ListCost public en face d’un coût privé qui contient des remises réelles sur le matériel et la licence mesure surtout votre position de négociation. Comparez la même colonne FOCUS des deux côtés, et dites laquelle.
• Le périmètre asymétrique. VCF expose Labor, Facilities et Network ; une réservation Azure « doesn’t cover additional software, Windows, networking, or storage charges ». Les dix drivers d’un côté et un tarif d’instance de l’autre, c’est un coût complet contre un coût partiel — aussi faux que son symétrique.
• Attribuer à VCF une granularité qu’il ne publie pas. La chaîne s’arrête au nœud et au vSphere namespace, et la méthode publiée est une agrégation de VM support, pas une allocation par consommation. Symétriquement, n’écrivez pas « VCF ne voit rien côté Kubernetes » : c’est faux depuis 9.1.
• Le taux d’occupation câblé que personne n’a choisi. Les pourcentages attendus « are arrived based on historical actual use of clusters », mais la documentation ne dit ni qui les fixe, ni sur quelle fenêtre, ni s’ils sont modifiables. Relevez la valeur configurée ; n’inférez pas une fenêtre.
• Le modèle qui reste juste et devient périmé. Un tarif change sans préavis, une version bascule en support étendu, un amortissement arrive à son terme — le modèle ne signale rien, il continue de calculer. D’où la date de péremption inscrite dans la fiche.

Conclusion

La question posée n’a pas de réponse unique, et le dire est un résultat, pas un aveu d’échec. Ce que vous rendez à la direction financière, ce ne sont pas deux colonnes : ce sont trois questions en retour — sur quelle durée amortissons-nous, à quel taux d’occupation tournons-nous, et avons-nous mis les mêmes postes des deux côtés ? Une organisation qui sait répondre à ces trois-là sait fabriquer son chiffre, et le défendre.

La boucle se referme sur le début de la série pour une raison mécanique : le taux d’occupation qui décide de la comparaison est exactement la grandeur que l’allocation par namespace rend lisible et que le rightsizing fait bouger. La comparaison multi-cloud n’est pas l’étape d’après la mesure — c’est la mesure qui la conditionne.