Hub-and-Spoke-Netzwerktopologie

In diesem Artikel wird erläutert, wie Sie ein Hub-and-Spoke-Netzwerk in Azure entwerfen. Ein zentraler virtueller Hub hostt gemeinsame Dienste, während isolierte virtuelle Netzwerke einzelne Workloads hosten.

Inhalt dieses Artikels

In diesem Artikel werden gemeinsam genutzte Dienste in virtuellen Hubnetzwerken, die Spoke-Isolation und Routingmuster (Standard, direktes Peering und stempelbasiert) behandelt. Es umfasst auch Gatewaytransit für Hybridkonnektivität und die Skalierung von Hub-Spoke-Topologien mit Azure Virtual Network Manager.

Wer diesen Artikel benötigt

Lesen Sie diesen Artikel, wenn eine oder mehrere dieser Bedingungen gelten:

• Sie benötigen gemeinsame Netzwerkdienste wie Firewall, DNS, Bastion, VPN Gateway oder ExpressRoute für mehrere Workloads.
• Sie möchten die Datenverkehrsüberprüfung, Routingsteuerung oder Verwaltung zentralisieren, anstatt diese Dienste in jedem VNet zu wiederholen.
• Sie benötigen eine wiederholbare Topologie zum Trennen von gemeinsam genutzten Plattformdiensten von Workload-VNets.
• Sie möchten hub-and-spoke mit anderen Transitmodellen vergleichen, bevor Sie Ihre Topologie standardisieren.

Wenn Sie über einen einzelnen Workload ohne Anforderungen für gemeinsame Dienste verfügen, beginnen Sie stattdessen mit einer flachen Netzwerktopologie .

Tip

Einem Szenariopfad folgen? Wählen Sie Ihr Szenario oben auf der Seite aus, um eine maßgeschneiderte Anleitung zu erhalten. Der folgende Kernleitfaden gilt für alle Leser.

Lift-and-Shift-Fokus: Lesen Sie diesen Artikel, wenn Sie lokale Workloads in Azure verschieben und zentrale gemeinsame Dienste (DNS, Firewall, VPN Gateway) über mehrere Speichen-VNets benötigen. Hub-and-Spoke ist die Standardtopologie für Lift-and-Shift-Migrationen mit mehreren Workloads, die eine gemeinsame Infrastruktur in einem einzigen Hub erfordern.

Modernisierungsfokus: Lesen Sie diesen Artikel, wenn Sie PaaS-Dienste in mehreren Regionen bereitstellen und Dual-Hub-Topologie mit IT-eigenen Hubs und app-teameigenen Speichen benötigen. Das Hub-and-Spoke-Modell wird skaliert, um separate Abonnementgrenzen für Plattformdienste und Anwendungsworkloads zu unterstützen.

Cloudübergreifender Fokus: Lesen Sie diesen Artikel, wenn Sie Hub-and-Spoke im Vergleich zu Virtual WAN für die cloudübergreifende Übertragung bewerten. Wenn Ihre cloudübergreifende Landschaft klein genug ist, sodass Virtual WAN nicht gerechtfertigt ist, bietet eine herkömmliche Hub-and-Spoke-Architektur mit VPN-Gateway-Verbindungen zu anderen Clouds einen einfacheren Einstieg.

Azure Dienste und Features

In der folgenden Tabelle sind die Azure Dienste und Features aufgeführt, die eine Hub-and-Spoke-Topologie unterstützen:

Dienst oder Feature	Rolle im Hub-Spoke	Weitere Informationen
Virtuelles Azure-Netzwerk	Stellt das Peering für die virtuellen Hub- und Spoke-Netzwerke bereit.	Virtuelle Netzwerke im Überblick
VNet-Peering	Verbindet jede Speichen mit dem Hub.	Peering in virtuellen Netzwerken
Azure Firewall	Zentrale Verkehrsüberprüfung und -filterung im Hub	Übersicht über Azure Firewall
VPN Gateway oder ExpressRoute-Gateway	Hybridkonnektivität, die über alle Speichen hinweg gemeinsam genutzt wird	übersicht über VPN Gateway
Azure Bastion	Sicherer Remotezugriff auf VMs über gekoppelte Spokes	Übersicht über Azure Bastion
Azure Privates DNS Resolver	DNS-Weiterleitung zwischen Azure und lokal	Übersicht über Privates DNS Resolver
Azure DDoS-Schutz	Gemeinsam genutzter DDoS-Schutzplan für öffentliche IP-Adressen von Spokes	Übersicht über DDoS Protection
Azure Virtual Network Manager (AVNM)	Automatisiertes Spoke-Peering, UDR-Verwaltung und Netzwerkgruppen im großen Umfang	AVNM-Übersicht

