Google ACE: Kostenmanagement, Leistung und Kapazitätsoptimierung — Lernleitfaden

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Teil des Google Associate Cloud Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Kostenmanagement und Leistungs-/Kapazitätsoptimierung auf Google Cloud erfordern kontinuierliche Transparenz, Entscheidungen zur Größenanpassung und eine Governance, die die Ressourcennutzung an den Geschäftszielen ausrichtet. Eine effektive Praxis kombiniert finanzielle Kontrollen (Budgets, Zuweisung), technische Hebel (Autoscaling, Reservierungen, Lebenszyklusrichtlinien), architektonische Entscheidungen (Datenlokalität, Replikation) und operatives Feedback (Telemetrie, Lasttests). Dieser Abschnitt beschreibt wichtige Tools, Kompromisse und Fehlerquellen in den Bereichen Compute, Storage, Datenverarbeitung, Networking, Datenbanken, Kontingente und Performance Engineering.

Kostentransparenz, Budgets und Zuweisung

Abrechnungsberichte und -exporte:
- Verwenden Sie Cloud Billing Reports für schnelle Trend- und SKU-Aufschlüsselungen; aktivieren Sie den Export von Cloud Billing-Daten nach BigQuery für detaillierte, abfragbare Kosten- und Nutzungsdaten. Dies unterstützt tägliche/monatliche Prognosen, Anomalieerkennung und projektübergreifende Zusammenfassungen mit Standard-SQL.
- Der Export der Preistabelle hilft dabei, Listenpreise mit SKU-Kosten und Gutschriften abzugleichen.
- Fehlerquellen: Die alleinige Nutzung der Konsolenansichten schränkt die Granularität ein; der Verzicht auf den Export nach BigQuery blockiert die historische Modellierung und eine genaue Showback-/Chargeback-Verrechnung.
Budgets und Benachrichtigungen:
- Erstellen Sie Budgets, die auf Abrechnungskonten, Projekte, Ordner, Dienste oder Label-/Tag-Filter beschränkt sind; konfigurieren Sie Schwellenwert-Benachrichtigungen (z. B. 50/90/100 %) für tatsächliche und prognostizierte Kosten. Ziehen Sie Benachrichtigungskanäle über Pub/Sub in Betracht, um automatisierte Aktionen auszulösen (z. B. das Anhalten von Nicht-Produktionsumgebungen).
- Kompromiss: Aggressive automatisierte Abschaltungen reduzieren die Ausgaben, können aber die Zuverlässigkeit beeinträchtigen, wenn sie auf Produktionspfade angewendet werden.
Labels und Tags zur Kostenzuordnung:
- Wenden Sie Ressourcen-Labels und Resource Manager-Tags konsistent an (env, app, owner, cost-center). Tags unterstützen Organisationsrichtlinien und erscheinen in Abrechnungsfiltern für eine robuste Zuordnung.
- Governance: Erzwingen Sie Label-/Tag-Richtlinien mithilfe von Organization Policy, Bereitstellungsvorlagen und CI/CD-Prüfungen.
- Fehlerquellen: Inkonsistente Schlüssel oder fehlende Labels machen Zuordnungsmodelle unbrauchbar; vererbte Tags werden nicht auf alle Ressourcentypen angewendet, wenn das Tooling inkonsistent ist.
Kostenzuordnungsmodelle:
- Showback/Chargeback verwenden typischerweise eine Hierarchie: Projekt → Dienst/SKU → Label/Tag. Gemeinsam genutzte Plattformkosten (z. B. Load Balancer, VPC-Egress) können nach Treibern wie Anfragen, übertragene GB oder CPU-Stunden, die über Logs/Metriken gemessen werden, zugewiesen werden.
- Kompromiss: Einfache Modelle (gleiche Aufteilung) sind leicht umzusetzen, können aber Vielnutzer falsch bepreisen; granulare Modelle erfordern zuverlässige Telemetrie und mehr Verwaltungsaufwand.

Kurzes Beispiel (BigQuery-Trockenlauf zur Kostenschätzung):

undefined

Compute-Effizienz und Lebenszyklus-Optimierung

