Google PCNE: Load Balancing, Cloud CDN und globales Traffic-Management — Lernleitfaden

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

Überblick

Dieser Abschnitt erklärt, wie Google Cloud Load Balancing, Cloud CDN und globales Traffic-Management zusammenarbeiten, um ausfallsichere, performante und sichere Dienste bereitzustellen. Er behandelt Load-Balancer-Familien und deren Auswahl, das Verhalten von Proxy im Vergleich zu Passthrough, Backend- und Routing-Komponenten, Failover- und Kapazitätsmanagement, Cloud CDN-Caching und Origin-Schutz, Anycast- und regionenübergreifende Designs, DNS-Steuerung und Health Checks, Beobachtbarkeit (Observability) sowie Designmuster für robuste globale Eingangspunkte.

Load-Balancer-Familien, Auswahl und Verhalten der Datenebene

Google Cloud bietet externe und interne Load Balancer mit unterschiedlichen Geltungsbereichen, Protokollen und Merkmalen der Datenebene. Die Wahl des richtigen Load Balancers stimmt Protokollanforderungen, geografische Gegebenheiten und betriebliche Kontrollen aufeinander ab.

Externer Proxy L7 (global): External Application Load Balancer für HTTP(S) und gRPC. Beendet TLS, setzt L7-Richtlinien durch, unterstützt URL-Maps, Cloud CDN, Cloud Armor, Request/Response-Funktionen und Anycast-IPv4/IPv6. Optimal für Web-APIs/Websites mit Internetzugang, die erweitertes Routing, Sicherheit und Caching erfordern.
Externer Proxy L4.5: External TCP Proxy Load Balancer (global) und External UDP Proxy Load Balancer (regional) beenden Client-Verbindungen und leiten sie per Proxy an Backends weiter. Verwenden Sie diese, wenn Sie eine globale VIP und L4-Funktionen (TLS-Richtlinie, Erhaltung der Client-IP über Header für TCP) ohne L7-Routing benötigen.
Externes Passthrough L3/L4 (regional): External Network Load Balancer leitet Pakete weiter, ohne die Verbindung zu beenden. Geringste Latenz und einfachste Konfiguration; unterstützt TCP/UDP/ESP/ICMP. Geeignet für Lift-and-Shift, heterogene Backends oder Protokolle, die keine Proxy-Terminierung tolerieren. Der klassische NLB verwendet Zielpools (Target Pools); der neuere regionale Passthrough-NLB verwendet Backend-Dienste (Backend Services).
Interner Proxy (regional): Internal HTTP(S) Load Balancer (L7) und Internal TCP Proxy Load Balancer (L4.5) beenden und leiten Verbindungen innerhalb einer VPC für den Nord-Süd- und Service-zu-Service-Einsatz von Microservices per Proxy weiter. Unterstützen Host/Pfad-Routing (HTTP), mTLS zu Clients über die Anwendung und dienstspezifische Sicherheitsrichtlinien.
Internes Passthrough (regional): Internal TCP/UDP Load Balancer verteilt Verbindungen an Backends über private RFC1918-Adressen, wobei die Client-IP erhalten bleibt und MAGLEV-Hashing verwendet wird. Ideal für Ost-West-Dienste (Datenbanken, benutzerdefinierte Protokolle), die eine zonenbewusste Verteilung und geringen Overhead erfordern.

Abwägungen bei Schicht und Terminierung:

Proxy L7/4.5 bietet erweitertes Routing, TLS-Offload, Beobachtbarkeit (Observability), Cloud Armor/CDN und regionenübergreifendes Failover auf Kosten zusätzlicher Hops und möglicher Header/NAT-Änderungen. Er eignet sich für öffentliche Eingangspunkte und Service Meshes.
Passthrough L3/L4 erhält die Client-IP durchgängig und minimiert die Latenz, bietet aber keine L7-Funktionen und weniger Anknüpfungspunkte für die Beobachtbarkeit. Das Sitzungsverhalten ist Hash-basiert; Health Checks sind einfacher.

