Hub-and-Spoke-Netzwerktopologie: Diagramme für Azure und AWS

Das erste Cloud-Netzwerk ist einfach. Beim zehnten gibt es ein Geflecht aus Peering-Verbindungen, drei VPN-Tunnel ins Büro, jeder leicht anders konfiguriert, eine in jedes Netz kopierte Firewall, und niemand kann sicher sagen, was was erreichen kann. Hub-and-Spoke ist der Standardweg heraus: ein zentrales Netz für gemeinsame Konnektivität und Inspektion, und Workloads in isolierten Spokes, die nur über dieses Netz verbunden sind.

Dieser Beitrag erklärt die Topologie und baut sie dann zweimal mit Diagrammen auf: in Azure mit einem Hub-VNet und Peering, in AWS mit Transit Gateway. Er behandelt Routing und Segmentierung, Traffic-Inspektion, zentralen Egress, die Kosten, die Teams überraschen, und wann ein verwalteter Hub die bessere Wahl ist.

Warum ein Mesh irgendwann nicht mehr funktioniert

Jedes Netz direkt mit jedem anderen zu verbinden, braucht n(n−1)/2 Verbindungen. Zehn Netze brauchen 45, fünfzig brauchen 1.225, jede mit eigenen Routen und Sicherheitsregeln. Peering ist außerdem in beiden Clouds nicht transitiv: Wenn A mit B und B mit C gepeert ist, erreicht A C trotzdem nicht über B. Ein Hub-and-Spoke-Design braucht eine Verbindung pro Spoke, und der Hub wird zum einzigen Ort, an dem Routing und Sicherheitsrichtlinien leben.

Was in den Hub gehört

Workloads gehören nicht in den Hub. Spokes enthalten Anwendungen, meist eine pro Anwendung, Team oder Umgebung, damit sich ein Fehler in einem nicht auf andere ausbreitet.

Hub-and-Spoke in Azure

Die Hub-Spoke-Referenzarchitektur von Microsoft legt Azure Firewall, ein VPN- oder ExpressRoute-Gateway und Azure Bastion in ein Hub-VNet, jeweils in ein eigenes dediziertes Subnetz. Azure Firewall braucht ein Subnetz von mindestens /26. Spokes verbinden sich per VNet-Peering mit dem Hub, das Microsoft als nicht transitiv beschreibt: Gepeerte Netze sprechen miteinander, nicht durch einander hindurch.

Das hat zwei Folgen:

• Gateway-Sharing ist explizit. Das Hub-Peering erlaubt Gateway-Transit, und jeder Spoke nutzt das Remote-Gateway, damit Spokes das lokale Netz über das Gateway des Hubs erreichen.
• Spoke-zu-Spoke-Traffic braucht Routen. Benutzerdefinierte Routen in jedem Spoke schicken Traffic für andere Spokes, und meist auch die Standardroute, an die private IP der Firewall. Die Firewall leitet weiter, was die Richtlinie erlaubt. Alternativ kann Azure Virtual Network Manager Peerings und verbundene Gruppen im großen Maßstab verwalten, und direktes Peering zwischen zwei Spokes bleibt für Sonderfälle eine Option.

Für einen von Microsoft verwalteten Hub bietet Azure Virtual WAN Hubs mit integriertem Routing, Gateways und optionalen Firewalls, im Tausch gegen weniger Kontrolle über die Details.

Hub-and-Spoke in AWS

In AWS ist der Hub meist ein Transit Gateway, ein regionaler Router, an den VPCs, VPN-Verbindungen und Direct-Connect-Gateways angebunden werden:

• Spokes sind VPC-Attachments. Ein Transit Gateway unterstützt laut den Transit-Gateway-Kontingenten standardmäßig 5.000 Attachments und skaliert damit weit über Peering-Meshes hinaus.
• Segmentierung entsteht durch Transit-Gateway-Routentabellen. Produktions-Attachments sind einer Routentabelle zugeordnet, Entwicklungs-Attachments einer anderen, sodass beide nie die Routen des anderen lernen, aber beide eine Shared-Services-VPC erreichen.
• Inspektion findet in einer dedizierten Inspektions-VPC statt, die AWS Network Firewall oder Appliances von Drittanbietern hinter einem Gateway Load Balancer betreibt. Die Routentabellen der Spokes zeigen auf das Transit Gateway, und Transit-Gateway-Routen schicken den Traffic durch die Inspektions-VPC.
• Appliance Mode am Attachment der Inspektions-VPC hält beide Richtungen eines Flows in derselben Availability Zone, was zustandsbehaftete Firewalls verlangen.
• Zentraler Egress: Eine Egress-VPC mit NAT-Gateways bedient alle Spokes, statt NAT-Gateways in jeder VPC.

Für globale Netze über viele Regionen übernimmt AWS Cloud WAN die Rolle, die Virtual WAN in Azure spielt: ein verwaltetes Kernnetz mit richtlinienbasierten Segmenten.

Die beiden Clouds im Vergleich

Routing, Segmentierung und Symmetrie

Drei Regeln halten ein Hub-and-Spoke-Netz berechenbar:

1. Standardrouten zeigen auf den Hub. Spokes schicken alles, was nicht lokal ist, an den Hub, damit nichts versehentlich die Inspektion umgeht.
2. Segmente sind explizit. Entscheide, welche Spokes mit welchen sprechen dürfen: Produktion und Entwicklung meist nicht, Shared Services sind meist von überall erreichbar, und der Zugriff aufs lokale Netz läuft über die Firewall.
3. Rückverkehr muss denselben Weg nehmen. Eine zustandsbehaftete Firewall verwirft Antworten, deren Hinweg sie nicht gesehen hat. Asymmetrische Routen sind die häufigste Ursache für „die Firewall-Regel ist da, aber nichts funktioniert“.

Schreib den Adressplan auf, bevor der erste Spoke existiert. Überlappende CIDR-Bereiche zwischen Spokes oder mit dem lokalen Netz lassen sich nicht über einen Hub routen und sind später mühsam zu beheben.

Was es kostet

Jedes Byte, das den Hub durchquert, wird irgendwo abgerechnet. In AWS kostet das Transit Gateway zum Zeitpunkt des Schreibens (November 2026) in US East (N. Virginia) 0,05 USD pro Attachment und Stunde und 0,02 USD pro GB verarbeiteter Daten. Zehn Spoke-Attachments kosten etwa 10 × 0,05 USD × 730 Stunden, also rund 365 USD im Monat, noch vor jedem Traffic. Zehn TB Spoke-zu-Spoke-Traffic kommen mit etwa 10.240 GB × 0,02 USD auf rund 205 USD Verarbeitung, plus die eigenen Verarbeitungsgebühren der Firewall. In Azure wird gepeerter Traffic an beiden Enden des Peerings pro GB berechnet, und Azure Firewall kommt mit eigener Verarbeitungsgebühr hinzu.

Die übliche Optimierung ist gezielt: Behalte den Hub für die Richtlinien und ergänze direktes Peering für ein bestimmtes Spoke-Paar, das sehr große Mengen austauscht und keine Inspektion braucht.

Wann Hub-and-Spoke nicht passt

• Zwei oder drei Netze brauchen keinen Hub; direktes Peering ist einfacher.
• Latenzkritischer Ost-West-Traffic zahlt bei jedem Paket einen zusätzlichen Hop und eine Firewall. Miss, bevor du ein gesprächiges Service-Paar durch die Inspektion schickst.
• Riesige interne Volumen können die Verarbeitung pro GB zum größten Netzwerkkostenpunkt machen. Direktes Peering für diese Flows ist oft gerechtfertigt.
• Sehr große Multi-Region-Landschaften sind mit einem verwalteten Hub, Virtual WAN oder Cloud WAN, oft besser bedient als mit handgebauten Routentabellen.

Das Hub-and-Spoke-Diagramm

So liest du es:

• On-Premises oben verbindet sich einmal mit jeder Cloud: mit dem Gateway des Azure-Hubs und mit dem AWS Transit Gateway.
• Der Azure-Rahmen zeigt das Hub-VNet mit Firewall und VPN-Gateway und zwei per Peering verbundene Spokes. Spoke-zu-Spoke-Traffic läuft durch die Firewall.
• Der AWS-Rahmen zeigt das Transit Gateway in der Mitte, die Inspektions-VPC mit ihrer Firewall und zwei angebundene Spoke-VPCs.
• Kantenbeschriftungen nennen den Verbindungstyp: Peering, Attachment, VPN oder Private Circuit.
• Der Markdown-Block listet die Routing-Regeln und die Kostenzahlen von oben auf.

Netzwerktopologien zeichnen, die ein Review überstehen

• Schreib CIDR-Bereiche an jedes Netz. Überlappungen prüft ein Reviewer als Erstes.
• Zeichne die Firewall dort, wo der Traffic wirklich durchläuft, und zeig die Standardroute, die auf sie zeigt.
• Beschrifte jede Verbindung mit ihrem Typ. Peering, Attachment und VPN verhalten sich unterschiedlich und kosten unterschiedlich.
• Ein Diagramm pro Region. Multi-Region-Netze auf einer Leinwand verstecken meist die Verbindungen zwischen Regionen, auf die es ankommt.

Für das Innere eines einzelnen Netzes siehe das AWS-VPC-Diagramm. Das Netzwerktopologie-Diagramm behandelt physische und logische Topologien allgemein, und das Zero-Trust-Architekturdiagramm erklärt, warum die Position im Netz allein keinen Zugriff gewähren sollte. Multi-Region-Designs behandelt das AWS-Multi-Region-Architekturdiagramm.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge oben einen Kasten aus dem Basis-Pack für das On-Premises-Netz hinzu.
3. Füge einen Rahmen aus dem Basis-Pack für Azure hinzu. Darin einen VPC-Node aus dem Netzwerk-Pack für das Hub-VNet, mit einer Firewall und einem Gerät-Node für das VPN-Gateway darin, und zwei weitere VPC-Nodes für die Spokes, jeder mit seinem CIDR.
4. Füge einen Rahmen aus dem Basis-Pack für AWS hinzu. Darin einen Router aus dem Netzwerk-Pack für das Transit Gateway, einen VPC-Node für die Inspektions-VPC mit einer Firewall darin und zwei VPC-Nodes für die Spokes.
5. Verbinde On-Premises mit dem Azure-Gateway und mit dem Transit Gateway, die Spokes mit ihren Hubs, und beschrifte jede Kante mit ihrem Verbindungstyp.
6. Füge einen Markdown-Block aus dem Basis-Pack mit den Routing-Regeln und Kosten hinzu.

Das Beispiel nutzt 14 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist eine Hub-and-Spoke-Netzwerktopologie? Ein Design, in dem ein zentrales Netz, der Hub, gemeinsame Konnektivität, Sicherheit und Dienste enthält und jedes Workload-Netz, ein Spoke, nur mit dem Hub verbunden ist. Traffic zwischen Spokes und ins lokale Netz läuft durch den Hub.

Ist VNet-Peering transitiv? Nein, weder in Azure noch in AWS. Zwei Spokes, die mit demselben Hub gepeert sind, erreichen einander nicht über ihn, es sei denn, Routen schicken ihren Traffic an eine Firewall oder einen Router im Hub.

Was ist der Unterschied zwischen Transit Gateway und VPC-Peering? VPC-Peering verbindet zwei VPCs direkt und ist nicht transitiv. Transit Gateway ist ein regionaler Router, an den viele VPCs und On-Premises-Verbindungen angebunden werden, mit Routentabellen zur Segmentierung.

Sollte ich Azure Virtual WAN statt eines Hub-VNets nutzen? Virtual WAN passt zu großen oder Multi-Region-Landschaften, in denen Microsoft das Hub-Routing und die Gateways verwalten soll. Ein selbst verwalteter Hub bietet mehr Kontrolle und ist für eine Handvoll Spokes in ein oder zwei Regionen üblich.

Was kostet Hub-and-Spoke? Hub-Verbindungen und verarbeiteter Traffic werden pro Stunde und pro GB abgerechnet, plus Firewall-Verarbeitung. In AWS kostet zum Zeitpunkt des Schreibens ein Transit-Gateway-Attachment 0,05 USD pro Stunde und die Datenverarbeitung 0,02 USD pro GB in US East.

Kostenlos starten — ein Seat, keine Kreditkarte.