Größenanpassung und benutzerdefinierte Maschinentypen:
- Verwenden Sie die Recommender API/Konsole, um die Größe von VMs basierend auf CPU-/Speichernutzungsperzentilen anzupassen. Bevorzugen Sie benutzerdefinierte Maschinentypen für einen stabilen, von Standardgrößen abweichenden Bedarf (z. B. 2 vCPU/10 GB RAM), um nicht für ungenutzte Kapazität zu bezahlen.
- Fehlerquellen: Eine Verkleinerung latenzempfindlicher oder durch Lastspitzen geprägter Dienste kann zu Drosselung führen. Validieren Sie dies mit Lasttests und planen Sie einen Puffer ein.
Rabatte für zugesicherte Nutzung (CUDs):
- Kaufen Sie ressourcenbasierte CUDs (vCPU, Arbeitsspeicher, GPUs) auf regionaler Ebene für eine Laufzeit von 1 oder 3 Jahren über die Konsole oder die CLI. Am besten für eine stabile Basiskapazität; überlagern Sie diese mit Autoscaling für Lastspitzen.
- Kompromisse: Zusicherungen reduzieren den Stückpreis, sind aber unflexibel. Eine zu hohe Zusicherung bindet Ausgaben; eine zu niedrige Zusicherung führt zum Verfall von Rabatten.
Spot VMs:
- Verwenden Sie Spot VMs für fehlertolerante, unterbrechbare Workloads (Batch-Verarbeitung, CI, zustandslose Tiers). Implementieren Sie Checkpointing und die Handhabung von Preemptions (30-Sekunden-Vorankündigung über Metadaten/Pub/Sub).
- Fehlerquellen: Die Kapazität kann jederzeit entzogen werden; platzieren Sie niemals zustandsbehaftete oder für ein Quorum kritische Dienste ausschließlich auf Spot VMs.
Autoscaling, Zeitplanung und Lebenszyklus:
- Verwaltete Instanzgruppen (MIGs) mit Autoscaling (basierend auf CPU, Load Balancer oder benutzerdefinierten Cloud Monitoring-Metriken) bewältigen variable Lasten. Passen Sie die Cool-down- und Scale-in-Steuerung an, um Oszillationen zu vermeiden; richten Sie die anfängliche Verzögerung des Health Checks an der Startbereitschaft der Anwendung aus.
- Zeitplanung: Stoppen oder halten Sie Dev/Test-VMs außerhalb der Geschäftszeiten an; verwenden Sie Instance Schedules oder Automatisierung mit Cloud Scheduler und Cloud Functions, um Leerlaufkosten zu minimieren.
- Lebenszyklus und Wartung: Aktivieren Sie den automatischen Neustart und die Migration bei Host-Wartung für hohe Verfügbarkeit; beachten Sie, dass eine Live-Migration möglicherweise nicht bei GPUs oder lokalen SSDs anwendbar ist.
- Bereinigung von Leerlaufressourcen: Geben Sie nicht angehängte nichtflüchtige Speicher, veraltete Snapshots und ungenutzte statische IPs mithilfe des Recommenders frei.
- Fehlerquellen: Kurze Verzögerungen bei Health Checks oder fehlende Bereitschaftssignale führen zu Überprovisionierung; zu aggressives Scale-in führt zum Abbruch von Verbindungen; die Deaktivierung der automatischen Reparatur verbirgt fehlerhafte Knoten.

Kurze Beispiele:

undefined

Wirtschaftlichkeit von Speicher und Datenverarbeitung

Cloud Storage-Speicherklassen und Lebenszyklus:
- Wählen Sie Klassen nach Zugriffsmuster: Standard (heiß), Nearline (≥30 Tage min.), Coldline (≥90 Tage min.), Archive (≥365 Tage min.). Wenden Sie Lebenszyklusregeln an, um Daten planmäßig herabzustufen und zu löschen.
- Abwägungen beim Abruf: Kostengünstigere Klassen erheben Abrufgebühren pro GB und Gebühren für die minimale Speicherdauer; häufige Lesezugriffe auf Coldline/Archive machen die Einsparungen zunichte. Planen Sie Wiederherstellungs-Workflows für Spitzenkosten bei Lesezugriffen.
- Governance: Verwenden Sie Aufbewahrungsrichtlinien und Objektsperren für die Compliance; aktivieren Sie „Requester Pays“ für gemeinsam genutzte Datensätze, um teamübergreifende Abrechnungsüberraschungen zu vermeiden.
Beispiel für eine Lebenszyklusrichtlinie (Herabstufen und dann löschen):
- Definieren Sie altersbasierte Aktionen wie SetStorageClass und Delete, um Übergänge und die Bereinigung veralteter Daten zu automatisieren.
Kostenkontrolle bei BigQuery:
- On-Demand-Abfragen werden nach verarbeiteten Bytes abgerechnet; minimieren Sie dies durch Partitionsbereinigung und Clustering. Partitionieren Sie nach Aufnahmezeit oder einer Datumsspalte; clustern Sie bis zu vier Spalten mit hoher Kardinalität/Selektivität.
- Nutzen Sie Testläufe zur Kostenschätzung, materialisierte Ansichten für häufig genutzte Aggregationen und Tabellen-Decorators, um Zeitfenster einzugrenzen.
- Reservierungen (Slots) bieten vorhersagbare Leistung und Ausgaben; verwenden Sie Zuweisungen pro Projekt/Ordner und ziehen Sie flexible Zusicherungen für kurze Lastspitzen in Betracht.
- Fehlerszenarien: Nicht partitionierte Scans, SELECT * in breiten Tabellen oder schlecht geordnetes Clustering erzeugen massiv gescannte Bytes; kurzlebige Zwischentabellen können den Speicher aufblähen, wenn sie nicht ablaufen.

