# Google Cloud Platform (GCP) Networking: VPC Architektur & Global Routing

TL;DR / Management Summary Das VPC (Virtual Private Cloud) in GCP unterscheidet sich grundlegend von AWS oder Azure: Es ist eine globale Ressource. Sie können ein einziges VPC erstellen, das Subnetze in Frankfurt, Tokio und New York enthält, die alle über Googles privaten Backbone kommunizieren. Ein Senior Admin nutzt diese Architektur zur Vereinfachung des globalen Routings und schützt seine Ressourcen durch das tag-basierte Firewall-Modell von Google.

# 1. Das globale VPC Modell

Ein Netzwerk für die ganze Welt.

In GCP müssen Sie keine VNets peeren, um Kontinente zu verbinden.

• Global Unicast: Ein VPC spannt standardmäßig über alle Regionen.
• Subnets: Sind regional. Sie legen fest: Subnet-EU (Frankfurt) und Subnet-US (Iowa).
• Routing: Der interne Traffic zwischen Subnetzen in verschiedenen Regionen wird automatisch und verschlüsselt über das Google-Netzwerk geleitet.

# 2. Firewall-Regeln in GCP

Tag-basiertes Filtering.

GCP Firewalls nutzen keine “Sicherheitsgruppen”-Objekte, sondern sind Teil des VPCs.

• Targets: Sie weisen Regeln nicht IPs zu, sondern Network Tags (z.B. http-server) oder Service Accounts.
• Vorteil: Wenn Sie eine neue VM mit dem Tag http-server starten, greifen alle zugehörigen Firewall-Regeln sofort, egal in welcher Region die VM läuft.

# 3. Deep Dive: Cloud Load Balancing

Der weltweite Proxy.

Googles Loadbalancer sind ebenfalls global.

• Anycast IP (Artikel 576): Sie erhalten eine einzige öffentliche IP für die ganze Welt.
• Logic: Google leitet den User automatisch an das RZ weiter, das die geringste Latenz hat.
• Vorteil: Kein DNS-GSLB (Artikel 750) nötig.

# 4. Day-2 Operations: Cloud Interconnect & Cloud VPN

Anbindung an On-Premise.

1. Cloud VPN: Klassisches IPsec (Artikel 565). Unterstützt HA-Setups mit zwei Tunneln für 99.99% Uptime.
2. Dedicated Interconnect: Physische Verbindung zu einem Google Edge-Standort (10G/100G).
3. Partner Interconnect: Verbindung über einen Provider (z.B. Equinix).

# 5. Troubleshooting & “War Stories”

Wenn die globale Cloud hakt.

# Top 3 Fehlerbilder

1. Symptom: VMs in verschiedenen Subnetzen können sich nicht pingen.

   • Ursache: GCP hat eine “Implied Deny” Regel für Ingress Traffic.
   • Lösung: Erstellen Sie eine Regel Allow ICMP | Source: 10.0.0.0/8.

2. Symptom: Hohe Latenz bei Multi-Region Zugriffen.

   • Ursache: Traffic nutzt den “Standard Tier” (Internet) statt des “Premium Tier” (Google Backbone).
   • Lösung: Network Service Tier auf Premium stellen.

3. Symptom: Firewall-Regel greift nicht.

   • Fix: Prüfen Sie, ob das Network Tag an der VM exakt mit dem Tag in der Regel übereinstimmt (Case Sensitive!).

# “War Story”: Die “Egress” Kostenfalle

Ein Admin nutzte das globale VPC, um Backups zwischen einem Server in den USA und einem Bucket in Europa zu verschieben. Er dachte, da es das gleiche VPC ist, sei es kostenlos. Das Ergebnis: Eine monatliche Rechnung über 2.000 Euro für “Inter-region egress traffic”. Lehre: Nur weil ein Netzwerk logisch global ist, ist der Datentransport nicht kostenlos. Google berechnet den Traffic zwischen Regionen, auch innerhalb eines VPCs. Planen Sie Backup-Ziele (Artikel 694) immer in der gleichen Region wie die Workload.

# 6. Monitoring & Reporting

Transparenz in der Flow-Ebene.

# VPC Flow Logs

Aktivieren Sie Flow Logs zur Analyse von Durchsatz und abgelehnten Paketen.

• Integration: Senden Sie Logs an BigQuery, um komplexe SQL-Analysen über Ihren weltweiten Traffic zu fahren.

# 7. Fazit & Empfehlung

GCP Networking ist ideal für global verteilte Applikationen.

• Empfehlung: Nutzen Sie die Premium Tier Netzwerkleistung. Der Aufpreis lohnt sich durch die massiv verringerte Latenz.
• Wichtig: Verwenden Sie Identity-Aware Proxy (IAP), um auf Ihre VMs zuzugreifen, ohne Ports wie 22 (SSH) oder 3389 (RDP) zum Internet hin öffnen zu müssen.

# Anhang: Cheatsheet (gcloud CLI)

# Referenzen

• Google Cloud: VPC Service Overview
• GCP: Global, regional, and zonal resources
• Best practices for VPC design