So funktioniert es

In einer Hub-and-Spoke-Topologie:

1. Ein virtuelles Hubnetzwerk fungiert als zentraler Punkt der Konnektivität. Sie enthält gemeinsame Netzwerkdienste wie eine Firewall, ein Gateway und bastion-Host.
2. Virtuelle Spoke-Netzwerke sind per Peering mit dem Hub verbunden. Jeder Spoke beherbergt eine Workload: eine Anwendung, eine Teamumgebung oder einen isolierten Dienst.
3. VNet-Peering ist nicht transitiv. Spokes können den Hub erreichen, aber Spokes können sich gegenseitig nicht direkt über den Hub erreichen, es sei denn, Sie konfigurieren Routing oder direktes Peering zwischen ihnen.

Was im virtuellen Hubnetzwerk passiert

Verwenden Sie die folgende Tabelle, um zu bestimmen, welche Dienste in Ihrem Hub platziert werden sollen:

Service	Einschließen?	Hinweise
Azure Firewall	Empfohlen	Stellt eine zentrale Verkehrsüberprüfung für den gesamten Ost-West- und Nord-Süd-Verkehr bereit. Erfordert ein Subnetz mit dem exakten Namen AzureFirewallSubnet.
VPN- oder ExpressRoute-Gateway	Wenn Hybridkonnektivität erforderlich ist	Alle Spokes teilen sich ein einzelnes Gateway über die Gatewaytransit. Erfordert ein Subnetz, das genau GatewaySubnet benannt ist (minimum /27).
Azure Bastion	Empfohlen	Ein Bastion-Host im Hub erreicht VMs in allen per Peering verbundenen Spoke-virtuellen Netzwerken. Erfordert die Basic-SKU oder höher: Die Entwickler-SKU unterstützt keinen Zugriff auf Cross-VNet-Peering.
Privater DNS-Resolver	Wenn benutzerdefiniertes DNS erforderlich ist	Leitet DNS-Abfragen zwischen Azure gehosteten privaten DNS-Zonen und lokalen DNS-Servern weiter.
Azure DDoS-Schutzplan	Wenn der DDoS-Schutz aktiviert ist	Ein einzelner Plan kann öffentliche IP-Adressen in allen mit dem Hubabonnement verknüpften virtuellen Netzwerken schützen.

Important

Halten Sie Anwendungsworkloads vom Hub fern. Der Hub hostet nur gemeinsame Infrastrukturdienste: Firewall, Gateways, Bastion und DNS. Anwendungs-VMs, Container und PaaS-Ressourcen werden in virtuellen Spoke-Netzwerken bereitgestellt. Diese Trennung sorgt dafür, dass der Hub sauber bleibt, Peering vereinfacht und das Plattformteam gemeinsam genutzte Dienste unabhängig von Anwendungsteams verwalten kann.

Layout des Hub-Subnetzes

Ein gut gestaltetes virtuelles Hubnetzwerk umfasst in der Regel die folgenden Subnetze:

Subnetzname	Purpose	Mindestgröße
AzureFirewallSubnet	Azure Firewall Bereitstellung	/26
AzureFirewallManagementSubnet	Management-NIC für erzwungenes Tunneln (nur Standard/Premium)	/26
GatewaySubnet	VPN- und ExpressRoute-Gateways	/27
AzureBastionSubnet	Azure Bastion	/26
Inbound-Subnetz des DNS-Resolvers	eingehender Endpunkt des Privates DNS-Resolvers	/28
Ausgehendes Subnetz des DNS-Resolvers	Ausgehender Endpunkt des Privates DNS-Resolvers	/28

Detaillierte Anleitungen zur Subnetzgröße finden Sie unter VNets und Subnetze.

Auswählen einer Variante

Das Hub-and-Spoke-Modell hat drei gängige Varianten. Wählen Sie basierend auf Ihren Isolations- und Kommunikationsanforderungen aus:

Variante	Verkehrspfad	Wann verwenden?
Standard-Hub-and-Spoke	Der gesamte Spoke-zu-Spoke-Datenverkehr wird über die Hub-Firewall geleitet.	Sie benötigen eine zentrale Inspektion des Datenverkehrs. Spokes erfordern keine direkte Peer-to-Peer-Kommunikation.
Hub-and-Spoke mit direktem Peering	Bestimmte Spoke-Paare stehen zudem in direkter Verbindung zueinander	Eng gekoppelte Workloads benötigen eine latenzarme Spoke-zu-Spoke-Kommunikation, ohne die Firewall zu durchlaufen.
Stempel (vollständig isoliert)	Kein Hub. Jedes virtuelle Netzwerk ist vollständig unabhängig.	Strikte Isolation zur Begrenzung des Auswirkungsbereichs, compliancebedingte Trennung oder mandantenfähiges SaaS mit unabhängigen Stacks.

