Google PCA: Vernetzung, Hybride Konnektivität und Traffic-Architektur — Lernleitfaden

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Übersicht

Netzwerk, hybride Konnektivität und Traffic-Architektur in der Google Cloud drehen sich um sicheres, skalierbares Virtual Private Cloud (VPC)-Design, zuverlässige hybride Verbindungen, intelligentes Traffic-Management und robuste Beobachtbarkeit (Observability). Das Ziel ist die Bereitstellung von resilienten Diensten mit niedriger Latenz, klarer Segmentierung, kontrolliertem Egress-Traffic und vorhersagbaren Fehlermodi. Dieser Abschnitt beschreibt praktische Designmuster, Abwägungen und betriebliche Anleitungen für die zentralen Netzwerkdienste der Google Cloud.

VPC-Architektur und Segmentierung

• Adressplanung und Subnetze

  • Verwenden Sie Custom-Mode-VPCs, um die Erstellung von Subnetzen und die IP-Adressierung zu steuern. Vermeiden Sie Standard-VPCs in der Produktion.
  • Weisen Sie frühzeitig nicht überlappende RFC1918-Blöcke zu. Berücksichtigen Sie zukünftiges Wachstum, Hochverfügbarkeitstopologien und hybride Erweiterungen. Reservieren Sie Bereiche für Dienste (z. B. Private Service Connect-Endpunkte) und für Peering/Interconnect.
  • Bevorzugen Sie kleinere Subnetze pro Funktion oder pro Umgebung gegenüber großen, flachen Netzwerken, um den Blast-Radius bei Ausfällen zu minimieren und die Firewall-Konfiguration zu vereinfachen.

• Routen

  • Jede VPC hat eine System-Routingtabelle; Routen werden nach dem Longest-Prefix-Match und dann nach Priorität ausgewertet. Von Google verwaltete Routen umfassen die Standard-Internetroute (falls externe IPs vorhanden sind) und Subnetzrouten. Dynamische Routen werden über Cloud Router mit On-Premises-Umgebungen ausgetauscht.
  • Setzen Sie benutzerdefinierte statische Routen sparsam ein; verlassen Sie sich wo immer möglich auf dynamisches Routing, um die Resilienz zu erhöhen. Vermeiden Sie Blackhole-Routen, es sei denn, sie dienen als bewusste Kontrollmaßnahme.

• Firewallregeln

  • Die VPC-Firewall ist zustandsbehaftet (stateful) und wird nach Priorität ausgewertet, mit einem impliziten „Deny“ am Ende. Das Targeting erfolgt über Netzwerk-Tags oder Dienstkonten; das Targeting über Dienstkonten bietet stärkere Identitätsgarantien als Tags.
  • Trennen Sie Zulassungsregeln nach ihrem Zweck (Health Checks, Intra-Tier, Admin) und beschränken Sie ihren Geltungsbereich auf Quell-Dienstkonten oder IP-Bereiche.
  • Protokollieren Sie Firewall-Entscheidungen für kritische Regeln in Cloud Logging, um die Forensik und Leistungsanalyse zu unterstützen.

• Hierarchische Firewall-Richtlinien und Organisationsrichtlinien

  • Hierarchische Firewall-Richtlinien gelten auf Organisations- oder Ordnerebene und werden vor den Regeln auf VPC-Ebene ausgewertet. Verwenden Sie sie, um globale Leitplanken zu setzen (z. B. SSH von 0.0.0.0/0 verbieten), die Projekte nicht überschreiben können. Pre- und Post-Richtlinien bieten Flexibilität, aber Ablehnungen (Denies) auf höheren Ebenen können nicht außer Kraft gesetzt werden.
  • Ergänzen Sie dies mit Einschränkungen durch Organisationsrichtlinien (z. B. die Erstellung externer IPs einschränken, die Erstellung von VPC-Peering durch Projekte verbieten), um Governance durchzusetzen.

• Shared VPC und Segmentierung

  • Verwenden Sie Shared VPC, um das Netzwerk in Host-Projekten zu zentralisieren, während Workloads in Dienstprojekten isoliert bleiben. Dieses Muster reduziert doppelte Egress-Pfade, standardisiert Kontrollen und vereinfacht den hybriden Transit.
  • Isolieren Sie Umgebungen (Prod, Non-Prod) in separaten Host-Projekten oder Ordnern; setzen Sie die Segmentierung mit hierarchischen Richtlinien und separaten Subnetzen durch. Beschränken Sie IAM, sodass nur NetOps-Teams die Ressourcen des Host-Projekts verwalten.

