Handbuch

Planen Sie die IP-Adressierung für große oder hybride Cloud-Bereitstellungen.

→Verwenden Sie VPCs im benutzerdefinierten Modus. Weisen Sie nicht überlappende RFC 1918 CIDR-Blöcke (z.B. 172.16.0.0/12) zu, um Konflikte mit On-Prem-Umgebungen (oft 10.0.0.0/8) zu vermeiden. Verwenden Sie 100.64.0.0/10 für sekundäre GKE Pod-Bereiche.

Warum: Vermeidet IP-Konflikte mit On-Prem für zukünftige Hybridkonnektivität und bietet volle Kontrolle über den Adressraum, was für Skalierbarkeit und die Vermeidung kostspieliger Re-IP-Adressierungen unerlässlich ist.

Referenz↗

Bieten Sie Netzwerkisolation für mehrere Mandanten/Umgebungen (Entwicklung, Produktion) bei gleichzeitiger Zentralisierung der Netzwerkverwaltung und gemeinsamer Dienste.

→Verwenden Sie Shared VPC. Das Hostprojekt enthält die VPC, Subnetze, Firewalls und Interconnects. Mandanten/Umgebungen sind Serviceprojekte, die an das Hostprojekt angehängt sind.

Warum: Zentralisiert die Netzwerkadministration im Hostprojekt und delegiert gleichzeitig die Ressourcenverwaltung an Serviceprojekte. Skalierbarer und besser verwaltbar als VPC-Peering für viele Projekte innerhalb einer Organisation.

Referenz↗

Planen Sie die IP-Adressierung für große GKE-Cluster mit VPC-nativer Vernetzung.

→Planen Sie in einer VPC im benutzerdefinierten Modus drei CIDR-Bereiche: einen primären Bereich für Nodes, einen sekundären Bereich für Pods und einen weiteren für Services. Verwenden Sie für die Erweiterung nicht zusammenhängende Multi-Pod-CIDR.

Warum: VPC-native Vernetzung erfordert dedizierte, nicht überlappende sekundäre Bereiche für Pods und Services. Die richtige Dimensionierung verhindert die IP-Erschöpfung, ein häufiges und störendes Problem in großen Clustern.

Referenz↗

VMs ohne externe IPs müssen auf Google Cloud APIs zugreifen (z.B. Cloud Storage, BigQuery).

→Aktivieren Sie Private Google Access im Subnetz. Konfigurieren Sie optional DNS, um `*.googleapis.com` auf `restricted.googleapis.com` (199.36.153.4/30) aufzulösen, um VPC-SC zu erzwingen.

Warum: Leitet den Traffic zu Google APIs über das interne Google-Netzwerk, ohne öffentliche IPs auf VMs zu erfordern. Die Verwendung von `restricted.googleapis.com` fügt eine Ebene des Datenschutzes vor Datenexfiltration hinzu.

Referenz↗

Bieten Sie privaten Zugriff auf einen Dienst in Ihrer VPC für Consumer (Partner, andere Geschäftseinheiten), deren VPCs überlappende IP-Bereiche aufweisen.

→Veröffentlichen Sie den Dienst (über einen Internal Load Balancer) mithilfe eines Private Service Connect (PSC) Service-Anhangs. Consumer erstellen einen PSC-Endpunkt in ihrer VPC mit einer IP aus ihrem eigenen Bereich.

Warum: PSC entkoppelt Produzenten- und Consumer-Netzwerke und verwendet NAT, um überlappende IPs zu verwalten. Es bietet sicheren, dienstbasierten Zugriff, nicht vollständige Netzwerkkonnektivität wie VPC-Peering.

Referenz↗

Verbinden Sie eine große Anzahl (50+) von VPCs und/oder On-Prem-Standorten in einer Hub-and-Spoke-Topologie für zentralisierte Verwaltung und Konnektivität.

