VPC Peering und Routing

1) Warum Peering und wann es angemessen ist

• Trennung von Umgebungen und Domänen (prod/stage/dev) bei gemeinsamer privater Konnektivität;
• Herausgabe gemeinsamer Plattformen (Logging, KMS/Vault, Artefakte) im Shared-Netzwerk;
• Zugriff von Apps auf verwaltete PaaS über private Pfade (über Hubs/Endpoints).

Wenn es besser ist, nicht peering, sondern einen Hub: mehr als 10-20 Netzwerke, die Notwendigkeit von Transit-Routing, zentralisiertes egress, Cloud-Kommunikation → verwenden Sie Transit Gateway/Virtual WAN/Cloud Router.

2) Modelle und Einschränkungen

2. 1 Arten von Peering

Intra-Region peering - innerhalb der Region, minimale Verzögerungen und Kosten.
Inter-region peering - Zwischen den Regionen wird in der Regel der überregionale Verkehr bezahlt.
Cross-project/account - Peering zwischen verschiedenen Konten/Projekten (mit Delegation).

2. 2 Transit und NAT

Das klassische VPC/VNet Peering ist nicht transitiv: Das Netzwerk von A↔B und B↔C bedeutet nicht A↔C.
NAT über ein Zwischennetz für den Transit ist ein Anti-Muster (bricht die ursprüngliche IP, komplexes Audit).
Für den Transit gibt es einen Hub-Bus: AWS Transit Gateway (TGW), Azure Virtual WAN/Hub, GCP Cloud Router/HA VPN/Peering Router.

2. 3 Overlapping CIDR

• Adressbindung (beste Option);
• NAT-Domains/Proxy VPCs mit einseitigen Schemata (unter Berücksichtigung von Audit und Logging);
• Für spezifische PaaS - PrivateLink/PSC ohne L3-Zugang.

3) Adressierung und Routengestaltung

3. 1 CIDR-Planung

Ein einzelnes Supernet (z.B. '10. 0. 0. 0/8') teilen → durch 'region/env/vpc'.
Reserviere Bereiche für zukünftige VPCs/Tenants (Growth-Buffer).
IPv6 - Plan im Voraus: '/56 'auf VPC, '/64' auf Subnetz.

3. 2 Routing

Routentabellen: Auf jedem VPC/Subnetz gibt es explizite Routen auf dem Peer/Hub.
Prioritäten: spezifischeres Präfix gewinnt; Vermeiden Sie Catch-all durch Peering.
Blackhole-Schutz: Doppelte/veraltete Routen markieren und reinigen.

3. 3 Domänen und Rollen

Spoke (Apps) ↔ Hub (Shared Services, Egress, Inspektion).
Feste nur spoke↔hub; spoke↔spoke - durch den Hub (Segmentierung und Kontrolle).

4) Topologiemuster

4. 1 „Einfaches“ Mesh (≤5 VPC)

Direkte Pin-to-Pin-Peers (A↔B, A↔C...). Vorteile: ein Minimum an Komponenten; Nachteile: O (N ²) Beziehungen und Regeln.

4. 2 Hub-and-Spoke

Alle spoke Pick mit Hub VPC/VNet; im Hub - TGW/Virtual WAN/Cloud Router, NAT/egress, Inspektion. Skalierbar, einfach zu verwalten.

4. 3 Multi-Region

Lokale Drehkreuze in jeder Region; zwischen den Hubs - inter-region peering oder backbone (TGW-to-TGW/VWAN-to-VWAN).

5) Sicherheit und Segmentierung

Stateful auf Host: SG/NSG - die Hauptbarriere; NACL/Subnet ACL - Grobe Einzäunung/Deny-Sheets.
L7 Richtlinien in mesh/proxy (Istio/Envoy/NGINX) - Autorisierung durch mTLS/JWT/claims.
Egress-Steuerung: spoke darf das Internet nicht direkt „sehen“ - nur über egress-gateway/PrivateLink.
Flow Logs und Inspektion im Hub (GWLB, IDS/IPS) für den Inter-VPC-Verkehr.

6) DNS и split-horizon

Jeder private Bereich - Sichtbarkeit auf den gewünschten VPCs (Private Hosted Zones/Private DNS/Zones).
Für PaaS über PrivateLink/PSC - private Einträge zu privaten IP-Endpunkten.
Conditional forwarding между on-prem ↔ cloud и region ↔ region.
Namensgebung: 'svc. env. region. internal. corp'- ohne PII; Befestigen Sie die TTL (30-120s) unter dem Failover.

7) Beobachtbarkeit und Prüfung

Metriken: akzeptiert/denied auf SG/NSG, Bytes per Peer, RTT/Jitter zwischen den Regionen, Top-Talker.
Logs: VPC Flow Logs/NSG Flow Logs in SIEM, Trace mit 'trace _ id' für die Coreation von L7↔L3.
Erreichbarkeitstests: synthetische TCP/443/DB-Ports aus verschiedenen Subnetzen/AZ/Regionen; reachability analyzer.
Chaos-Netzwerk: Verzögerungen/Verluste zwischen Peer/Hub; Überprüfung der Timeouts/Retrays/Idempotenz.

8) Leistung und Kosten

Inter-Region wird fast immer berechnet; Zählen Sie egress im Voraus (es wird teurer mit Protokollen/Backups).
MTU/PMTUD: Innerhalb des Anbieters eine Standard-MTU, aber an den Grenzen (VPN, FW, NAT-T) die MSS-Klemme beachten.
Horizontale Skalierung der Inspektion (GWLB/scale sets) ohne Engpässe; ECMP für Hubs.
Cache/Edge und SWR reduzieren den überregionalen Verkehr.

9) Cloud-Funktionen und Beispiele

9. 1 AWS (VPC Peering / Transit Gateway)

VPC Peering: Erstellen Sie eine Peering-Verbindung, fügen Sie Routen in Subnetztabellen hinzu.
Kein Transit durch das normale Peering. Für Transit und zentrales Modell - Transit Gateway.

hcl resource "aws_vpc_peering_connection" "a_b" {
vpc_id    = aws_vpc. a. id peer_vpc_id  = aws_vpc. b. id peer_owner_id = var. peer_account_id auto_accept  = false tags = { Name = "a-b", env = var. env }
}

resource "aws_route" "a_to_b" {
route_table_id     = aws_route_table. a_rt. id destination_cidr_block = aws_vpc. b. cidr_block vpc_peering_connection_id = aws_vpc_peering_connection. a_b. id
}

9. 2 Azure (VNet Peering / Virtual WAN)

VNet Peering (einschließlich global): Flags Allow forwarded traffic, Use remote gateway for hub schemas.
Für Hubs und Transit - Virtual WAN/Hub c Routentabellen und Richtlinien.

bash az network vnet peering create \
--name spokeA-to-hub --vnet-name spokeA --remote-vnet hub \
--resource-group rg --allow-vnet-access --allow-forwarded-traffic

9. 3 GCP (VPC Peering / Cloud Router)

VPC Peering ohne Transit; für das Zentrum - Cloud Router + HA VPN/Peering Router.
Hierarchical FW для org-guardrails.

10) Kubernetes in Peer-to-Peer-Netzwerken

Cluster im Spoke, gemeinsame Dienste (Logging/Storage/Artefakte) - im Hub; Zugriff auf private Adressen.
NetworkPolicy „deny-all“ und explizit egress auf hub/PrivateLink.
„Schleppen“ Sie den Pod CIDR nicht zwischen den VPCs; Routing des Node CIDR und Verwendung von Ingress/Gateway.

11) Trablschuting (Spickzettel)