Geltungsbereich und IP-Familien:

Globale Anycast-VIPs sind für den External Application LB und den External TCP Proxy LB verfügbar und stellen einzelne IPv4/IPv6-Adressen bereit, die von überall erreichbar sind. Regionale LBs verwenden regionale Unicast-VIPs. Die Bereitstellung öffentlicher Dienste über IPv6 wird durch die Konfiguration eines externen globalen Load Balancers mit einer IPv6-Adresse erreicht.

Highlights der Auswahlkriterien:

Bedarf an Host/Pfad-Routing, Weiterleitungen, Cloud CDN, Cloud Armor oder gRPC: External Application LB.
Bedarf an globalem TCP ohne L7: External TCP Proxy LB.
Protokolle, die Proxys nicht tolerieren (z. B. einige ältere UDP/TFTP-Implementierungen): Externes oder internes Passthrough.
Privater Service-zu-Service-Verkehr mit HTTP-Routing: Internal HTTP(S) LB.
Minimierung von Kosten/Hops für Intra-VPC-Traffic: Internes Passthrough.

Backend-Dienste, Routing-Objekte, Systemdiagnosen und Traffic-Stickiness

Kernobjekte der Datenebene:

Backend services: Definieren Backends (Instanzgruppen, zonale NEGs, hybride NEGs, serverlose NEGs), Systemdiagnosen, Balancing-Modus, Kapazität, Sitzungsaffinität, Timeout und Failover-Richtlinie. Erforderlich für Proxy-LBs und neuere Passthrough-LBs.
Target pools: Legacy-Konstrukt für den klassischen externen NLB. Geeignet für einfache TCP/UDP-Verteilungen und heterogene VMs bei einem Lift-and-Shift.
Named ports: Schlüssel in Instanzgruppen, die logische Namen (z. B. http) auf Portnummern abbilden und von Backend-Diensten und URL-Maps referenziert werden. Stellen Sie die Konsistenz über alle Gruppenmitglieder hinweg sicher.

Systemdiagnosen und Failover:

Typen: HTTP(S), HTTP/2, gRPC, TCP, SSL. Wählen Sie eine Prüfung, die die tatsächliche Dienstbereitschaft validiert, nicht nur die Erreichbarkeit des Betriebssystems.
Geltungsbereich: Systemdiagnosen sind regional; jedes Backend sollte eine Systemdiagnose haben, deren Geltungsbereich auf die bereitstellende Region beschränkt ist.
Failover-Richtlinie: Der Backend-Dienst kann primäre und Failover-Backends festlegen. Der Traffic wird per Failover umgeleitet, wenn das primäre Backend fehlerhaft ist oder seine Kapazität erschöpft ist (sofern Failover-bei-Kapazitätserschöpfung aktiviert ist und der Schwellenwert erreicht wird). Berücksichtigen Sie Draining und Kapazitätsreservierung, um einen Thundering-Herd-Effekt zu vermeiden.

URL-Maps und Routing:

URL map wird an den externen oder internen HTTP(S)-LB angehängt und definiert Host-Regeln und Pfad-Matcher.
Standarddienst: Catch-all-Backend für Anfragen, die auf keine Regel passen; wenn nicht festgelegt, wird ein 404-Fehler zurückgegeben.
Weiterleitungen und Umschreibungen: Verwenden Sie URL-Map-Aktionen, um HTTPS-Weiterleitungen, kanonische Host-Weiterleitungen oder Pfad-Umschreibungen vor dem Routing durchzuführen.

Beispiel: Minimale URL-Map mit HTTPS-Weiterleitung und Standard-Backend

Erstellen Sie eine Host-Regel für example.com, leiten Sie HTTP auf HTTPS um, routen Sie /static zu einem CDN-fähigen Backend-Bucket und verwenden Sie standardmäßig einen regionalen Backend-Dienst.

