Google PCNE: VPC-Architektur, Subnetze und Adressplanung — 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

Eine Virtual Private Cloud (VPC) ist ein globales, logisch isoliertes Netzwerk, das sich über alle Google Cloud-Regionen erstreckt. Subnetze sind regionale Konstrukte innerhalb einer VPC und beherbergen IP-Bereiche, die Compute Engine, GKE und andere Ressourcen unterstützen. Eine solide VPC-Architektur schafft ein Gleichgewicht zwischen Adress-Effizienz, Wachstum und betrieblicher Kontrolle und gewährleistet gleichzeitig eine latenzarme, kostengünstige Konnektivität für projektinterne und projektübergreifende Workloads sowie zu Google APIs.

VPC-Geltungsbereich, Subnetz-Architektur und Modi

• Globale VPC, regionale Subnetze

  • Eine einzelne VPC erstreckt sich über alle Regionen. Subnetze werden pro Region erstellt und definieren primäre IPv4-CIDRs sowie optionale sekundäre Bereiche. Instanzen erhalten IPs aus regionalen Subnetzen, können aber standardmäßig privat über Regionen hinweg innerhalb derselben VPC kommunizieren.
  • Dynamischer Routing-Modus
    • Regional: Cloud Routers tauschen Routen nur mit Subnetzen in ihrer Region aus.
    • Global: Cloud Routers in einer Region kündigen erlernte Routen in allen Regionen an. Bevorzugen Sie den globalen Modus, wenn multiregionale Workloads oder HA-Egress erforderlich sind.

• Auto-Modus vs. benutzerdefinierter Modus

  • Der Auto-Modus erstellt ein Subnetz pro Region mit vordefinierten CIDRs. Er ist praktisch für einen schnellen Start, aber bei Skalierung unflexibel. Er kann in den benutzerdefinierten Modus konvertiert werden; die Konvertierung ist unumkehrbar.
  • Der benutzerdefinierte Modus bietet volle Kontrolle über die Erstellung von Subnetzen und die Wahl der CIDRs. Dies ist das empfohlene Muster für die Adressplanung in der Produktion, Shared VPC, Peering und Wachstum.
  • Hinweis zur Migration: Nach der Konvertierung von Auto zu benutzerdefiniert schlagen Artefakte oder Vorlagen, die von Auto-Subnetzen ausgingen, oft fehl, bis sie explizit aktualisiert werden, um auf benutzerdefinierte Subnetze zu verweisen.

• Unveränderlichkeit und Wachstum von Subnetzen

  • Die Region eines Subnetzes ist unveränderlich; Sie können ein Subnetz nicht zwischen Regionen verschieben.
  • Primäre IPv4-Bereiche können an Ort und Stelle erweitert (Präfix verbreitert), aber nicht verkleinert werden und müssen über die gesamte VPC und alle verbundenen Netzwerke hinweg überschneidungsfrei bleiben.
  • Sekundäre Bereiche können hinzugefügt oder entfernt werden (je nach Nutzung), müssen aber ebenfalls überschneidungsfrei sein.

Adressplanung: primäre/sekundäre Bereiche, Alias-IPs, IPv6 und privater Adressraum

• Primäre und sekundäre IPv4-Bereiche

  • Primärer Bereich: Weist VM-Schnittstellenadressen zu (standardmäßig nic0). Er erstellt eine systemgenerierte Subnetz-Route und wird für die meiste interne Kommunikation verwendet.
  • Sekundäre Bereiche: Verknüpfen zusätzliche CIDRs mit dem Subnetz und sind für VPC-native GKE-Cluster erforderlich. Systemgenerierte Routen für sekundäre Bereiche ermöglichen Ost-West-Konnektivität für Pods und Services.