• VPC Network Peering

  • Peering ist privat, skalierbar und hat eine niedrige Latenz, ist aber nicht-transitiv. Es eignet sich am besten zur Verbindung autonomer Netzwerke oder von Drittanbietern verwalteter Dienste. Vermeiden Sie den Aufbau von Transit-Hubs mit Peering; verwenden Sie stattdessen das Network Connectivity Center für den Transit oder eine zentralisierte Shared VPC.
  • Einschränkungen: keine überlappenden IPs; bestimmte Routen (z. B. die Standard-Internetroute) und einige Dienste werden nicht propagiert. Verstehen Sie beim Entwurf den Import/Export von benutzerdefinierten Routen.

Abwägungen und Fehlermodi:

• Überlappende IP-Bereiche blockieren Peering und den Austausch hybrider Routen; lösen Sie dies durch Umnummerierung oder NAT.
• Übermäßig freizügige Firewallregeln oder fehlende Regeln für Health Checks verursachen Ausfälle und schwer zu diagnostizierendes Verhalten.
• Statische Routen schaffen brüchige Abhängigkeiten; bevorzugen Sie Cloud Router für das Failover.

Traffic-Management, DNS und Edge-Sicherheit

• Cloud Load Balancing-Muster

  • Der External HTTP(S) Load Balancer ist ein globales Anycast mit einer einzigen Anycast-VIP, regionsübergreifendem Failover, Pfad- und Host-basiertem Routing sowie CDN/Armor-Integration. Wird für Web- und API-Workloads mit Internetzugriff verwendet.
  • Der Internal HTTP(S) Load Balancer ist regional und für den Service-zu-Service-Traffic innerhalb einer VPC oder über Private Service Connect vorgesehen.
  • Der External/Internal TCP/UDP Network Load Balancer ist ein regionaler L4-Load-Balancer; wird für Nicht-HTTP-Protokolle oder dort eingesetzt, wo die Beibehaltung der Quell-IP erforderlich ist.
  • Backend-Dienste und Netzwerk-Endpunktgruppen (NEGs): Verwenden Sie zonale Instanzgruppen-Backends für VM-Pools; verwenden Sie zonale, regionale oder serverlose NEGs für GKE, hybride Backends oder Cloud Run. Erstellen Sie separate Backend-Dienste pro Traffic-Klasse, Systemdiagnoseprofil oder Kapazitätsrichtlinie. Beispiel: Stellen Sie alte und neue API-Versionen unter demselben Hostnamen bereit, indem Sie das Routing über Pfade zu unterschiedlichen Backend-Diensten leiten, sodass beide bereitstellbar und unabhängig skalierbar bleiben.

• Systemdiagnosen und häufige Fallstricke

  • Systemdiagnosen müssen von der Firewall zugelassen werden. Für externe HTTP(S)-Systemdiagnosen müssen die IP-Bereiche 130.211.0.0/22 und 35.191.0.0/16 für die Backends freigegeben werden. Eine fehlende Regel führt dazu, dass Backends als fehlerhaft markiert werden und VMs schnell neu gestartet werden, wenn das Autoscaling auf Signale des Load Balancers reagiert.
  • Gleichen Sie die Pfade und Ports der Systemdiagnose mit den Readiness-Endpunkten der Container ab; legen Sie Zeitüberschreitungen und Schwellenwerte fest, um ein Gleichgewicht zwischen schnellem Failover und Fehlalarmen (False Positives) zu finden.