Sitzungsaffinität und Draining:

Die Affinitätsoptionen hängen vom LB-Typ ab. Gängige Optionen sind:
- Keine: Am besten für zustandslose (stateless) Anwendungen; maximiert die Lastverteilung.
- Client IP: Sticky nach Quell-IP über L4/L7; verwenden, wenn mehrere Protokolle (z. B. HTTP und TFTP) gemeinsam an dasselbe Backend gebunden sein müssen.
- Generated cookie (nur L7): Der LB setzt ein Cookie, um die Sitzung an ein Backend zu binden; bessere Verteilung als Client-IP bei Clients hinter einem NAT.
Abwägungen: Affinität kann zu Hotspotting führen und die automatische Skalierung erschweren. Bevorzugen Sie nach Möglichkeit Zustandslosigkeit (Statelessness).
Connection draining: Bei der Herunterskalierung (Scale-in) oder Entfernung eines Backends berücksichtigt der LB das Draining-Timeout, damit bestehende Verbindungen ordnungsgemäß geschlossen werden können. Passen Sie die Draining-Zeit an Ihre längste erwartete Anfrage an, um Resets zu vermeiden.

Kapazität und automatische Skalierung:

Balancing-Modi: Basierend auf der Auslastung (z. B. CPU), RPS oder Verbindungen. Jedes Backend meldet seine Kapazität; der LB leitet bei Sättigung Last ab oder führt ein Failover durch.
Automatische Skalierung: Managed instance groups skalieren basierend auf Signalen (CPU, benutzerdefinierte Metriken). Eine Verzögerung bei der Hochskalierung (Scale-out) kann zu 503-Fehlern führen, wenn dem LB die Kapazität ausgeht; wärmen Sie durch eine Mindestanzahl von Replikaten oder durch prädiktive automatische Skalierung für tageszeitabhängigen Traffic vor.
Failover und Überlauf: Die Aktivierung von Failover-bei-Kapazitätserschöpfung mit einem geeigneten Schwellenwert ermöglicht einen reibungslosen regionsübergreifenden Überlauf.

Sicherheit bei Backends:

Beschränken Sie den Backend-Zugriff mithilfe von Firewall-Regeln, die auf Instanz-Tags oder Dienstkonten abzielen. Erlauben Sie nur Traffic von den Quellbereichen des Google Load Balancers und der Systemdiagnosen sowie von Ihren genehmigten Client-Bereichen, falls interner Client-Direktzugriff erforderlich ist.

Beispiel: Beschränkung von Clients und Systemdiagnosen auf eine mit einem Backend-Tag versehene Gruppe

Versehen Sie Instanzen mit dem Tag application.
Erstellen Sie eine Ingress-Allow-Regel für tcp:80 von Ihren Client-CIDRs und den Google-Systemdiagnosebereichen, die auf das Tag application abzielt.
Eine standardmäßige Ablehnung (Deny-by-default) wird empfohlen, um verworfenen Traffic in den Logs sichtbar zu machen.

Cloud CDN, Caching-Richtlinien und Origin-Schutz

Cloud CDN lässt sich in den externen Application Load Balancer integrieren, um Antworten an Edge-POPs zwischenzuspeichern. Dies reduziert die Latenz und entlastet die Kapazität des Origins.

Cache-Modi und TTLs:

Herkunfts-Header verwenden: Berücksichtigt Cache-Control und Expires von Ihrem Origin. Wird für die Korrektheit der Daten bevorzugt.
Caching erzwingen: Speichert alle Antworten mit einer konfigurierten Standard-TTL zwischen und überschreibt oder ignoriert optional die Origin-Header für statische Inhalte. Vorsichtig verwenden, um das Caching dynamischer Daten zu vermeiden.
Cache umgehen: Nützlich für Pfade, die niemals zwischengespeichert werden dürfen.