• Alias-IPs

  • Alias-IPs ermöglichen es einer VM-NIC, mehrere IPs aus den primären oder sekundären Bereichen des Subnetzes zu besitzen, was eine strikte IP-basierte Richtliniendurchsetzung, Pod-IPs für VPC-native GKE und eine effiziente IP-Nutzung ermöglicht.
  • Planen Sie für GKE große, zusammenhängende sekundäre CIDRs, um Fragmentierung und zukünftige Größenänderungen zu minimieren. Beispiel: Für 100 Nodes mit 200 Pods/Node und 1500 Services weisen Sie einen sekundären Pod-Bereich von mindestens /17 und einen Services-Bereich von /21 zu, um Spielraum zu lassen.

• Design mit privatem RFC 1918 und IP-Management

  • Wählen Sie überschneidungsfreie Blöcke für alle aktuellen und geplanten VPCs, On-Premises-Umgebungen und Partner. Reservieren Sie große übergeordnete Blöcke für jede Umgebung und teilen Sie dann vorhersagbare Unterblöcke pro Region und pro Funktion auf.
  • Reservieren Sie Kapazität für Wachstum, sekundäre Bereiche, Migrationspuffer (temporäres Dual-Stack/Double NAT) und Infrastruktur-Endpunkte (ILB-VIPs, PSC-Endpunkte).
  • Vermeiden Sie die gängigsten Unternehmensblöcke, wenn eine Partnerkonnektivität wahrscheinlich ist, oder segmentieren Sie mit NAT, um Konflikte zu vermeiden.

• IPv6-Planung

  • Externes IPv6: Verwenden Sie globale externe IPv6-Adressen auf globalen Load Balancern für den Client-Zugriff und Anycast-Erreichbarkeit.
  • Internes IPv6: Wo verfügbar, aktivieren Sie Dual-Stack-Subnetze, um VMs interne IPv6-Adressen zuzuweisen, und passen Sie die Firewall-Regeln entsprechend an. Planen Sie DNS-AAAA-Records und stellen Sie die Parität mit der IPv4-Richtlinie sicher.
  • Behalten Sie IPv4 für cloud-interne Kontrollen und Integrationen von Drittanbietern bei; führen Sie IPv6 schrittweise über Load Balancer und Dual-Stack-Subnetze ein.

Routing: implizite Routen, benutzerdefinierte Routen, Prioritäten, Tags und nächste Hops

• Implizite (systemgenerierte) Routen

  • Subnetz-Routen: eine pro primärem Subnetz und pro sekundärem Bereich, Ziel entspricht dem CIDR, nächster Hop ist das Subnetz selbst.
  • Standardroute: 0.0.0.0/0 zum Standard-Internet-Gateway wird standardmäßig erstellt; Egress ins Internet erfordert eine externe IP oder NAT.

• Benutzerdefinierte Routen und Auswahl-Logik

  • Die längste Präfixübereinstimmung (Longest Prefix Match) gewinnt. Wenn mehrere Routen die gleiche Präfixlänge haben, gewinnt die niedrigste Prioritätsnummer (Standardpriorität 1000).
  • Tags und Dienstkonten
    • Routen ohne Tags gelten für alle VMs. Auf Tags bezogene Routen gelten nur für Instanzen mit passenden Netzwerk-Tags.
    • Identitätsbasierte Firewall-Regeln können auf Dienstkonten abgestimmt werden; verwenden Sie diese nach Möglichkeit für eine feinere Steuerung als mit Tags.

• Nächste Hops

  • Unterstützte nächste Hops für benutzerdefinierte Routen umfassen:
    • Standard-Internet-Gateway (0.0.0.0/0 oder spezifischere Egress-Präfixe)
    • Instanz (erfordert IP-Weiterleitung, um Verkehr für andere zu routen; wird für virtuelle Appliances verwendet)
    • Cloud VPN-Tunnel (statische Routen)
    • Regionaler interner Load Balancer als nächster Hop (für skalierbare Appliance-Muster)
  • Sie können den nächsten Hop nicht auf eine VPC-Peering-Verbindung setzen; Peering handhabt seinen eigenen Routenaustausch.

• Beispiel für Traffic-Steuerung (virtuelle Appliance)

  • Erstellen Sie eine spezifischere Route als die Subnetz-Route mit einem nächsten Hop zu einer Instanz mit IP-Weiterleitung, eingeschränkt durch Tags auf den Quell-VMs.

  • Beispiel:

undefined

• Egress zu Google APIs ohne externe IPs
  • Option 1: Aktivieren Sie Private Google Access (PGA) auf Subnetzen und fügen Sie dann benutzerdefinierte Routen für Google API VIPs zum Standard-Internet-Gateway hinzu, um bei Bedarf einen standardmäßigen Egress-Pfad eines Drittanbieters zu umgehen.
  • Option 2: Verwenden Sie Cloud NAT mit PGA, um Egress für private VMs zu Google-Diensten bereitzustellen.
  • Option 3: Verwenden Sie Private Service Connect zu Google APIs für eine internetfreie Nutzung; der Verkehr verbleibt im Google-Netzwerk und verwendet einen privaten RFC1918-Endpunkt in Ihrer VPC.
  • Für eingeschränkten Zugriff leiten Sie Clients zu den eingeschränkten (restricted) Google API VIPs und erzwingen Sie Egress-Kontrollen.

Shared VPC, Peering, delegierte Administration und Dienstkonten

• Shared VPC

  • Das Host-Projekt besitzt eine oder mehrere zentral verwaltete VPCs und Subnetze. Dienstprojekte binden Workloads an ausgewählte freigegebene Subnetze an.
  • Delegierte Administration
    • Der Shared VPC Admin konfiguriert Anbindungen (Attachments) und die Freigabe von Subnetzen.
    • Netzwerk-Admins verwalten Routen, Subnetze und die Firewall im Host-Projekt.
    • IAM auf Projektebene in Dienstprojekten steuert die Bereitstellung von Workloads; Sie können nur die erforderlichen Subnetze freigeben, um den „Blast Radius“ und die Sichtbarkeit von Routen einzuschränken.
  • Dienstkonten
    • Bevorzugen Sie auf Dienstkonten basierende Firewall-Richtlinien für eine deterministische, identitätsbasierte Steuerung über Teams hinweg.
    • Verwenden Sie dedizierte Dienstkonten pro Schicht (Tier) und Umgebung, mit Rollen nach dem Prinzip der geringsten Rechte (Least Privilege) für den Datenzugriff (z. B. gewähren Sie einem Dienstkonto, das aus Cloud Storage liest, die Rolle Storage Object Viewer).

• VPC Network Peering

  • Einschränkungen
    • Nicht-transitiv: A↔B und B↔C implizieren nicht A↔C. Erstellen Sie bei Bedarf ein Full-Mesh-Netzwerk.
    • Keine überlappenden IP-Bereiche zwischen den Peering-Netzwerken.
    • Der Austausch ist auf Subnetz-Routen beschränkt (einschließlich sekundärer Bereiche); eine Steuerung des nächsten Hops über Peering wird nicht unterstützt.
  • Verwenden Sie Peering für private Konnektivität mit geringer Latenz innerhalb einer Organisation mit minimalem Betriebsaufwand, wenn separate VPCs administrativ getrennt bleiben müssen.

• Hybride Konnektivität

  • Zentralisieren Sie Dedicated Interconnect und Cloud Router in einem Shared VPC-Host-Projekt, um Konnektivität mit hoher Kapazität mit den Dienstprojekten der Abteilungen zu teilen.
  • Verwenden Sie HA VLAN-Anhänge, verschiedene Edge-Standorte, duale Cloud Router und globales dynamisches Routing für Ausfallsicherheit und die Weitergabe (Propagation) an alle benötigten Regionen.

Betrieb: Erweiterung, HA, privater Zugriff, Verifizierung und Fehlerbehebung

• Einschränkungen bei der Subnetz-Erweiterung und -Migration

  • Führen Sie eine direkte Erweiterung durch, wenn sich ein Subnetz seiner Kapazitätsgrenze nähert; validieren Sie alle verbundenen Netzwerke auf Nicht-Überlappung und stellen Sie sicher, dass abhängige sekundäre GKE-Bereiche ausreichend bleiben.
  • Wenn sich Bereiche über Organisationen oder Partner hinweg überschneiden, verwenden Sie NAT oder eine gestaffelte Neunummerierung. Sie können keine überlappenden VPCs peeren oder überlappende dynamische Routen installieren.