→Verwenden Sie Network Connectivity Center. Konfigurieren Sie den Hub und verbinden Sie VPCs als VPC Spokes und On-Prem-Verbindungen (VPN/Interconnect) als Hybrid Spokes.

Warum: NCC ist Googles verwaltete Lösung für große Hub-and-Spoke-Topologien, die die Routenverwaltung vereinfacht und über die 25-Peer-Grenze von VPC-Peering hinaus skaliert.

Stellen Sie einen GKE-Cluster bereit, bei dem Nodes und die Steuerungsebene zur Verbesserung der Sicherheit keine öffentlichen IP-Adressen haben.

→Erstellen Sie einen Private GKE Cluster. Dies weist Nodes nur interne IPs zu und erstellt einen privaten Endpunkt für die Steuerungsebene. Konfigurieren Sie autorisierte Netzwerke, um den Zugriff auf die Steuerungsebene einzuschränken.

Warum: Ein privater Cluster entfernt die Steuerungsebene und Nodes aus dem öffentlichen Internet, wodurch die Angriffsfläche erheblich reduziert wird. Der gesamte Verwaltungs- und Workload-Traffic bleibt im privaten Netzwerk.

Serverless-Workloads (Cloud Run, Functions) müssen auf Ressourcen (z.B. Cloud SQL, Memorystore) innerhalb einer VPC zugreifen.

→Erstellen Sie einen Serverless VPC Access Connector in der Ziel-VPC. Konfigurieren Sie den serverless-Dienst so, dass er diesen Connector für den ausgehenden Traffic verwendet.

Warum: Der Connector fungiert als Proxy, der serverless-Diensten (die in einer von Google verwalteten Umgebung ausgeführt werden) ermöglicht, Traffic unter Verwendung interner IPs in eine vom Kunden verwaltete VPC zu senden.

Eine Anwendung (z.B. HPC, Finanzhandel) erfordert die absolut niedrigste Netzwerklatenz zwischen einer Gruppe von VMs.

→Erstellen Sie eine kompakte Platzierungsrichtlinie und wenden Sie diese auf die VMs an. Verwenden Sie Maschinentypen mit Tier_1-Networking.

Warum: Die Kollokation von VMs im selben Netzwerk-Rack minimiert Netzwerk-Hops und physische Entfernung, wodurch die Latenz im Vergleich zur Standard-VM-Platzierung erheblich reduziert wird.

Implementieren Sie ein Zero-Trust-Sicherheitsmodell für Microservices, das starke Identität, verschlüsselte Kommunikation (mTLS) und feingranulare Autorisierung erfordert.

→Stellen Sie Anthos Service Mesh bereit. Aktivieren Sie automatisches mTLS für die gesamte Service-zu-Service-Kommunikation. Verwenden Sie `AuthorizationPolicy`-Ressourcen, um die erlaubte Kommunikation zu definieren.

Warum: Ein Service Mesh entkoppelt die Sicherheit vom zugrunde liegenden Netzwerk und bietet Workload-Identität, transparentes mTLS und L7-Autorisierung, die Kernpfeiler einer Zero-Trust-Architektur sind.

Workloads (VMs, GKE Pods) ohne öffentliche IPs benötigen eine stabile, vorhersehbare Quell-IP für ausgehende Verbindungen zu externen APIs, die Allow-Lists verwenden.

→Stellen Sie Cloud NAT bereit. Verwenden Sie die Option "manuelle NAT-IP-Zuweisung" und weisen Sie reservierte statische externe IP-Adressen dem NAT-Gateway zu.

Warum: Cloud NAT mit manueller Zuweisung bietet einen gemeinsamen Pool statischer Egress-IPs. Dies entkoppelt den Workload von der IP und ermöglicht die Skalierung, ohne externe Allow-Lists aktualisieren zu müssen.

VPC-Peering ist eingerichtet, aber VMs können nicht zwischen den gepeerten VPCs kommunizieren.

→Überprüfen Sie, ob Firewall-Regeln in *beiden* VPCs eingehenden Traffic aus dem IP-Bereich der anderen VPC zulassen. Die Peering-Verbindung stellt nur das Routing her; sie erstellt keine impliziten Firewall-Zulassungen.

Warum: Ein häufiger Fehler ist die Annahme, dass Peering Firewall-Ports öffnet. Die implizite Deny-All-Ingress-Regel blockiert Traffic, bis eine explizite Allow-Regel erstellt wird.

Erteilen Sie in einer Shared VPC einem Team/Serviceprojekt die Berechtigung, nur ein bestimmtes Subnetz zu verwenden, nicht die gesamte VPC.

→Erteilen Sie im Hostprojekt der Identität des Serviceprojekts (z.B. Servicekonto, Gruppe) die IAM-Rolle `compute.networkUser` auf Subnetzebene.

Warum: IAM-Rollen können auf bestimmte Ressourcen zugeschnitten werden. Die Anwendung von `compute.networkUser` auf Subnetzebene erzwingt das Prinzip der geringsten Rechte und erlaubt die Nutzung nur dieses Subnetzes.

Implementieren Sie Mikrosegmentierung für eine mehrschichtige Anwendung (z.B. Web, App, DB) auf Compute Engine.

→Weisen Sie VMs Netzwerk-Tags basierend auf ihrer Schicht zu (z.B. `web-server`). Erstellen Sie Firewall-Regeln, die diese Tags als Quell- und Zielspezifizierer verwenden.

Warum: Tags bieten eine flexible, skalierbare Alternative zu IP-basierten Regeln. Die Firewall-Richtlinie ist unabhängig von der Anzahl oder den IPs der VMs in einer Schicht.

Erfassen Sie Verkehrsmetadaten für Compliance/Auditing und minimieren Sie gleichzeitig das Protokollvolumen und die Speicherkosten.

→Aktivieren Sie VPC Flow Logs mit einem längeren Aggregationsintervall (z.B. 10 Minuten), einer reduzierten Sampling-Rate (z.B. 0.5) und Metadatenfilterung, um nicht benötigte Felder auszuschließen.

Warum: Die Standardeinstellungen erzeugen riesige Datenmengen. Das Anpassen dieser Parameter reduziert die Kosten erheblich, während für die meisten Audit-Anwendungsfälle noch ausreichende Sichtbarkeit gegeben ist.

Stellen Sie eine globale Anwendung mit geringer Latenz bereit, die Benutzer mit automatischem Failover an das nächstgelegene fehlerfreie Backend weiterleitet.

→Verwenden Sie einen Global External Application Load Balancer (oder TCP/SSL Proxy LB für Nicht-HTTP). Konfigurieren Sie Backend-Dienste/NEGs in mehreren Regionen. Verwenden Sie Premium Tier Networking.

Warum: Die Anycast-IP des Load Balancers leitet Benutzer an den nächstgelegenen Google Edge PoP. Der Traffic reist dann über Googles privates Backbone zum nächstgelegenen fehlerfreien Backend für optimale Leistung.

Referenz↗

Leiten Sie internen Traffic basierend auf URL-Pfad oder Hostname, mit SSL-Terminierung, nur innerhalb der VPC oder von On-Prem aus zugänglich.

→Verwenden Sie einen Regional Internal Application Load Balancer. Konfigurieren Sie eine URL-Map, um Traffic basierend auf Host-/Pfadregeln zu leiten. Erfordert ein reines Proxy-Subnetz.

Warum: Dies ist Googles verwalteter L7 Internal Load Balancer. Er bietet erweiterte Routing-Funktionen, die beim L4 Internal Passthrough Network LB nicht verfügbar sind.

Verwenden Sie Cloud CDN, um private oder benutzerspezifische Inhalte zwischenzuspeichern und bereitzustellen, ohne sie öffentlich zu machen.

→Aktivieren Sie Cloud CDN für ein privates Backend (z.B. GCS-Bucket). Generieren Sie Cloud CDN Signed URLs oder Signed Cookies in Ihrer Anwendung, um Benutzern temporären, authentifizierten Zugriff zu gewähren.

Warum: Signed URLs/Cookies stellen ein sicheres Token bereit, das Cloud CDN validiert, bevor ein gecachtes Objekt bereitgestellt wird, wodurch Edge-Caching genutzt und gleichzeitig eine strenge Zugriffskontrolle aufrechterhalten wird.

Ermöglichen Sie bidirektionale DNS-Auflösung zwischen einem On-Prem-Netzwerk und einer GCP VPC.

→1) On-Prem löst GCP auf: Erstellen Sie eine Cloud DNS Inbound Server Policy. Konfigurieren Sie On-Prem DNS so, dass es an die Inbound Forwarder IPs weiterleitet. 2) GCP löst On-Prem auf: Erstellen Sie eine Cloud DNS Forwarding Zone, die auf die On-Prem DNS-Server verweist.

Warum: Diese standardmäßige zweiteilige Konfiguration bietet nahtlose, private Namensauflösung für hybride Umgebungen, eine kritische Komponente für die Anwendungsinteroperabilität.

Die Cloud CDN Cache-Hit-Rate ist aufgrund unnötiger URL-Variationen (z.B. Tracking-Parameter) niedrig.

→Konfigurieren Sie eine benutzerdefinierte Cache Key Policy für den Backend-Dienst. Schließen Sie nicht essentielle Abfrageparameter, Cookies und Header aus dem Cache Key aus.

Warum: Standardmäßig ist die vollständige URL der Cache Key. Die Normalisierung des Keys durch Ausschluss irrelevanter Parameter verhindert Cache-Fragmentierung und verbessert die Hit-Rate dramatisch.

Lösen Sie einen DNS-Namen für interne Clients auf eine interne IP und für externe Clients auf eine öffentliche IP auf.

→Erstellen Sie eine private Cloud DNS-Zone für die Domäne (sichtbar für Ihre VPC) mit dem internen IP-Eintrag. Erstellen Sie eine passende öffentliche Cloud DNS-Zone mit dem öffentlichen IP-Eintrag.

Warum: Cloud DNS liefert die Antwort aus der privaten Zone automatisch an Clients innerhalb der autorisierten VPC und die Antwort aus der öffentlichen Zone an alle anderen.

Eine interne Anwendung in einer Region muss für Clients (VMs, On-Prem) in anderen Regionen zugänglich sein.

→Aktivieren Sie die Option "Global Access" in der Weiterleitungsregel des Internal TCP/UDP Load Balancers oder Internal Application Load Balancers.

Warum: Standardmäßig sind interne LBs regional. Global Access macht sie von jeder Region innerhalb des VPC-Netzwerks zugänglich und vereinfacht so interne Multi-Region-Dienstarchitekturen.

Stellen Sie hochverfügbare (99.99% SLA), hochbandbreitige (10G+) Konnektivität zwischen On-Prem und GCP her.

→Stellen Sie mindestens vier Dedicated Interconnect-Verbindungen bereit, zwei in einer Metropolregion und zwei in einer anderen, wobei jedes Metropolenpaar in verschiedenen Edge Availability Domains liegt. Konfigurieren Sie BGP.

Warum: Redundanz über separate Metropolregionen und Ausfallbereiche (Edge Availability Domains) ist für die 99.99% SLA erforderlich.

Referenz↗

Benötigen Sie eine verschlüsselte, zuverlässige (99.9% oder 99.99% SLA) und schnell bereitstellbare Hybridverbindung mit moderater Bandbreite (< 6 Gbit/s).

→Verwenden Sie HA VPN mit BGP für dynamisches Routing. Für 99.99% SLA verwenden Sie zwei HA VPN-Gateways. Für 99.9% SLA verwenden Sie ein einzelnes Gateway mit zwei Tunneln.