Cache-Schlüssel:

Die Schlüsselfelder umfassen Protokoll, Host, Pfad, Abfrageparameter, Header und Cookies. Konfigurieren Sie bei Bedarf die Richtlinie für Abfrage-Strings (alle einschließen, ausgewählte einschließen oder ignorieren), die selektive Einbeziehung von Headern und Cookies sowie die Gerätesegmentierung.
Halten Sie die Schlüssel minimal, um die Trefferquote zu maximieren; variieren Sie nur nach Feldern, die die Darstellung ändern.

Signierte Anfragen:

Signierte URLs: Fügen Sie eine HMAC- oder RSA-Signatur mit Ablaufzeit und Pfadgültigkeit hinzu, um zeitlich begrenzten Zugriff auf bestimmte Ressourcen zu gewähren. Gut geeignet für CDN-as-Accelerator mit Autorisierung auf Objektebene.
Signierte Cookies: Autorisieren Sie eine Reihe von Pfaden mit einem Cookie; nützlich für zugangsbeschränkte Inhalte der gesamten Website.
Rotieren Sie Schlüssel und erzwingen Sie kurze Ablaufzeiten, um das Risiko von Replay-Angriffen zu verringern.

Kompression und Korrektheit:

Origins müssen auch dann komprimieren, wenn Anfragen einen Via-Header enthalten. Wenn das CDN unkomprimierte Objekte ausliefert, während der Origin „Kompression unterstützt“, überprüfen Sie, ob der Origin so konfiguriert ist, dass er bei Vorhandensein des Via-Headers komprimiert.

Origin-Sicherheit:

Verwenden Sie HTTPS von den Edge-Proxys zu den Origins mit modernen TLS-Richtlinien.
Erreichbarkeit des Origins einschränken: Backend-Firewallregeln, die nur Traffic von den Quellbereichen des Google Load Balancers und der Systemdiagnose sowie von bekannten privaten Producern zulassen. Backend-Instanzen sollten keinen beliebigen öffentlichen Ingress-Traffic akzeptieren.
Kombinieren Sie es mit Cloud Armor für L7-DDoS/WAF, Ratenbegrenzung und Bedrohungserkennung. Verwenden Sie den Vorschaumodus für neue Regeln, um False Positives zu vermeiden.
Machen Sie Inhalte absichtlich über Cache-Invalidierungs-APIs ungültig, wenn Sie sie vor Ablauf der TTL entfernen müssen. Bevorzugen Sie für dynamische Inhalte kurze TTLs und eine Neuvalidierung (ETag/If-None-Match).

Fehlermodi und Kompromisse:

Zu weit gefasste Cache-Schlüssel verschwenden Cache-Speicher und senken die Trefferquote; zu eng gefasste Schlüssel bergen das Risiko, falsche Varianten auszuliefern.
Das Erzwingen des Cachings von dynamischen Daten kann personalisierte Inhalte preisgeben.
Signierte URLs/Cookies schützen den Zugriff am Edge, aber eine Umgehung des Origins muss dennoch durch eine Netzwerkrichtlinie unterbunden werden.

Globales Traffic-Management, DNS-Steuerung, Beobachtbarkeit und resiliente Einstiegspunkte

Anycast-Front-Doors und regionsübergreifendes Failover:

Der externe Application LB und der externe TCP Proxy LB verwenden globale Anycast-VIPs, um Clients zum nächstgelegenen Google-Edge zu leiten. Der Traffic wird dann an das fehlerfreiste und nächstgelegene Backend mit Kapazität weitergeleitet. Konfigurieren Sie mehrere Backend-Regionen mit konsistenten Zustandsprüfungen und Kapazitätseinstellungen für nahtloses Failover und Overflow.
Stellen Sie Kapazitäten in sekundären Regionen vorab bereit, um Cold-Start-Penalties zu vermeiden; koordinieren Sie die Min/Max-Werte des Autoscalers mit den Kapazitätsschwellenwerten des LB.

