Google Cloud Kosten senken: Die wirksamsten Hebel

Googles Well-Architected Framework fasst Kostenoptimierung in vier Prinzipien: Cloud-Ausgaben am Geschäftswert ausrichten, eine Kultur des Kostenbewusstseins fördern, Ressourcen bedarfsgerecht nutzen und kontinuierlich optimieren [W1]. Der vierte Punkt ist der wichtigste in der Praxis. Einmalige Aufräumaktionen verpuffen, wenn niemand die Kosten laufend beobachtet. Wie sich daraus ein dauerhafter Prozess macht, beschreibt unser Beitrag Multi-Cloud Cost Optimization: A Practical Decision Framework (englisch).

Ohne Zuordnung lassen sich Einsparungen weder priorisieren noch nachweisen. Labels sind Schlüssel-Wert-Paare, die Sie Google-Cloud-Ressourcen zuweisen. Google leitet die Label-Informationen an das Abrechnungssystem weiter, sodass sich die abgerechneten Kosten nach Labels aufschlüsseln und in den Abrechnungsberichten filtern lassen [W11]. Legen Sie vor der ersten Optimierungsrunde fest, welche Labels Pflicht sind, etwa Team, Umgebung und Anwendung.

Der günstigste Server ist der, der nicht läuft. Compute Engine erzeugt automatisch Empfehlungen für ungenutzte VMs. Sie identifizieren Instanzen, die in den vergangenen 1 bis 14 Tagen nicht genutzt wurden, auf Basis der Messwerte aus Cloud Monitoring [W5]. Diese Empfehlungen sind ein guter Startpunkt für die erste Bereinigung, besonders in Entwicklungs- und Testprojekten.

Wichtig ist die Prüfung vor dem Löschen. Eine VM, die zwei Wochen ruht, kann trotzdem Teil eines Notfallplans oder eines monatlichen Abschlusslaufs sein. Klären Sie deshalb den Eigentümer, bevor Sie stoppen.

Viele VMs sind größer als nötig, weil sie beim Start großzügig dimensioniert wurden. Compute Engine liefert dafür Maschinentyp-Empfehlungen, auch Rightsizing-Empfehlungen genannt. Sie basieren auf Systemmetriken der vergangenen 8 Tage [W6].

Acht Tage bilden kurzfristige Muster ab, aber keine Monats- oder Quartalsspitzen. Für Systeme mit saisonaler Last sollten Sie die Empfehlung mit längeren Zeitreihen abgleichen. Hintergründe zu Rightsizing und Autoscaling über mehrere Clouds hinweg finden Sie in Rightsizing and Autoscaling in Multi-Cloud (englisch).

Erst wenn die Größen stimmen, lohnen Verpflichtungen. Google bietet drei Mechanismen mit sehr unterschiedlichem Risiko.

Sustained Use Discounts: automatisch, aber begrenzt

Compute Engine gewährt Sustained Use Discounts (SUDs) für Ressourcen, die mehr als 25 Prozent eines Abrechnungsmonats genutzt werden und keine anderen Rabatte erhalten. Der Rabatt steigt mit der Nutzung und erreicht bis zu 30 Prozent Nettorabatt für VMs, die den ganzen Monat laufen. Er erscheint automatisch auf der Rechnung [W3]. Sie müssen nichts tun, aber Sie können ihn auch nicht mit anderen Rabatten kombinieren.

Committed Use Discounts: Rabatt gegen Verpflichtung

Committed Use Discounts (CUDs) gewähren Rabatte im Gegenzug für eine Verpflichtung. Es gibt zwei Varianten [W2]:

• Ausgabenbasierte CUDs verpflichten Sie zu einem Mindestumsatz für bestimmte Dienste, mit einer Laufzeit von einem oder drei Jahren. Bei den Flexible Savings Plans wird die Verpflichtung über ein monatliches Zeitfenster gemessen. Nutzung über dem zugesagten Betrag wird zum On-Demand-Preis abgerechnet.
• Ressourcenbasierte CUDs gibt es nur für Compute Engine. Sie verpflichten sich zu einer Mindestmenge an Ressourcen wie vCPUs und Arbeitsspeicher in einer bestimmten Region. Google empfiehlt sie für planbaren Bedarf.