• Regionale Platzierung und Hochverfügbarkeit

  • Platzieren Sie Subnetze in Regionen, die den Benutzern und Daten am nächsten sind. Für eine Benutzerbasis auf beiden Seiten des Atlantiks bietet eine einzelne VPC mit regionalen Subnetzen in us-east1 und europe-west1 direkte private Konnektivität mit optimaler Latenz und ohne Egress-Gebühren innerhalb der VPC.
  • Verteilen Sie Workloads über Zonen; verwenden Sie regionale verwaltete Instanzgruppen und regionale interne/externe Load Balancer für eine Toleranz gegenüber Zonenausfällen.
  • Für Hybrid-Umgebungen: Stellen Sie pro Region oder Edge-Standort zwei Cloud Router und Anhänge bereit; aktivieren Sie BFD, wo unterstützt; verwenden Sie globales dynamisches Routing für Failover.

• Privater Google-Zugriff und eingeschränkte Endpunkte

  • Aktivieren Sie PGA auf Subnetzen, die Instanzen ohne externe IPs hosten.
  • Um allgemeinen Internet-Egress zu verhindern und gleichzeitig Google APIs zu erlauben:
    • Leiten Sie den Standard-Traffic zu Ihrer NGFW.
    • Fügen Sie spezifischere statische Routen für Google API VIPs zum Standard-Internet-Gateway hinzu oder stellen Sie PSC-Endpunkte für Google APIs bereit.

  • Beispiel:

undefined

• Verifizierung der Topologie und Fehlerbehebung
  • Verwenden Sie das Network Intelligence Center:
    • Connectivity Tests, um die Erreichbarkeit zu validieren und Routing-, Firewall- und Gateway-Entscheidungen zu simulieren.
    • Performance Dashboard und Topology, um Pfade und den Zustand zu visualisieren.
  • Logs und Telemetrie:
    • VPC Flow Logs, um Zulassungen/Ablehnungen und Latenz pro Schnittstelle zu beobachten.
    • Firewall Rules Logging, um Übereinstimmungen mit Regeln zu bestätigen.
    • Cloud NAT-Logs und -Zustand für Egress-Probleme ohne externe IPs.
    • Load Balancer- und Health-Check-Logs für die Bereitschaft der Backends.

  • CLI-Prüfungen:

undefined

und

undefined

, um die wirksame Richtlinie zu bestätigen. -

undefined

und

undefined

von Test-VMs; verwenden Sie Packet Mirroring für eine tiefgehende Untersuchung bei Bedarf.

Praktisches Problemszenario

Die Acme Retail Group benötigt ein Multi-Region-Google-Cloud-Netzwerk mit niedriger Latenz, zentralisierter Steuerung, internetfreiem Zugriff auf Google APIs für private Instanzen und strikter Isolierung zwischen Abteilungen, die nicht miteinander kommunizieren müssen. Einige Teams betreiben GKE mit hoher Pod-Dichte. Acme leitet außerdem den allgemeinen Egress über eine Drittanbieter-Firewall, möchte aber, dass der Google-API-Traffic die Firewall umgeht.

1. Erstellen Sie eine einzelne Shared VPC in einem Host-Projekt im benutzerdefinierten Modus mit globalem dynamischem Routing und erstellen Sie regionale Subnetze in us-east1 und europe-west1 mit reservierten sekundären Bereichen für GKE.

• Begründung: Eine VPC bietet private, kostenlose, regionenübergreifende Konnektivität über RFC1918-Adressen für optimale Effizienz. Der benutzerdefinierte Modus und das globale dynamische Routing unterstützen eine präzise IP-Planung und eine regionenübergreifende Routenverteilung.

2. Geben Sie nur die spezifischen Subnetze für das Service-Projekt jeder Abteilung frei; erstellen Sie drei Service-Projekte (Sales, Finance, Marketing) und stellen Sie jedem nur die erforderlichen Subnetze zur Verfügung.

• Begründung: Die Freigabe pro Subnetz begrenzt den Auswirkungsbereich und die Routen-Exposition und erzwingt so die Isolierung, während gleichzeitig ein zentraler Betrieb ermöglicht wird. Delegiertes IAM ermöglicht es zentralen Netzwerkadministratoren, Firewalls und Routen zu verwalten, während Anwendungsteams Workloads unabhängig bereitstellen.

3. Für Abteilungen, die kommunizieren müssen, peeren Sie deren dedizierte VPCs oder platzieren Sie sie in denselben Shared-VPC-Subnetzen; für isolierte Abteilungen verzichten Sie auf Peering und geben Sie keine überlappenden Subnetze frei.

• Begründung: Peering bietet private Konnektivität mit niedriger Latenz bei minimalem Betriebsaufwand. Die Nicht-Transitivität erfordert explizite Mesh-Verbindungen nur dort, wo sie benötigt werden, was die Isolierung standardmäßig aufrechterhält.

4. Aktivieren Sie Private Google Access auf allen freigegebenen Subnetzen und stellen Sie Private Service Connect-Endpunkte für Google APIs bereit; behalten Sie die Standardroute zu einer Drittanbieter-Firewall bei und fügen Sie zusätzlich spezifischere statische Routen für Google API VIPs zum Standard-Internet-Gateway hinzu.

• Begründung: PGA und PSC ermöglichen die internetfreie Nutzung von APIs von privaten VMs aus. Die spezifischeren Routen stellen sicher, dass der API-Traffic die NGFW umgeht, während der Nicht-Google-Internet-Egress weiterhin den Inspektionspfad durchläuft.

5. Weisen Sie primäre und sekundäre CIDRs mit Wachstumsspielraum zu: Dimensionieren Sie für GKE einen sekundären Bereich für Pods (z. B. /17) und einen sekundären Bereich für Services (/21) pro ausgelasteter Region; verwenden Sie Alias-IPs für Pods und Services und erstellen Sie VPC-native Cluster, die an diese Bereiche gebunden sind.

• Begründung: Sekundäre Bereiche und Alias-IPs verhindern die Erschöpfung der Knoten-IPs und ermöglichen ein dichtes Scheduling. Die Dimensionierung für zukünftigen Bedarf vermeidet störende Größenänderungen und die Neunummerierung sekundärer Bereiche.

6. Implementieren Sie HA für Hybrid- und Appliance-Traffic: Stellen Sie bei Bedarf duale Cloud Router und HA VPN oder Interconnect bereit; wo eine Umleitung über eine virtuelle Appliance erforderlich ist, verwenden Sie eine spezifischere benutzerdefinierte Route, bei der der nächste Hop auf einen regionalen internen Load Balancer oder eine Instanz mit IP-Weiterleitung und tag-basierter Anwendbarkeit gesetzt ist.

• Begründung: HA am Edge stellt die Kontinuität bei Ausfällen sicher. Das Routen-Scoping nach Tags vermeidet unbeabsichtigtes Traffic-Hairpinning und lässt nur ausgewählte Instanzen den Appliance-Pfad durchlaufen.

7. Verifizieren und betreiben Sie mit Network Intelligence Center Connectivity Tests, VPC Flow Logs und Firewall Rules Logging; erzwingen Sie identitätsbasierte Firewall-Richtlinien mithilfe von Servicekonten und pflegen Sie IPAM-Aufzeichnungen mit reservierten Puffern pro Region und Funktion.

• Begründung: Proaktive Verifizierung verhindert Ausfälle bei Änderungen. Identitätsbasierte Richtlinien sind robuster als reine Tag-basierte Ansätze. IPAM-Disziplin verhindert Überlappungen, die Peering blockieren oder gelernte Routen unterdrücken würden.

Alle Domänen · Firewall-Richtlinien →

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

Google durchsuchen →