Standard-Hub-and-Spoke

Diese Variante ist am häufigsten. Der gesamte Spoke-zu-Spoke-Datenverkehr durchläuft zur Überprüfung die Firewall des Hubs. Speichen kommunizieren nur über den Hub, nie direkt.

Routingmuster: Wenden Sie auf jedes Spoke-Subnetz eine benutzerdefinierte Route (UDR) mit der Standardroute (0.0.0.0/0) an, die auf die private IP-Adresse der Hub-Firewall verweist. Dies erzwingt, dass der gesamte ausgehende Datenverkehr, einschließlich des Spoke-zu-Spoke-Datenverkehrs, zur Protokollierung und Filterung durch die Firewall geleitet wird.

Peeringlimit: Ein einzelnes virtuelles Hub-Netzwerk unterstützt bis zu 500 Peeringverbindungen (Standardplattformlimit). Wenn Sie Azure Virtual Network Manager (AVNM) mit einer Hub-Spoke-Konnektivitätskonfiguration verwenden, erhöht sich der Grenzwert auf 1.000 Speichen.

Hub-and-Spoke mit direktem Peering

In einigen Architekturen benötigen bestimmte Speichenpaare eine Kommunikation mit geringer Latenz, ohne die Hubfirewall zu durchlaufen. Richten Sie in diesen Fällen direktes VNet-Peering zwischen den beiden Spokes ein, oder verwenden Sie mit AVNM verbundene Gruppen.

Verwenden Sie in folgenden Fällen ein direktes Spoke-Peering:

• Zwei Workloads tauschen Daten mit hohem Durchsatz aus (z. B. Datenbankreplikation zwischen Speichen).
• Die Latenz des Firewall-Hops ist für einen bestimmten Datenpfad nicht akzeptabel.
• Sie erkennen an, dass direkt über Peering geleiteter Datenverkehr die Überprüfung durch die zentrale Firewall umgeht.

Note

Das Peering zwischen Spokes entfernt nicht die Notwendigkeit für den Hub. Zum Hub gerichteter Datenverkehr (ausgehender Datenverkehr, hybride Konnektivität, gemeinsam genutzte Dienste) wird weiterhin über die Hub-Firewall geleitet.

Stempelmuster (vollständig isoliert)

Das Stamps-Muster ist eine Alternative für Szenarien, in denen eine strikte Isolierung des Auswirkungsbereichs erforderlich ist. Jede Workload wird in einem vollständig unabhängigen virtuellen Netzwerk ohne Hub und ohne Peering zu anderen Workloads bereitgestellt.

Wann Stempel verwendet werden:

• Für die Einhaltung gesetzlicher Vorschriften ist kein Netzwerkpfad zwischen Workloads erforderlich.
• Mandantenfähige SaaS-Lösung, bei der jeder Mandant über einen unabhängigen Stack verfügt.
• Maximale Fehlerisolation: Ein Fehler in einem Stempel kann nicht an andere weitergegeben werden.

Beispiel: Mehrinstanzenfähige SaaS-Isolation

Ein SaaS-Anbieter hostet jeden Unternehmenskunden in einem dedizierten Stempel. Jeder Stempel enthält ein eigenes VNet (10.x.0.0/16), Anwendungsgateway, Computeebene und Datenbank. Es gibt kein VNet-Peering zwischen den Stempeln, sodass eine falsch konfigurierte NSG oder eine kompromittierte Workload im Stempel von Mandant A die Ressourcen von Mandant B über das Netzwerk nicht erreichen kann. Der Anbieter verwaltet Stempel über Azure Resource Manager Vorlagen und stellt sie in separaten Ressourcengruppen oder separaten Abonnements für große Mandanten bereit. Der mandantenübergreifende Datenaustausch verwendet bei Bedarf einen freigegebenen Azure Service Bus Namespace. Jeder Stempel greift über private Endpunkte auf diesen Namespace zu.

Kompromisse:

• Keine gemeinsamen Dienste. Jeder Stempel benötigt einen eigenen Firewall-, Gateway- und Bastion-Host (falls erforderlich), wodurch die Kosten erhöht werden.
• Keine Kommunikation zwischen Workloads über private Netzwerke.
• Der Betriebsaufwand erhöht sich, da Sie unabhängige Netzwerke anstelle einer zentralen Infrastruktur verwalten.
• Die Kosten steigen linear mit der Anzahl der Stamps, da Einsparungen durch gemeinsam genutzte Dienste nicht greifen.

Wenn Ihre Workloads gemeinsame Dienste oder arbeitsübergreifende Kommunikation benötigen, verwenden Sie stattdessen die standardmäßige Hub-and-Spoke-Variante.

Spoke-zu-Spoke-Kommunikationsmuster

Da das VNet-Peering nicht transitiv ist, erfordert die Spoke-zu-Spoke-Kommunikation explizites Routing. In diesem Abschnitt wird erläutert, wie der Datenverkehr zwischen Speichen mithilfe der Hubfirewall fließt.

Datenverkehrsfluss: Spoke A zu Spoke B über die Hub-Firewall

Die folgende Sequenz beschreibt, wie ein Paket von einem virtuellen Computer in Spoke A (10.1.0.4) zu einem virtuellen Computer in Spoke B () reist (10.2.0.4):

1. Spoke A VM sendet ein Paket mit dem Ziel 10.2.0.4. Die effektive Routentabelle der VM enthält eine UDR mit 0.0.0.0/0 → 10.0.1.4 (der privaten IP-Adresse von Azure Firewall).
2. Das Paket überschreitet den VNet-Peeringlink von Spoke A zum Hub-VNet. Durch Peering kann Datenverkehr das Subnetz der Firewall erreichen.
3. Azure Firewall empfängt das Paket auf seiner internen Schnittstelle. Es wertet das Paket anhand von Netzwerkregeln und Anwendungsregeln in Prioritätsreihenfolge aus.
4. Wenn eine Regel den Fluss zulässt, leitet die Firewall das Paket an 10.2.0.4. Das Paket überschreitet die Hub-zu-Spoke-B Peering-Verknüpfung.
5. Die VM Spoke B empfängt das Paket. Der Rückverkehr folgt demselben Pfad in umgekehrter Richtung. Die UDR von Spoke B sendet die Antwort zurück über die Firewall.

Konfigurieren der Routentabellen

Wenden Sie diese Routentabellen an, um das vorherige Muster zu aktivieren:

1. Erstellen Sie eine Routentabelle für Speichensubnetze. Deaktivieren Sie die BGP-Routenverteilung, wenn Sie verhindern möchten, dass lokale Routen Ihre UDRs außer Kraft setzen.
2. Fügen Sie eine Standardroute (0.0.0.0/0) mit dem nächsten Hoptyp VirtualAppliance und der nächsten Hopadresse hinzu, die auf die Azure Firewall private IP festgelegt ist.
3. Ordnen Sie die Routentabelle jedem Spoke-Subnetz zu, das andere Spokes oder das Internet erreichen muss.
4. Erstellen Sie Firewallregeln, die den spezifischen Spoke-zu-Spoke-Datenverkehr zulassen. Erlauben Sie beispielsweise 10.1.0.0/16 → 10.2.0.0/16 über die Ports 443 und 1433.

Tip

Verwenden Sie IP-Gruppen in Azure Firewall, um Sprachadressbereiche zu organisieren. Dadurch wird die Regelverwaltung beim Hinzufügen von Speichen vereinfacht.

Alternative: AVNM-verbundene Gruppen für direktes Spoke-zu-Spoke

Wenn Sie keine Firewallüberprüfung zwischen bestimmten Speichen benötigen, stellen verbundene AVNM-Gruppen ein Gitterverbindungsmodell bereit. Spokes in derselben verbundenen Gruppe kommunizieren direkt, ohne den Hub zu durchlaufen. Dadurch werden Latenz- und Firewalldurchsatzanforderungen reduziert, die zentrale Inspektion wird jedoch umgangen.

Important

Wenn Sie die erzwungene Tunnelung auf Azure Firewall aktivieren (um internetgebundenen Datenverkehr an eine lokale Appliance weiterzuleiten), benötigen Sie die Standard- oder Premium-Stufe. Das erzwungene Tunneling erfordert auch ein Verwaltungssubnetz (AzureFirewallManagementSubnet) und deaktiviert DNAT-Regeln.

Gatewaytransit

Durch die Gatewaytransit können alle Speichen ein einzelnes VPN- oder ExpressRoute-Gateway teilen, das im Hub bereitgestellt wird. Ohne Gatewaytransit benötigt jeder Spoke ein eigenes Gateway, um On-Premises-Netzwerke zu erreichen.

Konfigurationsschritte

1. Stellen Sie ein VPN- oder ExpressRoute-Gateway im Hub bereit GatewaySubnet.
2. Auf der hubseitigen Peering-Verbindung (Hub → Spoke): Gatewaytransit zulassen aktivieren.
3. Auf der Spoke-seitigen Peering-Verbindung (Spoke → Hub): Remote-Gateways verwenden aktivieren.
4. Überprüfen der Routenverteilung. Überprüfen Sie nach der Konfiguration die effektiven Routen auf der NIC einer Spoke-VM. In der Routentabelle werden On-Premises-Präfixe angezeigt, die über das Hub-Gateway mit einem nächsten Hop-Typ VNetGlobalPeering oder VNetPeering erlernt wurden.

