Comprendre le nouveau modèle CUD basé sur la dépense de Google Cloud

Vous est-il déjà arrivé de calculer vos économies CUD en jonglant entre coûts à la demande, frais d'engagement et compensations par crédits ? C'est précisément ainsi que fonctionnait l'ancien système CUD basé sur la dépense de Google. Vous vous engagiez par exemple sur 100 $/heure de dépense à la demande, payiez des frais d'engagement de 54 $/heure (avec une remise de 46 %), puis receviez un crédit de -100 $ qui compensait vos frais d'utilisation. Le calcul tombait juste, mais l'expliquer aux clients ou au service financier relevait du cauchemar.

Le nouveau modèle multiprice balaie cette complexité. Au lieu de crédits, Google applique désormais votre remise directement sur le prix des SKU, via ce que l'on appelle des consumption models. Vous vous engagez sur votre dépense remisée réelle (54 $/heure), vous payez ce montant, et votre utilisation apparaît au tarif remisé. Plus de crédits séparés, fini la gymnastique mentale.

Ce changement modifie aussi en profondeur la manière dont les données CUD apparaissent dans les exports BigQuery, ce qui impose de mettre à jour les dashboards FinOps maison ou les systèmes d'allocation de coûts que vous avez développés. Chez DoiT, nous sommes passés par là.

La migration introduit trois changements majeurs à bien comprendre :

Premièrement, la logique de calcul des engagements est inversée. Auparavant, vous vous engagiez sur la base d'une dépense équivalente à la demande. Désormais, vous vous engagez sur votre coût horaire remisé réel. Un engagement couvrant 185 $ d'utilisation à la demande avec 46 % de remise était décrit comme un engagement de 185 $/heure. Dans le nouveau modèle, ce même engagement devient un engagement de 100 $/heure, soit le montant que vous payez réellement. L'outil CUD Recommendations a été mis à jour en conséquence. Si vous avez des scripts d'automatisation qui calculent les montants d'engagement, ils devront être révisés.

Deuxièmement, le schéma BigQuery s'enrichit de nouveaux champs. L'ajout le plus marquant est la struct consumption_model, qui contient un champ id et un champ description. Lorsque l'utilisation est couverte par un Compute Flexible CUD de 3 ans, la description indique Compute Flexible CUDs 3 Year au lieu d'apparaître sur une ligne de crédit séparée. Google a également ajouté les champs price.list_price, price.effective_price_default et cost_at_list_consumption_model pour aider à différencier le tarif à la demande du tarif remisé dans vos requêtes.

Troisièmement, les SKU de frais sont restructurés. Les nouveaux SKU de frais CUD sont facturés à 1 $/heure avec un type de crédit compensatoire appelé FEE_UTILIZATION_OFFSET. Lorsque votre CUD est pleinement utilisé, le frais et la compensation s'annulent. En cas de sous-utilisation, la portion non consommée apparaît comme un coût. Cela génère deux lignes par CUD dans vos données de facturation : une pour l'utilisation couverte au tarif remisé, et une pour tout dépassement au tarif à la demande.

FEE_UTILIZATION_OFFSET

Les Compute Flexible CUDs couvrent désormais des workloads qui exigeaient auparavant des types d'engagement distincts, ou qui n'avaient tout simplement aucune voie de remise.

Les VM optimisées pour la mémoire entrent enfin dans le périmètre des Flex CUD. Les familles de machines M1, M2, M3 et M4 peuvent désormais être couvertes par des Compute Flexible CUDs, mais uniquement sur des durées de 3 ans avec une remise de 63 %. Attention au piège : les engagements d'1 an n'offrent aucune remise pour les VM optimisées pour la mémoire. Votre dépense consommera l'engagement non utilisé sans le moindre bénéfice en termes d'économies. Si vous exécutez des workloads gourmands en mémoire comme SAP HANA ou de grandes bases de données in-memory, les engagements de 3 ans deviennent nettement plus attractifs.

Les familles HPC entrent dans la danse. Les familles compute-optimized H3 et la nouvelle H4D sont désormais éligibles aux Flex CUD avec 17 % sur 1 an et 38 % sur 3 ans. La H4D, actuellement en preview, embarque des processeurs AMD EPYC Turin de 5e génération avec 192 cœurs, jusqu'à 1 488 Go de mémoire et un réseau RDMA à 200 Gbps. Du sérieux, pour des workloads de calcul intensif.

Cloud Run bénéficie d'une couverture complète. La facturation à la requête pour les services Cloud Run (y compris les Cloud Run functions, anciennement Cloud Functions) est désormais éligible aux Compute Flexible CUDs à 17 %, aussi bien sur 1 an que sur 3 ans. La facturation à l'instance, les jobs et les worker pools continuent de bénéficier des remises de 28 %/46 %. Si vous exécutez des workloads serverless à grande échelle, l'impact sur votre unit economics peut être significatif.

