CUDs für BigQuery und Composer sind endlich da – spare ich damit wirklich Geld?
Einleitung
Google hat kürzlich Committed Use Discounts (CUDs) für BigQuery und Cloud Composer angekündigt – und damit Sparpotenzial bei konstanter Nutzung in Aussicht gestellt. Versprochen sind bis zu 20 % Rabatt bei dreijähriger und 10 % bei einjähriger Laufzeit. Wie viel Sie tatsächlich sparen, hängt allerdings davon ab, ob Sie Ihre stündliche Commitment-Baseline durchgehend ausschöpfen.
Die meisten Details stehen in der offiziellen Dokumentation (etwa hier [1] und hier [2]) – ich möchte aber etwas Kontext ergänzen:
Diese CUDs sind spend-based: Sie verpflichten sich, pro Stunde einen festgelegten Betrag für berechtigte SKUs auszugeben. Der Kauf läuft über Ihren Billing Account, und die Rabatte lassen sich projektübergreifend innerhalb derselben Region teilen. Wichtig: CUDs sind regionsspezifisch, Sie müssen sie also für jede Region separat erwerben, in der Sie den Rabatt nutzen möchten.
Laut Google gelten CUDs für alle BigQuery-PAYG-SKUs [3]. Konkret umfasst das aber nur:
- BigQuery-Editions-Verbrauchsmodelle (alle Editions!)
- Composer-3-SKUs für Compute (sehr schön!)
- BigQuery Data Governance (vormals Dataplex)
Es gibt jedoch nennenswerte Ausnahmen: BigQuery-Storage-Kosten und das On-Demand-Pricing für Analyseabfragen werden von diesen CUDs nicht abgedeckt. Eine entscheidende Einschränkung, die man im Hinterkopf behalten sollte.
Auf der Habenseite: Composer-CUDs sind ein willkommenes und lang erwartetes Feature für viele Nutzer. Auch die Einbeziehung von BigQuery Data Governance ist interessant, zumal Google diese SKUs erst kürzlich unter das BigQuery-Dach geholt hat. Wie wirkungsvoll die CUDs für diese spezifischen Services sind, wird sich zeigen.
Um zu beurteilen, ob die neuen BigQuery-/Composer-CUDs für Sie sinnvoll sind, sollten Sie folgende Punkte prüfen:
- Nutzen Sie BigQuery Editions in Kombination mit Cloud Composer (Version 2 oder 3) oder BigQuery Data Governance? Ein reines BigQuery-Slot-Commitment ist möglicherweise günstiger – wenn Sie jedoch konstante Nutzung über mehrere dieser berechtigten Services hinweg haben, profitieren Sie zusätzlich von diesen neuen spend-based CUDs.
- Haben Sie stabile workloads in diesen Services? Läuft Ihre Composer-Umgebung etwa rund um die Uhr, und werden Abfragen kontinuierlich über den Tag verteilt ausgeführt?
- Bestehen bereits andere Slot Commitments für BigQuery-Reservierungen [4]? Es sieht so aus, als ließen sich diese neuen spend-based CUDs für Editions/Composer/Governance nicht mit bestehenden Slot-Reservierungs-Commitments kombinieren.
So ermitteln Sie Ihre stabile Workload-Baseline
Die Baseline für stabile workloads zu bestimmen, ist weniger trivial, als es klingt – Sie müssen die stündlichen Ausgaben für sämtliche berechtigten SKUs sauber ermitteln.
Zunächst können Sie in den Einstellungen Ihres Billing Accounts unter "Committed use discounts analysis" einsehen, welche Nutzung sich über CUDs abdecken ließe.
Falls Sie zudem einen detaillierten BQ-Export eingerichtet haben, können Sie folgendes Query nutzen:
WITH base as (
SELECT *
FROM `project.dataset.billing_export*`
WHERE 1=1
AND TIMESTAMP_TRUNC(export_time, DAY) = TIMESTAMP("2025-04-20")
AND sku_group_description like "%PAYG%"
AND service_description = "BigQuery Reservation API"
)
SELECT
usage_start_time,
sku_group_description,
sku_description,
location.region,
SUM(cost)
FROM base
GROUP BY ALL
Für DoiT-Kunden haben wir einen passenden Report ergänzt: BigQuery CUD eligible analysis spend. Sprechen Sie uns gerne über eine Support-Anfrage an, wenn Sie sich dazu mit einem unserer BigQuery-SMEs austauschen möchten.
DoiT DCI Report: BigQuery CUD eligible analysis spend.
Generell fahren Sie mit einem BigQuery-Slot-Commitment besser. Wenn Sie jedoch Cloud Composer 3 oder BigQuery Data Governance einsetzen, sind BigQuery-CUDs durchaus attraktiv.
Vergleich: CUDs vs. Slot-Commitment
Beispiel
Schauen wir uns folgendes, einfaches Praxisszenario an:
Kosten pro berechtigter SKU, gruppiert nach Region
In diesem Beispiel lohnt sich der Kauf von CUDs für us-east1 oder us-central kaum – die stündlichen Ausgaben für berechtigte SKUs liegen unter 1 $. In der US-Multi-Region hingegen ließen sich 10 % einsparen (bis zu 500 $ pro Tag; 230 $ Baseline × 24 Stunden × 0,1), wenn der Kunde einen CUD erwirbt. Der Haken: Er hat bereits eine einjährige BigQuery-Slot-Reservierung, die ihm 20 % pro Slot-Stunde spart. In diesem konkreten Fall wäre ein zusätzliches spend-based Commitment nicht sinnvoll.
Generell empfehlen wir häufig einen Mix aus 1-Jahres- und 3-Jahres-CUDs, um nicht alles auf eine Karte zu setzen. Außerdem kann es sinnvoll sein, nur 60–75 % der berechtigten Ausgaben mit CUDs abzudecken – das lässt Spielraum für künftige Kostenoptimierungen oder veränderte Nutzungsmuster.
TL;DR
Für "Always-on"-Services wie VMs oder auch Cloud SQL sind CUDs zweifellos sinnvoll – zu typischen BigQuery-Nutzungsmustern passen sie aber nicht zwangsläufig. BigQuery-workloads sind häufig eher spiky und können bei Nichtnutzung auf null herunterskalieren. Genau das ist ja einer der Hauptvorteile eines Cloud Data Warehouse.
Beziehen Sie aber Cloud Composer und BigQuery Data Governance in die Rechnung mit ein, ändert sich das Bild. Diese Services laufen tendenziell konstant, oft rund um die Uhr, und verbrauchen den ganzen Tag über Compute-Ressourcen (etwa Slots oder DCUs).
Wenn Ihnen gefällt, was wir tun, schauen Sie auf unserer Services-Seite vorbei: https://doit.com/services
[1] https://cloud.google.com/bigquery/docs/bigquery-cud
[2] https://cloud.google.com/docs/cuds-spend-based#purchasing