Kurzes Beispiel (Cloud Storage Lebenszyklus JSON-Snippet):

{ “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }

Netzwerk, Datenbanken und kontingentbewusste Skalierung

Netzwerk-Egress und Architekturauswirkungen:
- Egress ins Internet, zwischen Regionen und über externe IPs verursacht Kosten; Verkehr innerhalb derselben Region über interne IPs ist in der Regel kostenlos. Wählen Sie den Premium Network Tier für Leistung oder den Standard Tier für kostensensible Workloads mit geringeren Anforderungen an Latenz/Jitter.
- Load Balancer: L7 HTTP(S) und L4 TCP/UDP haben Gebühren für die Datenverarbeitung und Weiterleitungsregeln; regionenübergreifende LBs können zusätzlichen interregionalen Egress verursachen. Die Konsolidierung von LBs spart Fixkosten, kann aber den Auswirkungsradius vergrößern.
- Optimierung: Halten Sie den Verkehr intraregional; nutzen Sie regionale Buckets und Dienste; vermeiden Sie Hairpinning über externe IPs. Cachen Sie statische Assets am Edge, um den Egress vom Ursprungsserver zu reduzieren.
- Fehlerszenarien: Die versehentliche Verwendung externer IPs zwischen Diensten in derselben VPC verursacht unnötigen Egress; multiregionale Replikation verdoppelt den Egress für Schreibpfade.
Dimensionierung von Datenbanken, Replikate und Verfügbarkeit:
- Cloud SQL: Dimensionieren Sie vCPU/RAM für die 95-Perzentil-Last; aktivieren Sie die automatische Speichergrößenanpassung; verwenden Sie Lesereplikate für die horizontale Leseskalierung; HA (Hochverfügbarkeit) verdoppelt die Rechenkosten, reduziert aber die RTO beim Failover. Verbindungspooling vermeidet übermäßigen Overhead bei Verbindungen.
- Spanner: Die Kapazität wird in Knoten oder Verarbeitungseinheiten bereitgestellt; multiregionale Konfigurationen verbessern die Verfügbarkeit und Leselatenz, erhöhen aber die Kosten und die Schreiblatenz; planen Sie Splits und Hotspots sorgfältig.
- Bigtable: Die Anzahl der Knoten bestimmt den Durchsatz; der Autoscaler hilft bei der Verfolgung des Traffics; Multi-Cluster-Replikation erhöht die Verfügbarkeit und die Kosten; Schema für eine gleichmäßige Schlüsselverteilung.
- Abwägungen: Replikate verbessern den Lesedurchsatz und die Verfügbarkeit, erhöhen aber die Schreibverstärkung und den Egress; starke Konsistenz und multiregionale Schreibvorgänge erhöhen die Latenz.
Kontingente, Ratenbegrenzungen und Backpressure:
- Verstehen Sie API-spezifische Kontingente und die dienstspezifische Gleichzeitigkeit. Implementieren Sie exponentiellen Backoff mit Jitter für 429/5xx-Fehler. Wenden Sie warteschlangenbasierten Lastausgleich mit Pub/Sub und Dataflow oder Cloud Run-Jobs an.
- Gleichzeitigkeitseinstellungen: Bei Cloud Run reduziert eine höhere Gleichzeitigkeit die Kosten, birgt aber das Risiko von Tail-Latenz; passen Sie die CPU-Zuweisung bei Anforderung an, um einen stabilen Durchsatz zu gewährleisten.
- Backpressure: Nutzen Sie Flusskontrolle in Pub/Sub-Abonnenten, Circuit Breaker und Zugangskontrolle, um kaskadierende Ausfälle zu verhindern.
- Fehlerszenarien: Das Ignorieren von Kontingenten führt zu plötzlicher Drosselung; Autoscaling kann die Last auf nachgelagerte Systeme ohne Backpressure verstärken, was zu Wiederholungsversuchen und steigenden Kosten führt.