Regionales internes Traffic-Management:

Der interne HTTP(S) LB und der interne Passthrough LB sind regional; planen Sie für Zonenvielfalt innerhalb einer Region und, falls erforderlich, für Multi-Region-Setups unter Verwendung separater LBs mit Private Service Connect oder dienstsensitiven Clients, um regionale Endpunkte auszuwählen.
Halten Sie die Ost-West-Latenz niedrig, indem Sie kommunizierende Dienste in derselben Region und VPC platzieren. Verwenden Sie RFC1918-Adressierung mit einer einzigen VPC oder über Peering verbundenen VPCs für minimale Kosten und betriebliche Einfachheit.

Cloud DNS Routing-Richtlinien und Zustandsprüfungen:

Richtlinien: Weighted Round Robin (Traffic-Aufteilung), Geolocation (sendet Benutzer zur nächstgelegenen regionalen VIP) und Failover (primär/Backup). Kombinieren Sie Richtlinien, um Geschäftsregeln zu erfüllen.
Zustandsprüfungen: Fügen Sie DNS-Zustandsprüfungen (HTTP/HTTPS/TCP) zu A/AAAA-Records hinzu, die bei der Steuerung verwendet werden, damit fehlerhafte Endpunkte entfernt werden. Berücksichtigen Sie das Resolver-Caching (TTL), das die Reaktion verzögert; halten Sie die TTLs für gesteuerte Records niedrig, um die Reaktionsfähigkeit beim Failover auf Kosten von mehr DNS-Abfragen zu verbessern.
Traffic-Steuerung: Verwenden Sie gewichtete Richtlinien, um Migrationen phasenweise durchzuführen oder Last zwischen Regionen zu verschieben. Vermeiden Sie die Steuerung zu privaten Adressen aus dem Internet, es sei denn, Sie verwenden Split-Horizon-DNS.

Beobachtbarkeit und Diagnose:

Load-Balancer-Protokollierung: Aktivieren Sie die Protokollierung für alle LBs. HTTP(S)-Protokolle enthalten Anfragemethode/URI, Latenz, Cache-Treffer/-Fehlschläge, Backend-Dienst, URL-Map-Regel, TLS-Details und Antwortcodes. TCP/UDP-Protokolle liefern Verbindungsmetadaten und den Status von Zustandsprüfungen.
Metriken: Überwachen Sie den Zustand des Backends, die Auslastung, RPS, Verbindungen, Latenz, Cache-Trefferrate, 4xx/5xx-Raten und die Kapazitätssättigung. Richten Sie Alarme für plötzliche Änderungen und anhaltende Schwellenwertüberschreitungen ein.
Gängige HTTP(S)-Fehlermuster:
- 404: Keine Übereinstimmung in der URL-Map; überprüfen Sie Host-/Pfadregeln und den Standarddienst.
- 301/302: Beabsichtigte Weiterleitungen; auf Weiterleitungsschleifen prüfen.
- 502: Backend-Verbindungs- oder Protokoll-Inkompatibilität (z. B. HTTP/1.1 vs. gRPC); überprüfen Sie den Zustand und die Protokollkonfiguration des Backends.
- 503: Keine fehlerfreien Backends oder keine Kapazität; überprüfen Sie Zustandsprüfungen, Kontingente und das Verhalten des Autoscalers.
Request-Tracing: Verwenden Sie X-Forwarded-For, X-Forwarded-Proto und Trace-IDs, die von Ihrer Anwendung weitergegeben werden. Korrelieren Sie LB-Protokolle mit Backend-Protokollen über Request-IDs.
Firewall-Einblicke: Aktivieren Sie die VPC-Firewall-Protokollierung für Allow- und Deny-Regeln. Um explizit verworfene Pakete zu protokollieren, fügen Sie eine Deny-All-Regel mit niedriger Priorität und aktivierter Protokollierung hinzu.