1. CIDRs überschneiden sich nicht? Supersets/alte Subnetze prüfen.
2. Routentabellen: Gibt es einen Weg in beide Richtungen? Gibt es keine spezifischere Route, die den Verkehr abfängt?
3. SG/NSG/NACL: stateful-in/out konform? Blockiert die Subnetz-ACL den Rückwärtsverkehr?
4. DNS: die richtigen privaten Einträge/Vorwarder? Überprüfen Sie' dig + short 'von beiden Netzwerken.
5. MTU/MSS/PMTUD: Gibt es keine Fragmentierung und „stille“ Timeouts?
6. Ablaufprotokolle prüfen: Gibt es SYN/SYN-ACK/ACK? Wer droppt?
7. Inter-region: die Quoten/Limits der piringa/Politik die Organisationen/Tags des Routings.

12) Antipatterns

Ein „zufälliges“ Mesh von Dutzenden von Festen ohne Hub → eine Explosion von Schwierigkeiten und ACL-Auslassungen.
Overlapping CIDR „irgendwie überleben NAT“ → bricht Audit/Ende-zu-Ende-Identifikation.
Öffentliche egress in jedem spoke → unkontrollierbare Oberfläche und Kosten.
Kein Split-Horizon DNS → Name Leaks/defekte Resolves.
Breite Routen'0. 0. 0. 0/0 'durch Peer → eine unerwartete Verkehrsasymmetrie.
Manuelle Bearbeitungen in der Konsole ohne IaC und Revision.

13) Spezifität von iGaming/Finanzen

PCI-CDE und Zahlungsschleifen - nur über einen Hub mit Inspektion; Kein spoke↔spoke zur Umgehung.
Datenresidenz: PII/Transaktionsprotokolle - innerhalb von Gerichtsbarkeiten; überregional - Aggregate/anonym.
Multi-PSP: PrivateLink/private Kanäle zur PSP, zentraler Egress-Proxy per Allowlist FQDN und mTLS/HMAC.
Audit/WORM: Flussprotokolle und Routenänderungen im unveränderlichen Speicher, Retention nach Normen.
SLO-Schnitte: per region/VPC/tenant; Warnungen vor der „undichten Stelle“ und dem Abbau interregionaler RTT.

14) Checkliste Prod-Ready

• CIDR-Plan ohne Überschneidungen (IPv4/IPv6), Wachstumspools reserviert.
• Hub-and-Spoke-Topologie; Feste - nur spoke↔hub; Transit über TGW/VWAN/Cloud Router.
• Routentabellen: explizite Pfade, kein Catch-All durch Peer, Blackhole-Kontrolle.
• SG/NSG/NACL angewendet; L7-Richtlinien in Mesh; egress nur über Hub/PrivateLink.
• Private DNS/PHZ konfiguriert; conditional-forwarders между on-prem/cloud/regions.
• Flow Logs enthalten; Dashboards per Peer/Region; Synthetik der Erreichbarkeit und PMTUD-Tests.
• IaC (Terraform/CLI) und Policy-as-Code (OPA/Conftest) für Regeln/Routen/DNS.
• runbook 'und dokumentiert (Peer hinzufügen, Routen ausrollen, Spoke ausschalten).
• Übungen: Abschalten des Hubs/Festes, Messung der tatsächlichen RTO/RPO der Netzwerkpfade.
• Für iGaming/Finanzen: PCI-Isolation, PrivateLink zu PSP, WORM-Audit, SLOs/Warnungen nach Gerichtsbarkeit.

15) TL; DR

Verwenden Sie VPC/VNet Peering für einfache private Punkt-zu-Punkt-Konnektivität, aber verlassen Sie sich nicht darauf für den Transit - dies erfordert einen Hub (TGW/VWAN/Cloud Router). CIDR ohne Kreuzungen planen, Routen explizit und spezifisch halten, stateful SG/NSG und L7-Richtlinien in Mesh, DNS - Split-Horizon anwenden. Aktivieren Sie Flow-Logs, Synthetics und PMTUD-Prüfungen. Für iGaming/Finanzen - PCI-Isolation, private Kanäle zur PSP und unveränderliches Audit.