Governance für Leistungsmessung und -optimierung

Messung und Lasttests:
- Etablieren Sie SLIs/SLOs für Latenz, Fehlerrate und Sättigung. Verwenden Sie Cloud Monitoring-Dashboards, Uptime-Prüfungen und Benachrichtigungen. Implementieren Sie Tracing (Cloud Trace) und Profiling (Cloud Profiler), um Hot Paths und Sperrkonflikte zu lokalisieren.
- Führen Sie Lasttests mit realistischen Traffic-Modellen, Datenkardinalität und Denkzeiten durch. Validieren Sie Autoscaler-Parameter, Aufwärmphasen und Readiness Gates. Schließen Sie Failover- und Chaos-Szenarien ein, um Kapazitätsreserven und Wiederherstellungszeiten zu beobachten.
- Engpassdiagnose: Verwenden Sie die USE-Methode (Utilization, Saturation, Errors – Auslastung, Sättigung, Fehler) für CPU, Arbeitsspeicher, Festplatte, Netzwerk und nachgelagerte Abhängigkeiten; korrelieren Sie die Ergebnisse mit Logs und Traces.
Governance zur Abstimmung von Kosten, Sicherheit und Zuverlässigkeit:
- FinOps-Leitplanken: Verbindliche Labels/Tags; Budgets mit Prognose-Alarmen; zentralisierte Abrechnungsexporte und regelmäßige Kostenüberprüfungen. Übernehmen Sie die Ergebnisse des Recommenders (ungenutzte IPs/Festplatten, Rightsizing) mit SLAs für die Verantwortlichen in das Backlog.
- Sicherheit: Bevorzugen Sie private Konnektivität (keine externen IPs) und VPC Service Controls für Risiken der Datenexfiltration – beachten Sie, dass private Pfade Egress-Muster und Kosten verändern können. Verschlüsseln Sie Daten im Ruhezustand (at rest) und bei der Übertragung (in transit); berücksichtigen Sie die KMS-Nutzung in den Kostenmodellen.
- Zuverlässigkeit: Reservieren Sie Basiskapazität über CUDs oder BigQuery-Reservierungen; halten Sie Spielraum für Lastspitzen (Burst Headroom) für SLOs bereit; führen Sie regelmäßig Game Days durch. Dokumentieren Sie, wann Spot-Instanzen oder aggressives Autoscaling für kritische Pfade inakzeptabel sind.
- Change Management: Behandeln Sie kostenrelevante Parameter (Autoscaler-Obergrenzen, BigQuery-Reservierungen, LB-Topologie) als Code mit Review- und Rollback-Plänen.

Praktisches Problemszenario

Contoso Media betreibt eine regionenübergreifende Videoanalyse-Plattform, bei der steigende Kosten und gelegentliche Verletzungen des Latenz-SLOs bei Lastspitzen auftreten. Die Geschäftsführung fordert eine Kostensenkung um 20 %, ohne das p95-Latenz-SLO von 300 ms für die API und ein 2-Stunden-SLA für den Abschluss der nächtlichen Batch-Verarbeitung zu beeinträchtigen.

Kosten- und Leistungs-Baselines erstellen

Aktion: Export von Cloud Billing nach BigQuery aktivieren und Dashboards erstellen, die SKU-Kosten mit Cloud Monitoring-SLIs (Latenz, CPU, ausgehende Bytes) korrelieren. Führen Sie bq-Trockenläufe für die Top-20-Abfragen durch, um die gescannten Bytes abzuschätzen.
Begründung: Baselines identifizieren Dienste mit großer Auswirkung und bilden die Ausgaben auf Leistungstreiber ab, was eine gezielte Optimierung ermöglicht.

Zuordnungs-Tagging und Budgets durchsetzen

Aktion: Labels/Tags (env, service, owner, cost-center) über Deployment-Vorlagen vorschreiben; Budgets pro Umgebung mit Prognose-Alarmen an ein FinOps Pub/Sub-Thema einrichten.
Begründung: Vollständige Zuordnungsdaten und proaktive Alarme ermöglichen eine schnelle Zuweisung der Verantwortung und Korrekturmaßnahmen vor Kostenüberschreitungen.