Warum: HA VPN ist schneller einzurichten als Interconnect, bietet eine starke SLA und ausreichend Bandbreite für viele Anwendungsfälle, was es zur Standardwahl für nicht-physische Verbindungen macht.

Verschlüsseln Sie den gesamten Traffic, der über einen Dedicated oder Partner Interconnect-Link läuft, zur Einhaltung von Compliance-Vorschriften.

→Konfigurieren Sie HA VPN über Interconnect. Erstellen Sie HA VPN-Tunnel, die die VLAN-Attachments des Interconnect für ihren zugrunde liegenden Transport nutzen.

Warum: Dieses Muster kombiniert die hohe Bandbreite und geringe Latenz von Interconnect mit der IPsec-Verschlüsselung von HA VPN und bietet so das Beste aus beiden Welten.

Stellen Sie eine dedizierte, private Hochgeschwindigkeitsverbindung zwischen GCP und einem anderen großen Cloud-Anbieter (AWS, Azure, OCI) her.

→Verwenden Sie Cross-Cloud Interconnect. Stellen Sie eine dedizierte physische Verbindung zwischen Googles Netzwerk und dem Netzwerk des anderen Cloud-Anbieters bereit. Konfigurieren Sie BGP mit Cloud Router.

Warum: Bietet einen direkten, SLA-gestützten Pfad mit geringer Latenz zwischen Clouds, vermeidet das öffentliche Internet und die variable Leistung von VPNs.

Ein On-Prem-Netzwerk, das über Interconnect mit einer GCP-Region verbunden ist, muss auf Ressourcen in allen anderen GCP-Regionen zugreifen.

→Aktivieren Sie den "Globalen" dynamischen Routing-Modus auf der VPC. Der Cloud Router wird dann Routen für alle Subnetze in der VPC ankündigen, nicht nur für die in seiner lokalen Region.

Warum: Globales Routing ermöglicht es einem einzelnen hybriden Verbindungspunkt, als Zugang zum gesamten globalen Google-Netzwerk zu dienen, was den Zugriff über mehrere Regionen vereinfacht.

Beeinflussen Sie die Traffic-Pfadauswahl über redundante Hybridverbindungen (VPN/Interconnect) mittels BGP.

→Um den GCP-zu-On-Prem-Traffic zu beeinflussen, lassen Sie On-Prem spezifischere Routen ankündigen oder verwenden Sie einen kürzeren AS_PATH für den bevorzugten Pfad. Um On-Prem-zu-GCP-Traffic zu beeinflussen, kündigen Sie vom Cloud Router mit einem niedrigeren MED-Wert für den bevorzugten Pfad an.

Warum: Die BGP-Pfadauswahl folgt einem klaren Algorithmus. Der längste Präfix-Match ist entscheidend für den ausgehenden Traffic, während MED die Entscheidungen für den eingehenden Traffic beeinflusst.

Konfigurieren Sie ein Active/Passive-Failover zwischen einem primären Dedicated Interconnect und einem Backup HA VPN.

→Verwenden Sie BGP auf beiden. Auf dem Cloud Router kündigen Sie Routen über Interconnect mit einer niedrigeren Basis-Priorität (z.B. 100) und über VPN mit einer höheren Basis-Priorität (z.B. 200) an.

Warum: GCP bevorzugt BGP-Routen mit einem niedrigeren Prioritätswert (höhere Präferenz). Der Traffic nutzt den primären Interconnect. Bei einem Ausfall werden dessen Routen zurückgezogen und die Backup-VPN-Routen werden aktiv.

Verhindern Sie Datenexfiltration aus sensiblen Google Cloud-Diensten (z.B. BigQuery, GCS), indem Sie den Zugriff nur von autorisierten Netzwerken sicherstellen.