Bei entsprechender Konfiguration werden die vom Hubgateway erlernten Routen (z. B. On-Premises-Präfixe aus ExpressRoute) automatisch an die Routingtabellen der Spokes weitergegeben.

Einschränkungen beim Gateway-Transit

• Die Gatewaytransit funktioniert mit allen VPN Gateway Ebenen außer der Stufe "Einfach". Wenn Sie das Basic-VPN-Gateway verwenden, können Sie es nicht mit gekoppelten virtuellen Netzwerken gemeinsam nutzen.
• Ein virtuelles Spoke-Netzwerk kann nur ein Remote-Gateway verwenden. Sie können Use remote gateways in einem Spoke, das per Peering mit mehreren Hubs verbunden ist, nicht aktivieren.
• Wenn Sie UDRs verwenden, um den Datenverkehr durch die Firewall zu erzwingen, stellen Sie sicher, dass die UDRs nicht unbeabsichtigt die vom Gateway propagierten On-Premises-Routen überschreiben. Legen Sie bei Bedarf spezifischere Routen für lokale Präfixe fest.

Note

Wenn Sie ExpressRoute mit Gatewaytransit verwenden, aktivieren Sie Gatewaytransit zulassen, bevor Sie die Spoke-Peerings erstellen. Das Gateway muss zuerst vorhanden sein und bereitgestellt werden.

Azure Virtual Network Manager im großen Maßstab

Wenn Ihre Umgebung über eine Handvoll Spokes hinaus wächst, wird die manuelle Verwaltung von Peering-Verbindungen und Routentabellen komplex. AVNM bietet Automatisierung für Hub-Spoke-Topologien:

AVNM-Fähigkeit	Was es bewirkt
Konfiguration der Hub-Spoke-Konnektivität	Erstellt und verwaltet automatisch Peering zwischen dem Hub und allen Speichen in einer Netzwerkgruppe. Unterstützt bis zu 1.000 Speichen pro Hub.
Verbundene Gruppen	Ermöglicht direkte Spoke-zu-Spoke-Konnektivität ohne manuelles Peering. Standardgrenzwert: 250 virtuelle Netzwerke pro Gruppe (erweiterbar auf 1.000 nach Anforderung).
Netzwerkgruppen mit dynamischer Mitgliedschaft	Verwendet Bedingungen in Azure Policy, um virtuelle Netzwerke basierend auf Tags, Namen oder Abonnements automatisch zu Gruppen hinzuzufügen.
UDR-Verwaltung	Automatisiert die Bereitstellung von Routentabellen in mehreren Hub-Spoke-Topologien.

AVNM ist besonders nützlich, wenn Sie Hub-Spoke-Topologien in mehreren Regionen verwalten oder eine dynamische Mitgliedschaft benötigen, wenn neue virtuelle Spoke-Netzwerke online sind.

Überlegungen zur Skalierung

Wenn Ihre Hub-Spoke-Topologie wächst, planen Sie die folgenden Plattformgrenzen und Organisationsmuster:

Peering- und Konnektivitätsgrenzwerte

Dimension	Grenzwert für „Standard“	Mit AVNM	Hinweise
VNet-Peerings pro virtuellem Netzwerk	500	1.000 (Hub-Spoke-Konfiguration)	Jedes Spoke-zu-Hub-Peering belegt auf beiden Seiten jeweils einen Slot.
Virtuelle Netzwerke pro mit AVNM verbundener Gruppe	250 (Standard)	Bis zu 1.000 (nach Anfrage)	Erhöhung über den Azure-Support anfordern
Abonnements pro AVNM-Bereich	N/A	1,000	Der Geltungsbereich kann sich über mehrere Abonnements in einer Verwaltungsgruppe erstrecken

Abonnementorganisation

• Teilen Sie Spokes in workloadspezifische Abonnements auf für Umgebungen mit mehr als 10 Spokes. Dadurch werden Abrechnung, RBAC und Kontingentgrenzen für jedes Workload-Team voneinander getrennt.
• Verwenden Sie ein dediziertes Konnektivitätsabonnement für das Hub-VNet, Gateways und die Firewall. Dies ist das von Azure Landing Zones empfohlene Muster (Plattformabonnement).
• Gruppieren Sie Abonnements unter einer Verwaltungsgruppe, damit AVNM Spoke-VNets abonnementübergreifend mithilfe von Azure Policy-Bedingungen dynamisch erkennen und verwalten kann.