Design resilienter globaler Einstiegspunkte:

Verwenden Sie eine einzige globale Anycast-VIP auf einem externen Application LB, der vor mehreren regionalen Backends steht. Platzieren Sie Serverless-/VM-/Container-Backends in mindestens zwei Regionen. Aktivieren Sie regionsübergreifendes Failover und Overflow, konfigurieren Sie konservative Zustandsprüfungen und passen Sie Draining und Timeouts für Ihre Workloads an.
Schützen Sie den Einstiegspunkt mit Cloud Armor und Richtlinien zur Kontingentbegrenzung. Verwenden Sie Cloud CDN für statische und zwischenspeicherbare dynamische Inhalte, um Traffic-Spitzen am Edge abzufangen.
Stellen Sie Dual-Stack IPv4/IPv6 auf dem globalen LB bereit, um alle Netzwerke zu bedienen. Wenden Sie für einen strengen Client-Zugriff Backend-Firewall-Regeln mit präzisen Quellbereichen und Instanz-Tags oder Service Accounts an.

Beispiel: Firewall-Regel zur Beschränkung von Client- und Zustandsprüfungsbereichen auf getaggte Backends

Taggen Sie Instanzen mit application.
Erstellen Sie eine Ingress-Allow-Regel für tcp:443 mit source-ranges=203.0.113.0/24,198.51.100.0/24 und den Google-Zustandsprüfungsbereichen, die auf application abzielen.
Stellen Sie sicher, dass eine Deny-All-Regel mit niedrigerer Priorität und Protokollierung existiert, um unerwartete Quellen zu erfassen.

Praktisches Problemszenario

Acme Retail startet eine globale E-Commerce-Plattform, die niedrige Latenz, hohe Sicherheit und transparentes Failover zwischen us-east1 und europe-west1 benötigt, während statische Medien effizient ausgeliefert werden. Nur Firmenbüros und ein Partner-CDN-Staging-Netzwerk sollen auf die private Admin-Oberfläche zugreifen können.

Front-Door und Backends

Erstellen Sie einen externen Application Load Balancer mit einer Dual-Stack-Anycast-VIP und TLS-Zertifikaten für den Hostnamen des öffentlichen Shops.
Definieren Sie zwei Backend-Dienste, die jeweils auf eine regionale verwaltete Instanzgruppe in us-east1 und europe-west1 verweisen. Aktivieren Sie Zustandsprüfungen (HTTPS) und stellen Sie den Balancing-Modus auf Auslastung mit einem Kapazitätsschwellenwert von 80 % ein. Begründung: Anycast plus Multi-Region-Backends stellen sicher, dass Benutzer den nächstgelegenen Edge erreichen und nahtlos ein Failover durchführen, wenn eine Region fehlerhaft oder überlastet ist.

URL-Map, Routing und Weiterleitungen

Konfigurieren Sie eine URL-Map mit Host-Regeln für die Hostnamen des öffentlichen Shops und des privaten Administrators. Leiten Sie /static zu einem Backend-Bucket mit aktiviertem Cloud CDN; leiten Sie /api und / zu den VM-Backends. Fügen Sie eine HTTP-zu-HTTPS-Weiterleitung hinzu. Begründung: Host-/Pfad-Routing trennt statischen von dynamischem Traffic und erzwingt sicheren Zugriff.

Cloud CDN-Richtlinie

Stellen Sie für den /static-Backend-Bucket den Cache-Modus auf die Verwendung von Origin-Headern ein und definieren Sie einen Cache-Schlüssel, der nicht funktionale Abfrageparameter ignoriert und nur den Accept-Encoding-Header enthält. Aktivieren Sie negatives Caching für häufige 404-Fehler mit einer kurzen TTL. Begründung: Respektiert die Semantik des Inhalts, maximiert die Trefferrate und vermeidet das Caching falscher Varianten.