Die Wahl hängt von der Planbarkeit ab. Ressourcenbasierte Zusagen binden Sie an Region und Ressourcentyp, ausgabenbasierte lassen mehr Spielraum. Unser Beitrag Commitment Strategy: On-Demand, Reserved, Spot (englisch) behandelt die Portfolio-Logik dahinter.

Spot VMs: hoher Rabatt, aber unterbrechbar

Spot VMs nutzen freie Compute-Engine-Kapazität zu deutlich reduzierten Preisen. Compute Engine kann sie jedoch jederzeit stoppen oder löschen, um die Kapazität zurückzuholen. Es gibt keine Mindest- oder Höchstlaufzeit, sofern Sie diese nicht selbst begrenzen [W4]. Vor dem Abschalten erhält die VM ein Signal über die Metadaten. Die Vorwarnzeit lässt sich beim Erstellen festlegen, Google empfiehlt 120 Sekunden für Arbeitslasten, die mehr als 30 Sekunden zum sauberen Beenden brauchen. Die anschließende Herunterfahrphase ist best effort und dauert bis zu 30 Sekunden [W4].

Spot VMs eignen sich deshalb für fehlertolerante Aufgaben wie Batch-Verarbeitung [W4], nicht für zustandsbehaftete Produktionsdatenbanken.

Bei datenintensiven Unternehmen ist BigQuery oft einer der größten Posten. BigQuery bietet drei Editionen, die mit reservierter Kapazität genutzt werden, sowie ein On-Demand-Modell, das nach verarbeiteten TiB abrechnet. Beide Modelle lassen sich pro Projekt gleichzeitig nutzen. Reservierungen mit Slot-Autoscaling skalieren mit der Last, und Kapazitätszusagen sind nicht zwingend, können aber die Kosten senken [W7].

Daraus folgt eine einfache Regel: Projekte mit gleichmäßiger, hoher Abfragelast sind Kandidaten für reservierte Kapazität, sporadische Analysen bleiben oft günstiger im On-Demand-Modell. Prüfen Sie die Zuordnung pro Projekt, nicht für die ganze Organisation.

Netzwerkkosten wachsen leise. Google bietet zwei Network Service Tiers: Premium Tier leitet Verkehr über Googles eigenes Backbone, Standard Tier über reguläre ISP-Netze. Google selbst empfiehlt Premium für Leistung und Standard für Kostenoptimierung [W8]. Für Arbeitslasten ohne strenge Latenzanforderungen kann der Wechsel des Tiers die Kosten für ausgehenden Verkehr senken. Prüfen Sie aber Einschränkungen, etwa bei Cloud Storage, wo Standard Tier nur über bestimmte Load-Balancer-Konfigurationen verfügbar ist [W8].

Cloud Storage bietet zwei Wege, Daten in günstigere Speicherklassen zu bewegen. Mit Object Lifecycle Management definieren Sie Regeln, etwa eine Lebensdauer für Objekte oder das Herabstufen in eine günstigere Klasse. Dabei hat die Löschaktion Vorrang vor jeder Klassenänderung, und bei mehreren Änderungsregeln gewinnt die Klasse mit dem niedrigsten Speicherpreis [W14]. Alternativ verschiebt Autoclass Objekte automatisch anhand ihres Zugriffsmusters: ungenutzte Daten in kältere Klassen, genutzte zurück nach Standard. Dafür fallen eine Verwaltungsgebühr und eine einmalige Aktivierungsgebühr an [W15]. Lifecycle-Regeln passen zu Daten mit bekanntem Lebenszyklus, Autoclass zu Buckets mit unklarem Zugriff.