Compute-Basisleistung richtig dimensionieren und binden (Rightsizing und Commitments)

Aktion: VM-Rightsizing-Empfehlungen des Recommenders auf Dienste mit stabiler Last anwenden; Kapazität für den stabilen Zustand in einjährige regionale CUDs umwandeln; 20–30 % Puffer auf dem Autoscaler-Maximum für Lastspitzen beibehalten.
Begründung: Rightsizing und Commitments senken die Einheitskosten für vorhersehbare Lasten, während der Spielraum für SLOs erhalten bleibt.

Autoscaling und Readiness optimieren

Aktion: Bei MIGs die Autoscaling-Signale auf anfragebasierte oder benutzerdefinierte QPS/Latenz-Metriken umstellen, die Cool-Down-Phase auf 120–180 Sekunden einstellen und die initiale Verzögerung des Health Checks auf die Aufwärmphase der Anwendung abstimmen. Scale-In-Steuerung aktivieren, um ein schnelles Herunterskalieren zu verhindern.
Begründung: Workload-abhängige Signale und Stabilisierung vermeiden „Thrashing“ und Überprovisionierung, die die Kosten in die Höhe treiben und die Latenz beeinträchtigen.

Netzwerk-Egress und Load-Balancer-Overhead reduzieren

Aktion: Externe IP-Kommunikation zwischen Diensten entfernen; sicherstellen, dass der gesamte Ost-West-Traffic internes Load Balancing verwendet; kommunikationsintensive Dienste innerhalb von Regionen am selben Standort platzieren; statische Assets am Edge zwischenspeichern.
Begründung: Interne Pfade eliminieren unnötigen Egress und reduzieren die L7-Verarbeitung, was Latenz und Kosten verbessert.

Speicherlebenszyklus und Archivierung

Aktion: Cloud Storage-Lebenszyklusregeln anwenden, um kalte Artefakte nach 90 Tagen nach Coldline zu verschieben und nach 365 Tagen zu löschen; „Requester Pays“ für gemeinsam genutzte Buckets festlegen; die Auswirkungen der Mindestspeicherdauer für Daten mit seltenem Zugriff überprüfen.
Begründung: Tiering und Aufbewahrungsrichtlinien reduzieren Speicher- und Abrufkosten bei gleichzeitiger Einhaltung der Compliance.

BigQuery-Abfrage- und Kapazitäts-Tuning

Aktion: Große Faktentabellen nach Datum partitionieren, nach Spalten mit hoher Selektivität clustern; SELECT * durch Spaltenprojektionen ersetzen; materialisierte Ansichten für Top-Aggregationen einführen; eine kleine Reservierung für ETL-Spitzenlastfenster erwerben und Flex Slots bei Batch-Spitzen verwenden.
Begründung: Partitionierung/Clustering reduziert die Anzahl der gescannten Bytes; Kapazitätsreservierungen stabilisieren die Leistung und die Kosten für kritische Workloads.

Datenbankskalierung und Replikate

Aktion: Für leseintensive Dienste in Cloud SQL Lesereplikate hinzufügen; Connection Pooling optimieren; automatische Speichergrößenanpassung einrichten; Failover testen, um RTO/RPO zu validieren. Für Bigtable den Autoscaler aktivieren und Hotspot-Keys beheben.
Begründung: Replikate entlasten Lesezugriffe und schützen Schreibpfade; Autoscaling hält den Durchsatz ohne manuelle Überprovisionierung an der Nachfrage ausgerichtet.

Kontingente, Gleichzeitigkeit und Backpressure

Aktion: Exponentiellen Backoff mit Jitter implementieren; Pub/Sub-Subscriber-Flusskontrolle konfigurieren; Cloud Run-Gleichzeitigkeit einstellen, um Durchsatz und Latenz auszubalancieren; Circuit Breaker an den Grenzen zu nachgelagerten Systemen hinzufügen.
Begründung: Eine korrekte Backpressure verhindert kaskadierende Ausfälle und außer Kontrolle geratene Wiederholungsversuche, die die SLOs verschlechtern und die Kosten in die Höhe treiben.

Kontinuierliche Validierung und Governance

Aktion: Monatliche Lasttests und Chaos Drills durchführen; SLO-/Fehlerbudgets verfolgen; Ergebnisse des Recommenders und Kostenanomalien mit Verantwort

← Zuverlässigkeit · Alle Domänen

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →