Das neue Spend-Based CUD-Modell von Google Cloud verstehen

Kennen Sie das? CUD-Einsparungen ausrechnen, indem Sie On-Demand-Kosten, Commitment-Gebühren und Gutschriften gegeneinander aufrechnen. Genau so funktionierte das alte Spend-Based-CUD-System von Google. Sie haben sich beispielsweise zu 100 $/Stunde On-Demand-Spend verpflichtet, eine Commitment-Gebühr von 54 $/Stunde (bei 46 % Rabatt) gezahlt und dann eine Gutschrift von -100 $ erhalten, die Ihre Nutzungskosten ausglich. Rechnerisch ging das auf, aber gegenüber Kunden oder der Finanzabteilung war es kaum verständlich zu erklären.

Das neue Multiprice-Modell räumt mit dieser Komplexität auf. Statt mit Gutschriften zu arbeiten, wendet Google Ihren Rabatt nun direkt auf die SKU-Preise an – über sogenannte "Consumption Models". Sie verpflichten sich auf Ihren tatsächlich rabattierten Spend (54 $/Stunde), zahlen genau diesen Betrag, und Ihre Nutzung erscheint zum rabattierten Preis. Keine separaten Gutschriften, keine Kopfrechnerei mehr.

Auch in den BigQuery-Exports erscheinen CUD-Daten dadurch grundlegend anders. Eigene FinOps-Dashboards oder Systeme zur Kostenallokation müssen entsprechend angepasst werden. Bei DoiT haben wir genau diesen Prozess durchlaufen.

Mit der Migration kommen drei wesentliche Änderungen, die Sie kennen sollten:

Erstens: Die Commitment-Logik kehrt sich um. Bisher haben Sie sich auf Basis des äquivalenten On-Demand-Spends verpflichtet. Jetzt verpflichten Sie sich auf Ihre tatsächlichen rabattierten Stundenkosten. Ein Commitment, das 185 $ On-Demand-Nutzung bei 46 % Rabatt abdeckte, hieß früher "185 $/Stunde Commitment". Im neuen Modell heißt dasselbe Commitment "100 $/Stunde Commitment" – also der Betrag, den Sie tatsächlich zahlen. Auch das CUD Recommendations Tool wurde entsprechend angepasst. Automatisierungsskripte, die Commitment-Beträge berechnen, müssen Sie überarbeiten.

Zweitens: Das BigQuery-Schema bekommt neue Felder. Die wichtigste Ergänzung ist das consumption_model-Struct mit den Feldern id und description. Wird Nutzung durch ein 3-jähriges Compute Flexible CUD abgedeckt, lautet die Beschreibung "Compute Flexible CUDs 3 Year" – statt als separate Gutschriftszeile zu erscheinen. Außerdem hat Google die Felder price.list_price, price.effective_price_default und cost_at_list_consumption_model ergänzt, damit Sie in Ihren Abfragen zwischen On-Demand- und rabattierten Preisen unterscheiden können.

Drittens: Die Fee-SKUs sind neu strukturiert. Neue CUD-Fee-SKUs sind mit 1 $/Stunde bepreist und werden durch eine Gutschrift vom Typ FEE_UTILIZATION_OFFSET ausgeglichen. Ist Ihr CUD voll ausgelastet, heben sich Gebühr und Offset gegenseitig auf null auf. Bei Unterauslastung erscheint der ungenutzte Anteil als Belastung. Daraus ergeben sich pro CUD zwei Zeilen in Ihren Abrechnungsdaten – eine für die abgedeckte Nutzung zum rabattierten Preis, eine für etwaige Überschreitungen zu On-Demand-Preisen.

FEE_UTILIZATION_OFFSET

Compute Flexible CUDs decken jetzt workloads ab, die bisher separate Commitment-Typen erforderten oder gar keinen Rabattpfad hatten.

Memory-Optimized VMs sind endlich Flex-CUD-fähig. Die Maschinenfamilien M1, M2, M3 und M4 lassen sich nun über Compute Flexible CUDs abdecken – allerdings nur mit 3-Jahres-Laufzeit zu 63 % Rabatt. Wichtiger Haken: 1-Jahres-Commitments bringen für Memory-Optimized VMs keinerlei Rabatt. Ihr Spend baut das ungenutzte Commitment ohne jeden Sparvorteil ab. Wer speicherintensive workloads wie SAP HANA oder große In-Memory-Datenbanken betreibt, sollte 3-Jahres-Commitments daher deutlich genauer prüfen.

HPC-Familien sind jetzt mit dabei. Die Compute-Optimized-Familien H3 und das neue H4D sind nun Flex-CUD-fähig – mit 17 % bei 1-Jahres- und 38 % bei 3-Jahres-Laufzeit. Die derzeit in der Preview befindliche H4D bietet AMD-EPYC-Turin-Prozessoren der 5. Generation mit 192 Kernen, bis zu 1.488 GB Arbeitsspeicher und RDMA-fähiges Netzwerk mit 200 Gbps. Schweres Geschütz für anspruchsvolle Compute-workloads.

Cloud Run wird umfassend abgedeckt. Die request-basierte Abrechnung für Cloud-Run-Dienste (einschließlich Cloud Run Functions, früher Cloud Functions) qualifiziert sich nun für Compute Flexible CUDs zu 17 % – sowohl bei 1- als auch bei 3-Jahres-Laufzeit. Instance-basierte Abrechnung, Jobs und Worker Pools profitieren weiterhin von 28 %/46 % Rabatt. Wer serverlose workloads im großen Maßstab betreibt, kann damit seine Stückkosten spürbar verbessern.