Kostenoptimierung umfasst auch die Option, Arbeitslasten anderswo zu betreiben. Seit dem 11. Januar 2024 bietet Google Cloud Kunden, die zu einem anderen Anbieter oder ins eigene Rechenzentrum wechseln, kostenlose Datenübertragung für die Migration an [W9]. Voraussetzung ist, dass alle Arbeitslasten und Daten des betreffenden Dienstes migriert werden. Der Ablauf ist formalisiert: Exit-Mitteilung, eine 30-tägige Startphase für die Migration und danach mindestens 30 Tage Migrationszeitraum [W10].

Das verändert die Kostenrechnung. Ein Vergleich mit anderen Anbietern, etwa europäischen Clouds, scheitert seltener an den Übertragungskosten. Der rechtliche Rahmen dazu, die Abschaffung der Wechselentgelte nach dem EU Data Act, ist in unserem Beitrag EU Data Act: Cloud Switching Fees End 12 Jan 2027 (englisch) erklärt.

Budgets in Cloud Billing lösen bei festgelegten Schwellenwerten E-Mail-Benachrichtigungen aus. Über Pub/Sub lassen sich die Meldungen zudem programmatisch verarbeiten, etwa zur Weiterleitung an Slack oder zur Automatisierung, bis hin zum programmatischen Deaktivieren der Abrechnung für ein Projekt [W12]. Die Anomalieerkennung meldet Ausgabenspitzen und Abweichungen, die vom erwarteten Verlauf auf Basis der bisherigen Ausgaben abweichen [W13]. Beides zusammen verhindert, dass Einsparungen unbemerkt wieder verloren gehen.

Zusagen vor dem Rightsizing. Wer CUDs auf überdimensionierte VMs abschließt, verpflichtet sich für ein oder drei Jahre auf Kapazität, die er später nicht braucht [W2][W6].

Spot VMs für zustandsbehaftete Systeme. Spot VMs können jederzeit zurückgeholt werden [W4]. Ohne Checkpointing oder Neustartlogik wird der Rabatt durch Ausfälle aufgezehrt.

Ein BigQuery-Modell für alle Projekte. On-Demand und Editionen lassen sich pro Projekt kombinieren [W7]. Eine organisationsweite Pauschalentscheidung verschenkt dieses Potenzial.

Empfehlungen ungeprüft übernehmen. Leerlauf- und Rightsizing-Empfehlungen beruhen auf kurzen Beobachtungszeiträumen von 1 bis 14 bzw. 8 Tagen [W5][W6]. Sie sind ein Hinweis, keine Entscheidung.

Die Angaben beruhen auf der öffentlichen Google-Cloud-Dokumentation, Stand 15. Oktober 2026. Preise, Rabattstufen und Programmbedingungen ändern sich regelmäßig. Konkrete Einsparungen hängen von Architektur, Nutzungsprofil und Vertrag ab und lassen sich nur mit den eigenen Abrechnungsdaten bestimmen. Prozentangaben in diesem Artikel stammen ausschließlich aus der Google-Dokumentation und sind Obergrenzen, keine Erwartungswerte.

Wer Google Cloud Kosten senken will, sollte zuerst Verschwendung beseitigen, dann Rabatte nutzen und die Platzierung der Arbeitslasten regelmäßig infrage stellen. Die nativen Empfehlungen von Google sind ein guter Anfang, sie betrachten aber nur Google Cloud.

Atomity geht einen Schritt weiter: Wir erkennen ungenutzte und überdimensionierte Ressourcen, vergleichen, ob eine Arbeitslast auf einem anderen Anbieter wie IONOS, STACKIT oder AWS günstiger liefe, und setzen Korrekturen über Pull Requests, Jira-Tickets und Slack-Benachrichtigungen um, ohne dass Ihr Team die Kontrolle abgibt. Wo Ihr Einsparpotenzial liegt, zeigt die kostenlose Cloud-Kostenanalyse.