Topologie mit Azure Policy erzwingen

Verwenden Sie Azure Policy, um Konfigurationsabweichungen zu verhindern:

• Peering mit Nicht-Hub-VNets ablehnen. Weisen Sie auf Verwaltungsgruppenebene eine Richtlinie zu, die die Erstellung von VNet-Peering verhindert, es sei denn, das Ziel ist das vorgesehene Hub-VNet.
• UDR-Zuordnung erforderlich machen. Weisen Sie eine Richtlinie zu, die Spoke-Subnetze überprüft (oder verweigert), die keine Routentabelle mit der Route 0.0.0.0/0 → Firewall enthalten.
• Erzwingen sie die AVNM-Gruppenmitgliedschaft. Verwenden Sie dynamische Mitgliedschaftsregeln in AVNM basierend auf Tags (z. B NetworkRole:Spoke. ), sodass neue VNets automatisch registriert werden.

Migrationspfad von flach zu Hub-Spoke

Wenn Sie mit einer Flachnetzwerktopologie begonnen haben und Ihre Umgebung gewachsen ist, um gemeinsame Dienste oder Segmentierung zwischen Arbeitsauslastungen zu erfordern, befolgen Sie diesen Migrationspfad:

Schritt 1: Planen des Hub-VNet

1. Weisen Sie dem Hub einen neuen Adressraum zu (z. B. 10.0.0.0/16), der sich nicht mit Ihrem bestehenden Flat-VNet überschneidet.
2. Ermitteln Sie, welche gemeinsamen Dienste bereitgestellt werden sollen: Firewall, Gateway, Bastion, DNS-Resolver.
3. Dimensionieren Sie Hub-Subnetze gemäß der Tabelle zum Hub-Subnetzlayout.

Schritt 2: Bereitstellen gemeinsamer Dienste im Hub

1. Erstellen Sie das Hub-VNet und stellen Sie Azure Firewall bereit (oder die NVA Ihrer Wahl).
2. Stellen Sie das VPN/ExpressRoute-Gateway bereit, wenn Sie eine Hybridverbindung benötigen.
3. Stellen Sie Azure Bastion für den sicheren VM-Zugriff bereit.
4. Konfigurieren Sie Privates DNS Resolver, wenn Sie benutzerdefiniertes DNS verwenden.

Schritt 3: Migrieren von Workloads in Spokes

1. Erstellen Sie Spoke-VNets mit neuen Adressräumen für jede Arbeitslast. Wenn Sie keine IP-Adressen neu zuweisen können, können Sie vorhandene IP-Bereiche beibehalten, solange diese sich nicht mit dem Hub überschneiden.
2. Peering jedes Spokes mit dem Hub. Aktivieren Sie Gatewaytransit auf der Hub-Seite und verwenden Sie Remote-Gateways auf der Spoke-Seite.
3. Wenden Sie UDRs auf Speichensubnetze an, wobei die Standardroute auf die Hubfirewall verweist.
4. Verschieben oder erneutes Bereitstellen von VMs und Diensten aus dem flachen VNet in die entsprechende Speichen. Verwenden Sie je nach Workloadkomplexität Azure Resource Mover oder die erneute Bereitstellung.
5. Erstellen Sie Firewallregeln, um die Datenverkehrsmuster zwischen den Spokes sowie zwischen den Spokes und dem Internet zuzulassen, die Sie zuvor innerhalb des flachen VNet genehmigt hatten.

Schritt 4: Das flache VNet stilllegen

1. Überprüfen Sie, ob alle Workloads über die neue Hub-Spoke-Topologie erreichbar sind.
2. Aktualisieren Sie DNS-Einträge, wenn sich private IP-Adressen geändert haben.
3. Entfernen Sie das alte flache VNet, nachdem Sie den gesamten Datenverkehr migriert und überprüft haben.

Tip

Migrieren Sie Arbeitslasten in Phasen. Beginnen Sie mit einer nicht kritischen Workload, um die Routing- und Firewallregeln zu überprüfen, und fahren Sie dann mit Produktionsworkloads fort.

Wann sollten Sie stattdessen Virtual WAN in Betracht ziehen?

Wenn Ihre Hub-Spoke-Topologie in der Komplexität wächst, bewerten Sie, ob Azure Virtual WAN eine bessere Anpassung bietet:

Faktor	Hub-and-Spoke (herkömmlich)	Azure Virtual WAN
Management	Vom Kunden verwaltete Hubinfrastruktur	Microsoft verwaltetes Hubrouting und Konnektivität
Am besten geeignet für:	Weniger als 30 VPN-Verzweigungsverbindungen, vollzugriff erforderlich	30+ VPN-Zweigstellen, viele Azure Regionen
Routing	Der Kunde konfiguriert UDRs manuell	Automatisches Routing im Hub
SD-WAN-Integration	Manuelle NVA-Bereitstellung	Systemeigene SD-WAN Partnerintegration
Globaler Transit	Erfordert das vom Kunden verwaltete Inter-Hub-Routing	Integriert: Alle Hubs verbinden sich automatisch

Einen detaillierten Vergleich finden Sie unter Azure Virtual WAN Topologie.

Überlegungen zum Entwurf

Stellen Sie für eine Lift-and-Shift-Migration einen einzelnen Hub mit gemeinsamen Diensten bereit, die von allen zu migrierenden Workloads genutzt werden:

• Einzelner Hub mit VPN Gateway. Stellen Sie VPN Gateway (oder ExpressRoute-Gateway) im GatewaySubnet des Hubs bereit. Alle Workloads in den Spoke-Netzwerken nutzen dieses Gateway über Gatewaytransit für die Konnektivität mit der lokalen Umgebung während und nach der Migration.
• Azure Bastion im Hub. Eine einzelne Bastion-Bereitstellung im Hub bietet sicheren RDP/SSH-Zugriff auf VMs über alle peered Spokes hinweg, ohne öffentliche IPs auf migrierten Servern verfügbar zu machen.
• Zentrale Firewall für ausgehenden Datenverkehr. Stellen Sie Azure Firewall im Hub bereit. Konfigurieren Sie UDRs in allen Spoke-Subnetzen, wobei die Standardroute auf die Firewall verweist. Der gesamte ausgehende sowie der gesamte Spoke-zu-Spoke-Datenverkehr fließt über diesen einen zentralen Inspektionspunkt.
• Beginnen Sie mit einem Hub, fügen Sie Speichen inkrementell hinzu. Koppeln Sie während der Migration das Spoke-VNet jeder Workload per Peering mit dem Hub. Ein einzelner Hub unterstützt bis zu 500 Peeringverbindungen (1.000 mit AVNM).

Planen Sie für ein Migrations- und Modernisierungsszenario die Dual-Hub-Topologie, die die Plattforminfrastruktur von Anwendungsworkloads trennt:

• Dual-Hub-Bereitstellung. Stellen Sie einen Hub in Ihrer primären Region und einen zweiten Hub in Ihrer Sicherungsregion bereit. Jeder Hub enthält eine eigene Firewall, ein Gateway und bastion. Dies unterstützt aktiv-aktive Architekturen für PaaS-Workloads.
• Von der IT verwaltete Hubs, von App-Teams verwaltete Spokes. Das Plattformteam verwaltet Hubabonnements (Verbindungsabonnementmuster, ein dediziertes Azure-Abonnement für freigegebene Hubnetzwerkressourcen, getrennt von Workloadabonnements). Anwendungsteams verwalten ihre Spoke-Abonnements mit delegierter Kontrolle über ihre Private-Link-Subnetze und Workloadressourcen.
• Private-Link-Subnetze pro Spoke. Jedes Speichen-VNet enthält ein dediziertes Subnetz für private Endpunkte. Anwendungsteams erstellen Private Link Verbindungen mit ihren PaaS-Diensten (Azure SQL, Speicher, Key Vault) innerhalb ihrer eigenen Speichen.
• Hub-Firewall als SNAT/DNAT. Die zentrale Firewall in jedem Hub stellt Quell-NAT für ausgehenden Datenverkehr und Ziel-NAT für eingehende Datenverkehrsmuster bereit. Anwendungsteams können die zentrale Inspektion nicht umgehen.

Für cloudübergreifende Konnektivität sollten Sie bewerten, ob ein traditionelles Hub-Spoke-Modell oder ein Virtual WAN das passende Transitmodell bietet:

• Entscheidung zwischen Hub-Spoke und Virtual WAN. Wenn Sie weniger als 30 Zweigstellenverbindungen haben, eine kleine Anzahl von cloudübergreifenden VPN-Tunneln und in einer oder zwei Azure Regionen arbeiten, ist herkömmliche Hub-Spoke mit VPN Gateway einfacher. Wenn Sie über viele VPCs, Filialen, Regionen oder Cloud-Edges verfügen, bietet Virtual WAN automatisiertes Routing, das besser skaliert wird.
• VPN Gateway für cloudübergreifende Tunnel. Stellen Sie in einem Hub-Spoke-Modell VPN Gateway im Hub bereit, und erstellen Sie Standort-zu-Standort-Verbindungen mit AWS Virtual Private Gateways und Google Cloud VPN-Endpunkten. Jede Verbindung verwendet IPSec/IKE-Verschlüsselung.
• Bewerten Sie das Komplexitätswachstum. Wenn Ihre cloudübergreifende Umgebung wächst (mehr AWS-Konten, Google-Cloud-Projekte oder Azure-Regionen), bewerten Sie die Entscheidung zwischen Hub-Spoke-Architektur und Virtual WAN erneut. Virtual WAN wird kostengünstiger, wenn viele Tunnel in großem Umfang verwaltet werden.