• DNS-Architektur

  • Verwenden Sie Cloud DNS für autoritative Zonen. Erstellen Sie private Zonen für interne Namen; erstellen Sie öffentliche Zonen für Namen im Internet.
  • Split-Horizon-DNS: Beantworten Sie interne und externe Anfragen unterschiedlich, indem Sie separate öffentliche und private Zonen mit identischen Namen erstellen. Dies unterstützt sicher private Dienst-Hostnamen und öffentlich zugängliche Einträge.
  • Weiterleitungs- und Peering-Zonen: Integrieren Sie mit On-Premises-DNS, indem Sie DNS-Richtlinien und Serverrichtlinien verwenden, um Abfragen für bestimmte Domains weiterzuleiten; verwenden Sie bedingte Weiterleitung, um Rekursionsschleifen zu vermeiden.
  • Service Discovery: Führen Sie einheitliche Namenskonventionen pro Umgebung und Dienst ein. Für GKE sollten Sie Headless Services mit Cloud DNS oder die Zuordnung von Dienstendpunkten über den Internal HTTP(S) Load Balancer und private DNS-Namen in Betracht ziehen.

• Edge-Caching und -Schutz

  • Cloud CDN lagert zwischenspeicherbare Inhalte an den Edge aus, wodurch die Latenz zum Ursprungsserver und die Egress-Kosten reduziert werden. Legen Sie Cache-Schlüssel, TTLs und negatives Caching sorgfältig fest; umgehen Sie das Caching für personalisierte oder dynamische Endpunkte.
  • Cloud Armor bietet WAF, Ratenbegrenzung und Geo-/IP-basierte Zugriffskontrolle. Weisen Sie Sicherheitsrichtlinien den Load Balancern zu; überwachen Sie die Protokolle der Regeltreffer. Verwenden Sie vorkonfigurierte Regeln für gängige CVEs und benutzerdefinierte Signaturen für anwendungsspezifische Bedrohungen.
  • Die TLS-Terminierung am Load Balancer zentralisiert die Zertifikatsverwaltung; aktivieren Sie, wo möglich, die automatische Zertifikatsbereitstellung und verwaltete Erneuerungen.

Betriebliche Hinweise:

• Versionierte APIs: Implementieren Sie pfad- oder hostbasiertes Routing zu separaten Backend-Diensten, damit jede Version unabhängig mit Blue-Green- oder Canary-Mustern ausgerollt werden kann.
• Verwenden Sie Request-Header und Cookies für A/B-Tests über Traffic-Steuerungsrichtlinien; stellen Sie immer sicher, dass Protokollierung/Metriken mit der korrekten Backend-Identität korrelieren.

Beobachtbarkeit, Zuverlässigkeit, Betrieb und Kontrollen

• Netzwerk-Beobachtbarkeit

  • VPC Flow Logs: Auf Subnetz-Ebene aktivieren und Sampling- sowie Metadaten-Optionen anpassen. Zur Erstellung von Traffic-Baselines, Egress-Analysen und zur Bedrohungssuche (Threat Hunting) verwenden. Für Langzeitanalysen nach BigQuery exportieren.
  • Protokollierung von Firewall-Regeln: Bei kritischen Regeln aktivieren, um erlaubten und verweigerten Traffic zu erfassen; mit Flow Logs korrelieren, um Fehlkonfigurationen zu erkennen.
  • Connectivity Tests: Quell-Ziel-Pfade modellieren, um Erreichbarkeit, Routenauswahl und Firewall-Auswertung zu validieren. In CI/CD integrieren, um Abweichungen (Drift) vor der Bereitstellung zu erkennen.
  • Health-Dashboards: Backend-Zustand des Load Balancers, Port-Auslastung von Cloud NAT, BGP-Sitzungsstatus des Cloud Router und Auslastung von Interconnect überwachen. Bei Abweichungen alarmieren.

• Zuverlässigkeitsmuster und häufige Ausfallmodi

  • Zonale Resilienz: Backends auf mindestens zwei Zonen verteilen; verwaltete Instanzgruppen (Managed Instance Groups) oder multizonale GKE-Knotenpools verwenden. Validieren, dass Zustandsprüfungen (Health Checks) und Firewall-Tags für alle Zonen gelten.
  • Routing-Resilienz: Globales dynamisches Routing und mehrere Cloud Router für regionenübergreifende Konnektivität verwenden. Blackhole-Szenarien testen und sicherstellen, dass das Monitoring Routen-Rückzüge abdeckt.
  • DNS-Resilienz: Standardmäßig mehrere Nameserver mit Cloud DNS bereitstellen; bei hybriden Setups sicherstellen, dass Forwarder redundant sind und Single Points of Failure in On-Premise-Resolvern vermieden werden. Split-Horizon-Fehlkonfigurationen verhindern, die nicht routbare Antworten von der falschen Seite zurückgeben.
  • Sicherheit am Edge: Cloud Armor-Ratenbegrenzungen anwenden, um den Ursprungsserver vor Überlastungsangriffen (Floods) zu schützen. Andernfalls können Autoscaling-Stürme und Kostenspitzen ausgelöst werden.