Sitzungsaffinität und Draining

Legen Sie eine Affinität über generierte Cookies für den öffentlichen Shop und keine für statische Assets fest; setzen Sie das Connection Draining auf 60 Sekunden. Begründung: Cookies halten Warenkorb-Sitzungen stabil und ermöglichen gleichzeitig eine breite Verteilung; Draining verhindert für den Benutzer sichtbare Fehler während des Scale-In oder Failovers.

Regionsübergreifendes Failover und Autoscaling

Aktivieren Sie Failover bei Kapazitätsengpässen mit einem Overflow-Schwellenwert von 90 %, um überschüssige Last in die andere Region zu verlagern. Konfigurieren Sie das MIG-Autoscaling mit mindestens 4 Replikaten pro Region und CPU-Zielen, die der LB-Auslastung entsprechen. Begründung: Vermeidet Kapazitätsklippen und koordiniert die Entscheidungen von LB und Autoscaler für eine reibungslose Skalierung.

Beschränkung der Admin-Oberfläche

Erstellen Sie einen internen HTTP(S) Load Balancer für den Hostnamen des privaten Administrators, der nur innerhalb der VPC zugänglich ist. Veröffentlichen Sie Split-Horizon-Cloud-DNS, sodass interne Clients die ILB-VIP auflösen und externe Clients NXDOMAIN erhalten. Begründung: Hält den Admin-Traffic privat und kontrolliert, ohne öffentliche Endpunkte preiszugeben.

Backend-Firewall und Origin-Sicherheit

Taggen Sie Admin- und Web-Backends mit application und fügen Sie eine Allow-Regel für tcp:443 von den CIDRs des Unternehmens und des Staging-Netzwerks sowie den Quellbereichen des Google Load Balancers und der Zustandsprüfungen hinzu; fügen Sie eine Deny-All-Regel mit Protokollierung und niedrigerer Priorität hinzu. Begründung: Stellt sicher, dass nur beabsichtigte Clients und die Google-Infrastruktur die Backends erreichen können, und bietet Einblick in verworfene Pakete.

Cloud Armor

Wenden Sie eine Sicherheitsrichtlinie mit verwalteten WAF-Regeln und einem im Vorschaumodus befindlichen Ratenlimit für /api-Bursts an. Begründung: L7-Schutz und gestaffelte Durchsetzung reduzieren das Risiko während der Feinabstimmung.

Cloud DNS-Steuerung und Zustandsprüfungen

Veröffentlichen Sie A- und AAAA-Records für den Hostnamen des öffentlichen Shops, die auf die Anycast-VIP des ALB verweisen. Erstellen Sie für einen Blue/Green-Canary eine gewichtete Richtlinie für einen designierten Canary-Hostnamen, die 5 % auf den reinen europe-west1-ALB und 95 % auf das globale Deployment aufteilt. Fügen Sie HTTPS-Zustandsprüfungen hinzu, um den Canary bei Fehlerhaftigkeit zurückzuziehen, und setzen Sie die TTL auf 20 Sekunden. Begründung: Ein DNS-basierter Canary ermöglicht eine schrittweise Einführung mit zustandsabhängiger Entfernung und schneller Konvergenz.

Beobachtbarkeit

Aktivieren Sie LB- und CDN-Protokolle; exportieren Sie sie zur Analyse nach BigQuery. Richten Sie Alarme für die 5xx-Rate, die Backend-Kapazität, fehlgeschlagene Zustandsprüfungen und die CDN-Trefferrate ein. Verwenden Sie URL-Map-Tests und Anforderungsprotokolle zur Diagnose von Routing-Fehlern; untersuchen Sie 502/503-Spitzen auf Backend-Überlastung oder Protokoll-Inkompatibilitäten. Begründung: Proaktives Monitoring und schnelle Diagnose minimieren

← Hybride Konnektivität · Alle Domänen · Cloud DNS →

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