Le tableau suivant résume la nouvelle structure de remise basée sur la dépense :

Après la migration, la colonne Savings de votre dashboard FinOps affichera des chiffres bien plus faibles. Là où elle indiquait -10,00 $, elle peut désormais afficher -4,50 $. De quoi déclencher la sonnette d'alarme, jusqu'à ce que l'on saisisse ce qui se passe.

L'ancien modèle affichait un crédit brut qui compensait l'intégralité de votre coût à la demande. Le nouveau modèle affiche vos économies nettes réelles : la différence entre ce que vous auriez payé au tarif à la demande et ce que vous avez effectivement payé au tarif remisé. Le montant final de votre facture et les économies réelles sont identiques dans les deux cas. Seule la présentation a changé.

Aucun de ces changements n'affecte vos taux de remise réels. Un Compute Flexible CUD de 3 ans vous fait toujours économiser 46 % sur le compute général. Un engagement d'1 an reste à 28 %. Les sommes que vous sortez de votre poche sont exactement les mêmes avant et après la migration. Google a modifié la manière dont les économies sont affichées, et non la manière dont elles sont calculées. C'est essentiel à retenir.

Cela suppose aussi de communiquer avec les CFO et autres parties prenantes habitués à voir de gros chiffres de crédits. Lorsqu'ils demanderont pourquoi les crédits CUD ont chuté de 55 %, il faudra leur expliquer qu'ils visualisent désormais des économies réelles plutôt que des compensations comptables.

Mon montant d'engagement va-t-il augmenter si je ne participe pas ?

Non. Lorsque Google vous migre automatiquement, il convertit vos engagements existants en valeurs équivalentes dans le nouveau modèle. Si vous aviez un engagement de 185 $/heure (exprimé en équivalent à la demande), il devient un engagement de 100 $/heure (votre dépense remisée réelle). Même couverture, même coût, étiquetage différent. Votre portefeuille reste exactement le même ; seul le reporting change.

Mes CUD existants couvriront-ils moins après la migration ?

Non, c'est même l'inverse. Tous les CUD existants couvriront au moins ce qu'ils couvraient auparavant, et beaucoup couvriront davantage de SKU grâce à l'éligibilité élargie. Si vous disposez aujourd'hui de Compute Flexible CUDs, ils commenceront automatiquement à couvrir les workloads nouvellement éligibles : facturation à la requête de Cloud Run, instances H3/H4D et VM optimisées pour la mémoire. Vous bénéficiez ainsi d'une meilleure utilisation des engagements déjà achetés, sans la moindre action de votre part.

Alors qu'est-ce qui change réellement ?

L'affichage et la structure des données. Vos pourcentages de remise restent identiques. Vos coûts d'engagement restent identiques. Votre couverture reste la même ou s'améliore. Les changements portent sur :

1. la manière dont les montants d'engagement sont exprimés ;
2. la manière dont les économies apparaissent dans les exports de facturation ;
3. les SKU éligibles à la couverture.

C'est tout.

Il convient de souligner ce que cette migration ne change pas. Les remises sur engagement basées sur les ressources, par lesquelles vous vous engagez sur des quantités précises de vCPU, de mémoire, de GPU ou de Local SSD dans une région et un projet donnés, continuent de fonctionner exactement comme avant. Elles restent idéales pour des workloads prévisibles, en régime stable, avec des besoins en ressources constants.

Les différences clés demeurent :

• Les CUD basés sur les ressources sont liés à un projet et à une région (même s'il est possible d'activer le partage à l'échelle d'un compte de facturation).
• Les Flex CUD basés sur la dépense s'appliquent automatiquement à toute l'utilisation éligible d'un compte de facturation.

Les engagements basés sur les ressources offrent des taux de remise légèrement plus élevés pour le compute général (jusqu'à 55 % sur 3 ans contre 46 % pour les Flex), mais exigent une planification de capacité plus rigoureuse.

Ce que je recommande systématiquement à la plupart des organisations, c'est de combiner les deux : des CUD basés sur les ressources pour vos workloads de base, prévisibles, et des Flex CUD pour l'utilisation variable ou distribuée, plus difficile à cerner par région et par type de machine.

Le nouveau modèle CUD multiprice constitue le changement de facturation le plus significatif de Google Cloud depuis des années. La couverture élargie et la structure de données plus lisible sont de belles avancées. À vous maintenant de vous assurer que vos systèmes internes sont prêts à en tirer parti — et si vous souhaitez que DoiT vous accompagne, parlons-en.