• Kostenkontrollen

  • Regionenübergreifende Aufrufe minimieren, internes Load Balancing für Intra-VPC-Traffic bevorzugen und PSC für Producer-Consumer-Traffic in Betracht ziehen, um NAT-Egress zu vermeiden.
  • Cloud CDN für statische und semi-statische Assets verwenden; Cache-Fähigkeit optimieren. Interconnect-Kapazität so dimensionieren, dass nicht für ungenutzte Reserven zu viel bezahlt wird; Traffic-Daten zur richtigen Dimensionierung von Commits verwenden.

Operative Snippets:

• Zustandsprüfungen des Load Balancers für private Backends zulassen:

undefined

• Privaten Google-Zugriff für ein Subnetz aktivieren:

undefined

• Einen Cloud Router für HA VPN erstellen:

undefined

Praktisches Problemszenario

Contoso Retail plant die Einführung einer globalen E-Commerce-API mit Zero-Downtime-Versionierung, strikter privater Konnektivität zu Back-Office-Systemen und ohne öffentliche IPs auf den Anwendungs-VMs. Die Lösung muss DDoS-Schutz, Edge-Caching und einen zuverlässigen hybriden Zugriff von zwei Rechenzentren aus bieten.

Ansatz:

1. Entwurf der VPC und Segmentierung

• Ein Shared VPC Host-Projekt im benutzerdefinierten Modus mit dedizierten Subnetzen pro Schicht (Web, API, Daten) in zwei Regionen erstellen. Begründung: Shared VPC zentralisiert die Steuerung, während Dienstprojekte die Teams isolieren. Subnetze pro Schicht ermöglichen Firewalling nach dem Prinzip der geringsten Rechte (Least Privilege) und kleinere Fehlerdomänen.
• Hierarchische Firewall-Richtlinien auf Organisationsebene anwenden, um eingehenden SSH-Verkehr aus dem Internet zu verweigern und ausgehenden Verkehr auf erlaubte Ziele zu beschränken. Begründung: Globale Leitplanken reduzieren das Risiko von Fehlkonfigurationen in Projekten.

2. Implementierung von pfadbasiertem globalem Ingress und API-Versionierung