Die folgende Tabelle fasst die neue Spend-Based-Rabattstruktur zusammen:

Nach der Migration zeigt die Spalte "Einsparungen" in Ihrem FinOps-Dashboard deutlich niedrigere Werte. Wo vorher -10,00 $ standen, könnten jetzt -4,50 $ erscheinen. Das schrillt erst einmal alle Alarmglocken – bis man versteht, was tatsächlich passiert.

Das alte Modell zeigte eine Brutto-Gutschrift, die Ihre gesamten On-Demand-Kosten ausglich. Das neue Modell zeigt Ihre tatsächlichen Netto-Einsparungen: die Differenz zwischen dem, was Sie zu On-Demand-Preisen gezahlt hätten, und dem, was Sie tatsächlich zum rabattierten Preis zahlen. Endrechnungsbetrag und reale Einsparungen sind in beiden Fällen identisch. Nur die Darstellung hat sich geändert.

Keine dieser Änderungen wirkt sich auf Ihre tatsächlichen Rabattsätze aus. Ein 3-jähriges Compute Flexible CUD spart Ihnen weiterhin 46 % auf General Compute. Ein 1-Jahres-CUD weiterhin 28 %. Was Sie unterm Strich zahlen, ist vor und nach der Migration exakt gleich. Google hat geändert, wie Einsparungen dargestellt werden – nicht, wie sie berechnet werden. Das ist ein wichtiger Punkt.

Daraus ergibt sich auch Kommunikationsbedarf gegenüber CFOs und Stakeholdern, die sich an die hohen Gutschriftsbeträge gewöhnt haben. Wenn die Frage kommt, warum die CUD-Gutschriften um 55 % gefallen sind, müssen Sie erklären, dass jetzt die tatsächlichen Einsparungen sichtbar werden – und nicht mehr buchhalterische Verrechnungen.

Erhöht sich mein Commitment-Betrag, wenn ich nicht zustimme?

Nein. Bei der automatischen Migration rechnet Google Ihre bestehenden Commitments in äquivalente Werte des neuen Modells um. Aus einem 185 $/Stunde-Commitment (ausgedrückt als On-Demand-Äquivalent) wird ein 100 $/Stunde-Commitment (Ihr tatsächlich rabattierter Spend). Gleiche Abdeckung, gleiche Kosten, andere Bezeichnung. Ihr Geldbeutel bleibt exakt gleich – nur das Reporting ändert sich.

Decken meine bestehenden CUDs nach der Migration weniger ab?

Nein – im Gegenteil. Alle bestehenden CUDs decken mindestens das ab, was sie bisher abgedeckt haben, und viele decken dank der erweiterten Berechtigung sogar mehr SKUs ab. Wer heute Compute Flexible CUDs hat, dessen Commitments greifen automatisch auch für neu berechtigte workloads wie die request-basierte Cloud-Run-Abrechnung, H3/H4D-Instanzen und Memory-Optimized VMs. Das bedeutet eine bessere Auslastung bereits gekaufter Commitments – ganz ohne Zutun Ihrerseits.

Was ändert sich also tatsächlich?

Darstellung und Datenstruktur. Ihre Rabattprozentsätze bleiben gleich. Ihre Commitment-Kosten bleiben gleich. Ihre Abdeckung bleibt entweder gleich oder verbessert sich. Geändert hat sich:

1. wie Commitment-Beträge ausgedrückt werden,
2. wie Einsparungen in Billing-Exports erscheinen,
3. welche SKUs für eine Abdeckung infrage kommen.

Mehr nicht.

Ein wichtiger Hinweis: Was diese Migration nicht betrifft, sind Resource-Based Committed Use Discounts. Dort verpflichten Sie sich auf bestimmte Mengen an vCPU, Speicher, GPU oder Local SSD in einer bestimmten Region und einem bestimmten Projekt – und das funktioniert genau wie bisher. Sie bleiben ideal für vorhersehbare, gleichbleibende workloads mit konstantem Ressourcenbedarf.

Die wesentlichen Unterschiede bleiben bestehen:

• Resource-Based CUDs sind projekt- und regionsspezifisch (lassen sich aber innerhalb eines Billing-Accounts gemeinsam nutzen).
• Spend-Based Flex CUDs werden automatisch auf alle berechtigten Nutzungen innerhalb eines Billing-Accounts angewendet.

Resource-Based Commitments bieten für General Compute leicht höhere Rabattsätze (bis zu 55 % bei 3 Jahren gegenüber 46 % bei Flex), erfordern dafür aber eine präzisere Kapazitätsplanung.

Den meisten Organisationen empfehle ich daher: Die optimale Strategie kombiniert beides – Resource-Based CUDs für vorhersehbare Baseline-workloads und Flex CUDs für variable oder verteilte Nutzung, die sich nicht ohne Weiteres auf Region und Maschinentyp festlegen lässt.

Das neue Multiprice-CUD-Modell ist die bedeutendste Änderung an der Abrechnung von Google Cloud seit Jahren. Die erweiterte Abdeckung und das saubere Datenmodell sind echte Verbesserungen. Jetzt liegt es an Ihnen, Ihre internen Systeme so aufzustellen, dass Sie davon profitieren – und wenn wir Sie bei DoiT dabei unterstützen sollen, sprechen Sie uns an.