→Implementieren Sie VPC Service Controls. Erstellen Sie einen Service Perimeter um Projekte mit sensiblen Daten. Konfigurieren Sie Zugriffsstufen, um autorisierte Quellen (IP-Bereiche, Gerätestatus, Identität) zu definieren.

Warum: VPC-SC erstellt eine virtuelle Netzwerkbegrenzung um von Google verwaltete Dienste, die den Zugriff von außerhalb des Perimeters auch mit gültigen Anmeldeinformationen blockiert. Eine kritische Kontrolle der Datengovernance.

Referenz↗

Erzwingen Sie konsistente, nicht überschreibbare Baseline-Firewall-Regeln in einer Organisation, während Sie gleichzeitig Anpassungen auf Projektebene zulassen.

→Implementieren Sie Hierarchical Firewall Policies auf Organisations- oder Ordnerebene. Platzieren Sie hier kritische Regeln. Verwenden Sie die Aktion `goto_next`, um die Evaluierung an Richtlinien niedrigerer Ebene zu delegieren.

Warum: Hierarchische Richtlinien werden vor VPC-Ebenen-Regeln evaluiert und können von Projektbesitzern nicht geändert werden, was eine zentralisierte Governance gewährleistet. `goto_next` bietet Flexibilität.

Schützen Sie eine Webanwendung vor OWASP Top 10-Schwachstellen und wenden Sie eine Ratenbegrenzung pro Client-IP an.

→Verknüpfen Sie eine Cloud Armor Security Policy mit dem Global External Application LB. Wenden Sie vorkonfigurierte WAF-Regeln an (z.B. `sqli-v3.3-stable`) und fügen Sie eine ratenbasierte Regel hinzu.

Warum: Cloud Armor bietet Edge-Sicherheit. Vorkonfigurierte WAF-Regeln bieten verwalteten Schutz, während ratenbasierte Regeln DoS- und Brute-Force-Angriffe abmildern.

Implementieren Sie eine feingranulare Netzwerksicherheit auf Pod-Ebene innerhalb eines GKE-Clusters basierend auf Labels.

→Aktivieren Sie die Network Policy-Durchsetzung im GKE-Cluster. Erstellen Sie Kubernetes `NetworkPolicy`-Ressourcen, die Ingress-/Egress-Regeln für Pods unter Verwendung von Label-Selektoren definieren.

Warum: Kubernetes NetworkPolicy ist der native Weg, um Mikrosegmentierung auf Pod-Ebene zu implementieren, was eine höhere Granularität bietet als VPC-Firewall-Regeln, die auf Node-Ebene arbeiten.

Überprüfen Sie den gesamten Inter-VPC- oder VPC-zu-Internet-Traffic mithilfe einer zentralisierten Drittanbieter-Firewall/NVA.

→Erstellen Sie eine Hub-and-Spoke-Topologie. Stellen Sie die NVA(s) in einer Hub-VPC bereit. Konfigurieren Sie benutzerdefinierte Routen in Spokes, die den Traffic an einen Internal Load Balancer im Hub als Next-Hop leiten.

Warum: Dieses Muster erzwingt den Traffic durch einen zentralen Inspektionspunkt. Der ILB bietet eine stabile, hochverfügbare Next-Hop-IP für die NVAs.

Bieten Sie Benutzern sicheren, identitätsbasierten Zero-Trust-Zugriff auf interne Webanwendungen oder VMs, ohne ein VPN zu verwenden.

→Für Webanwendungen aktivieren Sie IAP auf einem External HTTPS LB Backend-Dienst. Für SSH/RDP verwenden Sie IAP für TCP-Weiterleitung. Erteilen Sie Benutzern entsprechende IAP IAM-Rollen.

Warum: IAP verlagert die Zugriffskontrolle von der Netzwerkperipherie auf die Identität des Benutzers, authentifiziert und autorisiert jede Anfrage. Es ist eine Kernkomponente von Googles BeyondCorp Zero-Trust-Modell.