• Einen externen HTTP(S) Load Balancer mit einer einzelnen Anycast-IP und HTTPS-Terminierung bereitstellen. URL-Maps konfigurieren, um /v1/* und /v2/* an separate Backend-Dienste weiterzuleiten, die durch regionale zonale NEGs gestützt werden. Begründung: Getrennte Backend-Dienste ermöglichen eine unabhängige Bereitstellung und ein unabhängiges Rollback für jede API-Version unter einem Hostnamen und TLS.
• Cloud Armor WAF und Ratenbegrenzungen anfügen; Cloud CDN für zwischenspeicherbare Endpunkte (z. B. Produktbilder) aktivieren. Begründung: Schützt den Ursprungsserver und reduziert Latenz- und Egress-Kosten.

3. Sicherstellung der Backend-Erreichbarkeit und des Backend-Zustands

• Eine Firewall-Regel erstellen, um Zustandsprüfungen (Health Checks) des Load Balancers zu den API-Instanzgruppen auf den erwarteten Ports zuzulassen. Begründung: Ohne diese Regel schlagen die Zustandsprüfungen fehl, und Autoscaler können instabil werden, da Instanzen als fehlerhaft eingestuft werden.
• Instanzen auf zwei Zonen pro Region verteilen; Schwellenwerte für Zustandsprüfungen konservativ einstellen, um “Flapping” (schnelle Zustandswechsel) zu vermeiden. Begründung: Zonale Diversität und stabile Zustandsrichtlinien verbessern die Verfügbarkeit.

4. Aufbau von DNS mit Split-Horizon und Service Discovery

• Eine öffentliche Cloud DNS-Zone für contoso.com und eine private Zone mit demselben Namen für nur interne Einträge (z. B. db.internal.contoso.com) erstellen. Begründung: Split-Horizon verhindert das Durchsickern interner Namen nach außen, während eine konsistente Namensgebung beibehalten wird.
• DNS-Richtlinien konfigurieren, um On-Premise-Abfragen für corp.local an das Unternehmens-DNS weiterzuleiten und private Zonen in Anwendungsprojekte zu importieren. Begründung: Nahtlose Auflösung über hybride Grenzen hinweg ohne Rekursionsschleifen.

5. Herstellung hybrider Konnektivität mit Redundanz

• In jeder Region zwei HA VPN-Tunnel zu jedem Rechenzentrum bereitstellen, jedes Paar auf separaten Cloud Routern mit BGP. Wenn Kapazitäts- und SLA-Anforderungen es rechtfertigen, Partner Interconnect mit redundanten Anhängen in separaten Edge-Zonen hinzufügen. Begründung: Mehrere verschiedene Pfade bieten Failover; BGP ermöglicht eine schnelle Konvergenz und einen dynamischen Routenaustausch.
• Globales dynamisches Routing in der Shared VPC verwenden und Routenfilter anwenden, um die Verbreitung unerwünschter On-Premise-Präfixe zu verhindern. Begründung: Konsistentes Routing über Regionen hinweg bei gleichzeitiger Reduzierung des Risikos von Routen-Leaks.

6. Bereitstellung von privatem Zugriff auf Google APIs und ausgehendem Internetverkehr

• Privaten Google-Zugriff auf App-Subnetzen aktivieren und Private Service Connect-Endpunkte für Google APIs konfigurieren, die von Batch-Jobs verwendet werden. Cloud NAT für ausgehenden Nicht-API-Verkehr verwenden, wo erforderlich. Begründung: Backends behalten keine öffentlichen IPs, können aber dennoch notwendige Dienste erreichen; PSC vereinfacht die Namensauflösung mit privatem DNS.

7. Zentralisierung von Transit und Konnektivität von Drittanbietern

• Einen Network Connectivity Center-Hub im Host-Projekt erstellen; HA VPNs, Interconnect-Anhänge und alle SD-WAN-Spokes anfügen. Begründung: Ein Hub-and-Spoke-Transit vereinfacht die Routenverteilung zwischen mehreren VPCs und externen Netzwerken im Vergleich zu Peering-Meshes.

8. Implementierung von Beobachtbarkeit und Leitplanken

• VPC Flow Logs auf allen Subnetzen mit angemessenem Sampling aktivieren; Firewall-Protokolle für kritische Regeln aktivieren; nach BigQuery exportieren. Connectivity Tests in CI/CD verwenden, bevor neue Firewall- oder Routenänderungen ausgerollt werden. Begründung: Tiefe Einblicke unterstützen Fehlerbehebung, Kapazitätsplanung und Auditierbarkeit.
• Alarme für BGP-Sitzungsabbrüche des Cloud Router, Port-Erschöpfung bei Cloud NAT, Einbrüche des Backend-Zustands und Treffer bei Cloud Armor-Regeln einrichten. Begründung: Die Früherkennung von Ausfällen und Angriffen reduziert die MTTR (Mean Time to Repair).

9. Optimierung von Leistung und Kosten

• Stateful-Dienste und Compute in derselben Region platzieren (Co-Location); statische Inhalte mit Cloud CDN am Edge zwischenspeichern. Begründung: Minimiert die RTT und den regionenübergreifenden Egress.
• Flow Logs regelmäßig überprüfen, um zonenübergreifende Kommunikation (“Chatter”) zu identifizieren und die Platzierung oder Dienstgrenzen anzupassen. Begründung: Reduziert unnötigen Egress und Latenz.

Dieser Entwurf bietet ein globales, sicheres Ingress mit versioniertem Routing, eine resiliente hybride Konnektivität mit dynamischem Failover, privaten Zugriff auf erforderliche Dienste und eine umfassende Beobachtbarkeit, während gleichzeitig Latenz- und Egress-Kosten kontrolliert werden.

← Datenspeicherung · Alle Domänen · Sicherheit →

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

Google durchsuchen →