Multi-VPC-Konnektivität: Peering vs. Transit Gateway vs. Hub-and-Spoke

Red Snapper

2 months ago

Multi-VPC-Konnektivität ist in modernen Cloud-Organisationen kein Spezialthema mehr, sondern Alltag: getrennte Accounts/Subscriptions, mehrere Umgebungen (Dev/Test/Prod), Plattform- und Produktteams, Compliance-Zonen, Shared Services und zunehmend auch Multi-Region-Designs. Früher oder später entsteht damit die Kernfrage: Wie verbinden wir mehrere VPCs/VNets so, dass Connectivity zuverlässig, sicher, beobachtbar und wirtschaftlich bleibt? Oft startet man mit „einfach mal peeren“, weil VPC Peering schnell eingerichtet ist und für wenige Netze gut funktioniert. Mit Wachstum wird aus „ein bisschen peeren“ jedoch eine Netztopologie mit vielen Kanten, inkonsistenten Policies und schwer zu erklärenden Datenpfaden. Spätestens wenn zentrale Security-Kontrollen, Hybrid-Anbindungen, Egress-Inspection oder mehrere Teams gleichzeitig Änderungen durchführen, wird eine skalierbare Architektur notwendig: Transit Gateway/Hub-Lösungen oder ein bewusstes Hub-and-Spoke-Design. Dieser Artikel ordnet Peering vs. Transit Gateway vs. Hub-and-Spoke praxisnah ein, zeigt die typischen Designfehler und gibt Kriterien an die Hand, mit denen Plattformteams eine robuste Multi-VPC-Konnektivität aufbauen – ohne in Routing-Spaghetti, Kostenfallen oder unklare Verantwortlichkeiten zu geraten.

Begriffe und Rahmen: Was „Multi-VPC-Konnektivität“ in der Praxis umfasst

Im Kern geht es um Layer-3-Konnektivität zwischen isolierten IP-Domänen. In AWS heißen sie VPCs, in Azure VNets, in GCP VPC Networks; die Muster sind aber ähnlich. Multi-VPC-Konnektivität umfasst typischerweise:

Ost-West-Traffic: Service-zu-Service zwischen VPCs (z. B. Produkt-VPC ↔ Shared-Services-VPC).
Nord-Süd-Traffic: Egress/Ingress, oft zentral kontrolliert (NAT, Firewall, Proxy, Inspection).
Hybrid: On-Prem ↔ Cloud, häufig mit redundanten Links und klaren Compliance-Anforderungen.
Segmentierung: Trennung nach Umgebungen, Datenklassen oder Mandanten, ohne Produktivität zu verlieren.

Als Referenz für CIDR-Grundlagen und Präfixlogik ist RFC 4632 (CIDR) hilfreich; private IPv4-Adressbereiche sind in RFC 1918 beschrieben. Das OSI-Modell bleibt ein nützliches Denkmodell, um Routing-/Transportprobleme von Applikationssymptomen zu trennen.

Warum die Wahl der Konnektivitäts-Architektur so entscheidend ist

Die Topologie bestimmt nicht nur, „ob es funktioniert“, sondern auch, wie schnell Sie Incidents triagieren, wie sicher Policies durchgesetzt werden, wie teuer Cross-Zone/-Region-Traffic wird und wie gut sich Änderungen automatisieren lassen. Die drei häufigsten Schmerzpunkte bei schlecht gewählten Ansätzen:

Skalierung: Die Anzahl der Verbindungen, Routen und Policy-Ausnahmen wächst schneller als die Zahl der VPCs.
Operational Overhead: Debugging wird schwer, weil Datenpfade intransparenter werden und Ownership unklar ist.
Sicherheit und Compliance: Zentrale Kontrollen lassen sich nur schwer erzwingen, wenn es viele direkte Wege gibt.

VPC Peering: Stärken, Grenzen und typische Einsatzfälle

VPC Peering (oder vergleichbare direkte VNet/VPC-Verbindungen) ist in vielen Clouds der schnellste Weg, zwei Netzdomänen zu verbinden. Es ist besonders attraktiv, weil es meist wenig Infrastruktur benötigt, geringe Latenz hat und für wenige Verbindungen überschaubar bleibt.

Wann Peering sinnvoll ist

Kleine Anzahl VPCs: wenige Netze, klare 1:1-Abhängigkeiten, geringe Änderungsfrequenz.
Klare Produktkopplung: ein Team kontrolliert beide Seiten oder es gibt eine stabile Schnittstelle.
Keine zentrale Inspection erforderlich: oder Inspection findet an anderer Stelle statt (z. B. in der Applikationsschicht).

Typische Grenzen von Peering

Die zentralen Grenzen sind weniger „technisch unmöglich“, sondern operativ teuer. Sobald viele VPCs miteinander sprechen müssen, wird das Netz vollvermascht. Daraus folgen Routing-Komplexität, Policy-Divergenz und ein wachsendes Risiko für Asymmetrien oder unklare Return Paths.

Vollmesh-Problem: viele direkte Verbindungen, schwer zu standardisieren.
Policy-Fragmentierung: jede Peering-Kante braucht Freigaben, Dokumentation und Tests.
Observability-Lücken: Datenpfade sind nicht zentral sichtbar, was MTTR erhöht.
IP-Overlaps: Overlapping CIDRs sind ein häufiger Blocker, besonders bei M&A oder Hybrid.

Das Vollmesh-Problem als Wachstumsfalle

Das Vollmesh-Problem lässt sich mathematisch als Anzahl der Verbindungen in einem vollständigen Graphen beschreiben. Bei n VPCs benötigen Sie im Vollmesh n(n-1)/2 Verbindungen. Das wächst quadratisch und ist der Hauptgrund, warum Peering „plötzlich“ unbeherrschbar wird.

Emesh = n × n – 1 2

Schon bei 10 VPCs sind das 45 Verbindungen; bei 30 VPCs 435. Jede Verbindung bringt Routen, Freigaben, Tests und potenziell ein Incident-Exposure mit.

Transit Gateway: Was es löst und welche neuen Fragen es einführt

Ein Transit Gateway (oder vergleichbare Hub-Routing-Komponente) ist ein zentraler Routing-Knoten, an den mehrere VPCs angebunden werden. Der Hauptnutzen: Sie ersetzen viele Peerings durch eine „Hub“-Struktur und gewinnen damit Skalierbarkeit und Standardisierbarkeit. In AWS ist das Muster besonders prominent, aber ähnliche Konzepte existieren auch in anderen Clouds (z. B. zentrale Router/Hub-Netzwerke).

Warum Transit Gateway häufig die nächste Evolutionsstufe ist

Skalierung: Anbindung einer VPC wird zu einer Standardoperation (Attachment statt neue Peering-Kanten).
Zentrale Policy-Steuerung: Routing-Domänen lassen sich konsistenter gestalten (z. B. Segmente/Route Tables pro Domäne).
Hybrid-Integration: On-Prem-Links können zentral eingebunden werden, statt pro VPC.
Transparente Datenpfade: Pfade laufen über einen definierten Knoten, der sich besser überwachen lässt.

Neue Fragen, die mit Transit Gateway entstehen

Ein Hub reduziert Komplexität an den Rändern, aber er ist ein zentrales Produkt, das betrieben werden muss. Damit entstehen neue Anforderungen an Governance, Change-Management und Fault Domain Design.

Blast Radius: Der Hub ist kritisch; Fehlkonfigurationen können viele VPCs gleichzeitig betreffen.
Routen-Governance: Wer darf welche Präfixe announcen? Wie verhindern Sie „Route Leaks“?
Segmentierung: Wie trennen Sie Umgebungen oder Datenklassen innerhalb des Hubs sinnvoll?
Kostenmodell: Zentraler Traffic kann Cross-AZ- und Datenverarbeitungskosten verstärken, wenn Lokalität ignoriert wird.

Hub-and-Spoke: Architekturprinzip, nicht nur ein Produkt

„Hub-and-Spoke“ ist ein Architekturprinzip: Viele isolierte Netze (Spokes) hängen an einem oder mehreren Hubs, die zentrale Funktionen bereitstellen (Routing, Security, Egress, Shared Services, Hybrid). Ein Transit Gateway kann die technische Umsetzung sein, aber Hub-and-Spoke ist breiter: Es umfasst auch Routing-Profile, Ownership, Observability und klar definierte Übergänge.

Typische Hub-Rollen

Connectivity Hub: routet zwischen Spokes, kontrolliert welche Domänen miteinander sprechen dürfen.
Security/Inspection Hub: zentraler Pfad für bestimmte Traffic-Klassen (z. B. Internet-Egress, Partnernetze).
Shared-Services Hub: stellt Plattformdienste bereit (Monitoring, Logging, Artefakte, DNS-Resolver, PKI).
Hybrid Hub: bündelt VPN/Direct Connect/ExpressRoute und hält Return Paths konsistent.

Warum „ein Hub“ nicht immer reicht

Ein häufiger Designfehler ist der „Monolith-Hub“: alles läuft durch einen Knoten, unabhängig von Zone/Region oder Traffic-Klasse. Das erhöht Kosten, Latenz und den Blast Radius. Besser ist oft ein mehrstufiges Modell: lokale Hubs pro Region oder pro Sicherheitsdomäne, die über definierte, gut beobachtbare Verbindungen gekoppelt sind.

Vergleichskriterien: Peering vs. Transit Gateway vs. Hub-and-Spoke

Die Entscheidung sollte nicht nach Bauchgefühl erfolgen, sondern entlang stabiler Kriterien. Die folgenden Dimensionen haben sich in Plattformteams bewährt.

Skalierbarkeit und Betriebsaufwand

Peering: gut für wenige Verbindungen, wird bei Wachstum schnell unübersichtlich (Vollmesh-Effekt).
Transit Gateway: skaliert in der Anzahl Spokes besser; Betrieb konzentriert sich auf Hub-Governance.
Hub-and-Spoke: skaliert organisatorisch, wenn Rollen und Ownership klar sind; technische Umsetzung kann variieren.

Security und zentrale Kontrolle

Peering: schwer, zentrale Inspection zu erzwingen, wenn direkte Pfade existieren; Policies fragmentieren.
Transit Gateway: bessere Grundlage für segmentierte Routing-Domänen und zentrale Kontrollpunkte.
Hub-and-Spoke: ermöglicht bewusstes „Default-Deny“ zwischen Spokes und definierte Übergänge über Security-Hubs.

Observability und Incident-Triage

Peering: viele Pfade, viele Zuständigkeiten; Triage benötigt oft mehr Kontext und Abstimmung.
Transit Gateway: zentraler Knoten erleichtert Pfadmodellierung; Metriken/Logs lassen sich am Hub bündeln.
Hub-and-Spoke: am besten, wenn Telemetrie nach Domänen (Spoke, Hub, Attachment) strukturiert ist.

Routing-Komplexität und Asymmetrie-Risiko

Asymmetrisches Routing entsteht häufig, wenn mehrere gleichwertige Pfade existieren und Hin-/Rückwege unterschiedliche Kontrollpunkte passieren. Je mehr direkte Kanten (Peering) und je mehr Sonderrouten, desto höher das Risiko.

Peering: viele alternative Wege, besonders in „teilweisen Meshes“; Return Paths werden schwer zu garantieren.
Transit/Hub: Pfade werden deterministischer, wenn der Hub als einziger Transit genutzt wird.
Wichtig: Der Hub muss als „single transit domain“ geplant werden; Mischformen ohne klare Regeln erzeugen neue Asymmetrien.

Typische Kostenfallen und wie man sie vermeidet

Die teuersten Multi-VPC-Designfehler sind selten die offensichtlichen. Häufig entstehen sie durch Cross-AZ/Cross-Region-Traffic, durch zentrale Inspection für jeden Flow oder durch „Workaround-Architektur“ nach IP-Overlap-Problemen.

Kostenfalle: Zentraler Egress ohne Lokalität

Problem: Traffic aus mehreren AZs läuft zu einem zentralen NAT/Firewall-Punkt und verursacht Cross-AZ-Kosten und Tail-Latency.
Lösung: zonale Egress-Pfade oder regionale Hubs mit lokalem Exit; nur bestimmte Klassen zentral inspizieren.

Kostenfalle: NAT als Dauerlösung für CIDR-Overlaps

Problem: Overlapping IP-Ranges verhindern direkte Konnektivität; NAT zwischen internen Netzen wirkt „schnell“, macht aber Debugging und Security kompliziert.
Lösung: IPAM und overlap-freie CIDR-Strategie; NAT nur als Übergang oder für spezifische, gut dokumentierte Zwecke.

Kostenfalle: „Alles durch Inspection“

Problem: Jeder Ost-West-Flow muss über Firewall/Proxy; das erhöht Latenz, Kosten und Ausfallradius.
Lösung: Egress- und East-West-Klassen definieren, Security-Ziele klar formulieren, Inspection selektiv einsetzen.

Governance: Ohne klare Ownership wird jede Topologie teuer

Unabhängig von der technischen Lösung ist Governance entscheidend. Multi-VPC-Konnektivität scheitert oft nicht am Feature, sondern an fehlenden Regeln: Wer darf Routen ändern? Wie werden neue Spokes angebunden? Wie werden Freigaben dokumentiert? Wie wird Drift verhindert?

Routing als Produkt: Hubs und Attachments haben Owner, Change-Prozess, Tests und SLOs.
Standardprofile: wenige, wiederholbare Muster (z. B. „prod-spoke“, „dev-spoke“, „shared-services“).
Policy-as-Code: Regeln gegen Overlaps, gegen ungewollte Default Routes, gegen „Route Leaks“ automatisieren.
Dokumentierte Datenpfade: „welcher Traffic darf wohin und über welchen Hub“ muss nachvollziehbar sein.

Designleitlinien: So wählen Plattformteams den passenden Ansatz

Die folgenden Leitlinien helfen bei der Auswahl und bei einem sauberen Übergang von „klein“ zu „groß“, ohne später alles neu bauen zu müssen.

Wenn Sie bei Peering bleiben, dann bewusst und begrenzt

Peering als Ausnahme: nur für klare 1:1-Beziehungen, nicht als Standard für jede neue VPC.
Keine „halb Mesh“-Topologie: entweder klarer Transit über Hub oder klare direkte Beziehungen; Mischformen sind fehleranfällig.
IPAM Pflicht: overlap-freie CIDRs, sonst wird Wachstum blockiert.

Wenn Sie Transit/Hub nutzen, designen Sie Fault Domains und Lokalität

Regionale Hubs: reduzieren Cross-Region-Kosten und verbessern Latenz; Koppelung zwischen Hubs bewusst gestalten.
Zonale Pfade: Egress/Inspection lokal halten, wo möglich; Failover testen.
Segmentierung: Umgebungen und Datenklassen trennen, damit ein Fehler nicht alles gleichzeitig betrifft.

Für Shared Services: bevorzugen Sie klare „Spoke → Hub“-Pfadlogik

Shared Services als Hub-Funktion: Monitoring, Logging, DNS-Resolver, Artefakte zentral, aber über definierte Pfade.
Kein „Backdoor Peering“: direkte Peerings zu Shared Services untergraben zentrale Policies.
Observability mit Dimensions: Spoke-ID, Hub-ID, AZ/Region, Zielklasse (Internet/Partner/On-Prem).

Telemetrie und Tests: Multi-VPC-Konnektivität „beweisbar“ machen

Viele Teams verlassen sich auf „Ping geht“ oder auf sporadische Integrations-Tests. Für stabile Plattformen braucht es jedoch Baselines und kontinuierliche Validierung der wichtigsten Pfade: Connect-Time, Paketverlust-Indizien, Latenz über Hubs, Erfolg pro Zielklasse und Failover-Verhalten.

Connectivity Checks: pro Spoke und pro Zielklasse (Shared Services, Internet, Partner, On-Prem).
Traceroute-ähnliche Sicht: nicht immer möglich in der Cloud, aber Pfad-Korrelation über Metriken am Hub ist oft ausreichend.
Change-Annotierung: Route-Änderungen, neue Attachments, neue Spokes als Events in Observability.

Für standardisierte Telemetrie ist OpenTelemetry hilfreich, um Metriken, Logs und Traces entlang der Pfade konsistent zu erfassen.

Outbound-Referenzen für vertiefende Informationen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.