Implementieren Sie Bedrohungsprävention (IDS/IPS) für Inter-VPC- oder VPC-zu-Internet-Traffic, einschließlich Malware-Erkennung und TLS-Inspektion.

→Verwenden Sie Cloud NGFW. Verknüpfen Sie eine Firewall Policy mit der VPC, erstellen Sie Regeln mit Sicherheitsprofilen zur Bedrohungsprävention und aktivieren Sie optional die TLS-Inspektion.

Warum: Cloud NGFW ist Googles verteilter, verwalteter Firewall-Dienst, der fortschrittliche L7-Inspektionsfunktionen von Palo Alto Networks bietet, direkt in die VPC integriert.

Zentralen Inspektion, Protokollierung und Steuerung des gesamten internetgebundenen ausgehenden Traffics aus einer VPC für Sicherheit und Compliance.

→Stellen Sie Secure Web Proxy bereit. Konfigurieren Sie Sicherheitspolicies für URL-Filterung und TLS-Inspektion. Leiten Sie Traffic von Subnetzen über benutzerdefinierte Routen zum Proxy.

Warum: Dies ist Googles verwaltete Lösung für sicheren Egress, die L7-Sichtbarkeit und -Kontrolle bietet, ohne selbstverwaltete Proxy-Flotten zu erfordern.

Diagnostizieren Sie schnell einen Konnektivitätsfehler zwischen zwei Endpunkten innerhalb von GCP (z.B. VM zu VM, VM zu Cloud SQL).

→Verwenden Sie die Connectivity Tests des Network Intelligence Center. Geben Sie Quelle und Ziel an, und es wird der gesamte konfigurierte Pfad auf Probleme analysiert.

Warum: Dieses nicht-intrusive Tool bietet eine definitive Analyse des Pfades und identifiziert den genauen Fehlerpunkt (Firewall, Route usw.) viel schneller als eine manuelle Überprüfung.

Eine BGP-Sitzung über eine Hybridverbindung wird sporadisch zurückgesetzt ("flapping").

→Überprüfen Sie auf eine Diskrepanz bei den BGP Keepalive-/Hold-Timern. Wenn Timer unter Last ablaufen, erhöhen Sie diese (z.B. 60s Keepalive, 180s Hold). Überprüfen Sie auch die MTU-Einstellungen und aktivieren Sie BFD.

Warum: Nicht übereinstimmende oder übermäßig aggressive Timer sind eine häufige Ursache für BGP Flaps, da vorübergehende Netzwerküberlastung Keepalive-Pakete über die Hold-Zeit hinaus verzögern kann.

Untersuchen Sie Berichte über erhöhte Latenz für Traffic zwischen GCP-Regionen.

→Verwenden Sie das Performance Dashboard des Network Intelligence Center, um historische und Echtzeit-Latenz- und Paketverlustmetriken zwischen allen GCP-Zonenpaaren anzuzeigen.

Warum: Dieses Tool bietet direkte Einblicke in die Leistung des Google-Backbone-Netzwerks und hilft, zwischen einem Anwendungsproblem und einem Netzwerkinfrastrukturproblem zu unterscheiden.

VMs, die Cloud NAT verwenden, erfahren intermittierende Ausfälle bei ausgehenden Verbindungen, und NAT-Logs zeigen `OUT_OF_RESOURCES`-Abbrüche.

→Dies ist wahrscheinlich eine NAT-Port-Erschöpfung. Erhöhen Sie die Anzahl der zugewiesenen NAT-IPs, erhöhen Sie die "Minimum Ports pro VM-Instanz" und/oder aktivieren Sie die dynamische Port-Zuweisung.

Warum: Hohe Verbindungsraten von vielen VMs können den zugewiesenen Quellport-Pool pro NAT-IP erschöpfen. Die Zuweisung weiterer Ressourcen ist die erforderliche Lösung.