Einen vollständigen Vergleich finden Sie unter Azure Virtual WAN Topologie.

Voraussetzungen

Bevor Sie ein Hub-and-Spoke-Netzwerk entwerfen:

• Schließen Sie Ihr virtuelles Netzwerk und Ihren Subnetzplan ab. Sie sollten wissen, wie viele Spokes Sie benötigen und welche Subnetze jeder Spoke benötigt.
• Definieren Sie Ihr IP-Adressschema. Hub- und Spoke-Adressräume dürfen sich nicht überlappen.
• Verstehen Sie, dass VNet-Peering nicht transitiv ist: Speichen erben keine Konnektivität mit anderen Speichen über den Hub.

Sicherheitsüberlegungen

Eine Hub-and-Spoke-Topologie zentralisiert die Durchsetzung von Sicherheitsrichtlinien im Hub. Wenden Sie die folgenden Prinzipien an:

• Leiten Sie den gesamten Spoke-Datenverkehr über die Hub-Firewall weiter. Verwenden Sie UDRs mit der Standardroute, die auf die Firewall zeigt. Diese Konfiguration stellt sicher, dass die Firewall jeden Speichen-zu-Speichen- und Speichen-zu-Internet-Fluss prüft und protokolliert.
• Verwenden Sie NSGs auf Spoke-Subnetzen zur mehrschichtigen Absicherung. Auch bei einer zentralen Firewall bieten Netzwerksicherheitsgruppen in speichensubnetzen eine zusätzliche Segmentierungsebene. Unerwarteten lateralen Datenverkehr auf Subnetzebene verweigern. Anleitungen zum NSG-Entwurf finden Sie unter Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen.
• Aktivieren Sie den Gateway-Transit mit Vorsicht. Gatewaytransit macht lokale Routen für alle Spokes verfügbar. Stellen Sie sicher, dass Firewallregeln die erweiterte Konnektivität berücksichtigen.
• Entfernen Sie öffentliche IP-Adressen von Spoke-VMs. Azure Bastion im Hub bietet sicheren Verwaltungszugriff, ohne VMs im Internet verfügbar zu machen.
• Betrachten Sie jeden Spoke als Sicherheitsgrenze. Workloads in verschiedenen Spokes sind standardmäßig voneinander isoliert. Für die Konnektivität zwischen Speichen sind explizite Routing- und Firewallregeln erforderlich.

Verwandte Artikel

• Flache Netzwerktopologie: für einzelne Workloads, die keine gemeinsamen Dienste benötigen
• Azure Virtual WAN Topologie: für verwaltetes Routing und konnektivität im großen Maßstab
• Netzwerk mit mehreren Regionen: für Workloads, die mehrere Azure Regionen umfassen
• VNets und Subnetze: Subnetzgröße für Hubkomponenten
• IP-Adressplanung: CIDR-Planung für Hub und Speichen
• Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen: Ausführliche Verteidigung in gesprochenen Subnetzen

Weitere Informationen

• Hub-Spoke-Netzwerktopologie in Azure
• Peering in virtuellen Netzwerken
• Übersicht über Azure Firewall
• Übersicht über Azure Virtual Network Manager
• VPN Gatewaytransit für Peering
• Azure Bastion und VNet-Peering

Nächste Schritte

Tip

Auf eigene Faust erkunden? Kehren Sie zum Übersichtsnavigator zurück, um Ihren nächsten Artikel nach Funktion zu finden.

Als Nächstes in Ihrer Lift-and-Shift-Reise:

Stellen Sie eine Verbindung mit Ihrem lokalen Netzwerk her: Richten Sie VPN Gateway oder ExpressRoute in Ihrem Hub-VNet ein, um die kritische Migrationsabhängigkeit einzurichten.

Als Nächstes in Ihrer Modernisierungsreise:

Planen Sie Ihre Bereitstellung über mehrere Regionen hinweg: Stellen Sie Ihre kundenorientierten Anwendungen im Active-Active-Modell über primäre und Backupregionen hinweg bereit.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Bewerten Sie Azure Virtual WAN als Ihr Transitmodell: Prüfen Sie, ob Virtual WAN oder das Hub-Spoke-Modell am besten zu Ihrer Cross-Cloud-Umgebung mit mehreren VPCs, Niederlassungen und Regionen passt.