Bearbeiten

Hub-Spoke-Netzwerktopologie in Azure

Azure Bastion
Azure Firewall
Azure Network Watcher
Azure Virtual Network
Azure VPN Gateway

Diese Referenzarchitektur implementiert ein Hub-Spoke-Netzwerkmuster mit kundenseitig verwalteten Hubinfrastrukturkomponenten. Eine von Microsoft verwaltete Hubinfrastrukturlösung finden Sie unter Hub-Spoke-Netzwerktopologie mit Azure Virtual WAN.

Aufbau

Diagramm einer Hub-Spoke-Topologie virtueller Netzwerke in Azure, bei der Spoke-Netzwerke über den Hub oder direkt miteinander verbunden sind.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Diese Hub-Spoke-Netzwerkkonfiguration verwendet die folgenden Architekturelemente:

  • Virtuelle Hub-Netzwerke: Das virtuelle Hubnetzwerk hostet freigegebene Azure-Dienste. Workloads, die in den virtuellen Spoke-Netzwerken gehostet werden, können diese Dienste verwenden. Das virtuelle Hubnetzwerk ist der zentrale Konnektivitätspunkt für Ihre standortübergreifenden Netzwerke.

  • Virtuelle Spoke-Netzwerke: Virtuelle Spoke-Netzwerke isolieren und verwalten Workloads separat in jedem Spoke. Jede Workload kann mehrere Schichten umfassen, wobei mehrere Subnetze über Azure Load Balancer-Instanzen verbunden sind. Spokes können in verschiedenen Abonnements vorhanden sein und unterschiedliche Umgebungen darstellen, z. B. Produktion und Nicht-Produktion.

  • VNET-Konnektivität Diese Architektur verbindet virtuelle Netzwerke mithilfe von Peeringverbindungen oder verbundenen Gruppen. Peeringverbindungen und verbundene Gruppen stellen nicht-transitive Verbindungen zwischen virtuellen Netzwerken mit geringen Wartezeiten dar. Peering-VNets oder verbundene virtuelle Netzwerke können Datenverkehr über den Azure-Backbone austauschen, ohne dass ein Router benötigt wird. Azure Virtual Network Manager erstellt und verwaltet Netzwerkgruppen und deren Verbindungen.

  • Azure Bastion-Host. Azure Bastion bietet sichere Konnektivität vom Azure-Portal zu virtuellen Computern (VMs) unter Verwendung Ihres Browsers. Ein in einem virtuellen Azure-Netzwerk bereitgestellter Azure Bastion-Host kann auf VMs in diesem virtuellen Netzwerk oder in verbundenen virtuellen Netzwerken zugreifen.

  • Azure Firewall. Eine von Azure Firewall verwaltete Firewallinstanz befindet sich in einem eigenen Subnetz.

  • Azure VPN Gateway oder Azure ExpressRoute-Gateway. Mit einem Gateway für virtuelle Netzwerke kann ein virtuelles Netzwerk eine Verbindung mit einem VPN-Gerät (Virtual Private Network) oder einer Azure ExpressRoute-Leitung herstellen. Das Gateway bietet standortübergreifende Netzwerkkonnektivität. Weitere Informationen finden Sie unter Verbinden eines lokalen Netzwerks mit einem virtuellen Microsoft Azure-Netzwerk und Erweitern eines lokalen Netzwerks mithilfe von VPN.

  • VPN-Gerät: Ein VPN-Gerät oder -Dienst stellt externe Konnektivität mit dem standortübergreifenden Netzwerk bereit. Bei dem VPN-Gerät kann es sich um ein Hardwaregerät oder eine Softwarelösung wie den Routing- und RAS-Dienst (RRAS) unter Windows Server handeln. Weitere Informationen finden Sie unter Überprüfte VPN-Geräte und Konfigurationshandbücher für Geräte.

Komponenten

  • Virtual Network Manager ist ein Verwaltungsdienst, mit dem Sie virtuelle Netzwerke im großen Stil in über Azure-Abonnements, Regionen und Mandanten hinweg gruppieren, konfigurieren, bereitstellen und verwalten können. Mit Virtual Network Manager können Sie Gruppen virtueller Netzwerke definieren, um Ihre virtuellen Netzwerke zu identifizieren und logisch zu segmentieren. Sie können Konnektivitäts- und Sicherheitskonfigurationen für alle virtuellen Netzwerke in einer Netzwerkgruppe gleichzeitig definieren und anwenden.

  • Azure Virtual Network ist der grundlegende Baustein für private Netzwerke in Azure. Ein virtuelles Netzwerk ermöglicht vielen Azure-Ressourcen, z. B. Azure-VMs, die sichere Kommunikation untereinander, mit standortübergreifenden Netzwerken und mit dem Internet.

  • Azure Bastion ist ein vollständig verwalteter Dienst, der sichereren und nahtloseren Zugriff per RDP (Remotedesktopprotokoll) und SSH (Secure Shell-Protokoll) auf VMs bietet, ohne deren öffentliche IP-Adressen verfügbar zu machen.

  • Azure Firewall ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst zum Schutz virtueller Netzwerkressourcen. Dieser zustandsbehaftete Firewall-Dienst verfügt über eine integrierte hohe Verfügbarkeit und uneingeschränkte Cloud-Skalierbarkeit, um Sie bei der Erstellung, Durchsetzung und Protokollierung von Anwendungs- und Netzwerkkonnektivitätsrichtlinien für Abonnements und virtuelle Netzwerke zu unterstützen.

  • VPN Gateway ist ein spezifischer Typ von Gateway für virtuelle Netzwerke, das verschlüsselten Datenverkehr zwischen einem virtuellen Netzwerk und einem lokalen Standort über das öffentliche Internet sendet. Ein VPN-Gateway kann aber auch verwendet werden, um verschlüsselten Datenverkehr zwischen virtuellen Azure-Netzwerken über das Microsoft-Netzwerk zu senden.

  • Azure Monitor kann Telemetriedaten aus standortübergreifenden Umgebungen, einschließlich Azure und lokalen Standorten, sammeln, analysieren und verarbeiten. Azure Monitor ermöglicht Ihnen, die Leistung und Verfügbarkeit Ihrer Anwendungen zu maximieren und Probleme proaktiv in Sekundenschnelle zu identifizieren.

Szenariodetails

Diese Referenzarchitektur implementiert ein Hub-Spoke-Netzwerkmuster, bei dem das virtuelle Hubnetzwerk als zentraler Verbindungspunkt für viele virtuelle Spoke-Netzwerke fungiert. Die virtuellen Spoke-Netzwerke stellen eine Verbindung mit dem Hub her und können zur Isolierung von Workloads verwendet werden. Sie können auch standortübergreifende Szenarien ermöglichen, indem Sie den Hub verwenden, um eine Verbindung mit lokalen Netzwerken herzustellen.

Diese Architektur beschreibt ein Netzwerkmuster mit kundenseitig verwalteten Hubinfrastrukturkomponenten. Eine von Microsoft verwaltete Hubinfrastrukturlösung finden Sie unter Hub-Spoke-Netzwerktopologie mit Azure Virtual WAN.

Die Vorteile der Verwendung einer Hub-and-Spoke-Konfiguration umfassen:

  • Kostenersparnis
  • Überwinden von Abonnementgrenzen
  • Workloadisolation

Weitere Informationen finden Sie unter Hub-and-Spoke-Netzwerktopologie.

Mögliche Anwendungsfälle

Typische Verwendungen für eine Hub-and-Spoke-Architektur umfassen Workloads, die:

  • Über mehrere Umgebungen verfügen, die gemeinsam genutzte Dienste erfordern. Beispielsweise kann eine Workload Entwicklungs-, Test- und Produktionsumgebungen aufweisen. Gemeinsam genutzte Dienste können DNS-IDs, NTP (Network Time Protocol) oder Active Directory Domain Services (AD DS) umfassen. Gemeinsam genutzte Dienste werden im virtuellen Hubnetzwerk platziert, und jede Umgebung stellt in einem Spoke bereit, um die Isolation aufrechtzuerhalten.
  • Keine Konnektivität untereinander benötigen, aber Zugriff auf gemeinsam genutzte Dienste erfordern.
  • Zentrale Kontrolle über die Sicherheit erfordern, z. B. eine Firewall im Umkreisnetzwerk (auch bekannt als DMZ) im Hub mit abgetrennter Workloadverwaltung in jedem Spoke.
  • Zentrale Kontrolle über die Konnektivität erfordern, z. B. selektive Konnektivität oder Isolation zwischen Spokes bestimmter Umgebungen oder Workloads.

Empfehlungen

Die folgenden Empfehlungen gelten für die meisten Szenarien. Sofern Sie keine besonderen Anforderungen haben, die Vorrang besitzen, sollten Sie diese Empfehlungen befolgen.

Ressourcengruppen, Abonnements und Regionen

Diese Beispiellösung verwendet eine einzelne Azure-Ressourcengruppe. Sie können den Hub und die einzelnen Spokes auch in verschiedenen Ressourcengruppen und Abonnements implementieren.

Wenn Sie Peering zwischen virtuellen Netzwerken in verschiedenen Abonnements einrichten, können die Abonnements demselben oder unterschiedlichen Microsoft Entra-Mandanten zugeordnet sein. Diese Flexibilität ermöglicht nicht nur eine dezentralisierte Verwaltung der einzelnen Workloads, sondern auch gleichzeitig die Verwaltung gemeinsam genutzter Dienste im Hub. Weitere Informationen finden Sie unter Erstellen des Peerings virtueller Netzwerke: Resource Manager, verschiedene Abonnements und Microsoft Entra-Mandanten.

Als generelle Regel ist es am besten, mindestens einen Hub pro Region zu verwenden. Diese Konfiguration trägt dazu bei, einen Single Point of Failure zu vermeiden, z. B. um zu vermeiden, dass Ressourcen in Region A auf Netzwerkebene von einem Ausfall in Region B betroffen sind.

Subnetze des virtuellen Netzwerks

In den folgenden Empfehlungen wird beschrieben, wie die Subnetze im virtuellen Netzwerk konfiguriert werden sollten.

GatewaySubnet

Das virtuelle Netzwerkgateway erfordert dieses Subnetz. Sie können auch eine Hub-Spoke-Topologie ohne Gateway verwenden, wenn Sie keine standortübergreifende Netzwerkkonnektivität benötigen.

Erstellen Sie ein Subnetz mit dem Namen GatewaySubnet mit einem Adressbereich von mindestens /27. Der Adressbereich /27 bietet dem Subnetz ausreichend Konfigurationsoptionen für die Skalierbarkeit, um das Erreichen der Einschränkungen hinsichtlich der Gatewaygröße in Zukunft zu verhindern. Weitere Informationen zum Einrichten des Gateways finden Sie abhängig von Ihrem Verbindungstyp in den folgenden Referenzarchitekturen:

Um eine höhere Verfügbarkeit zu erzielen, können Sie ExpressRoute mit einem VPN für Failoverzwecke kombinieren. Weitere Informationen finden Sie unter Verbinden eines lokalen Netzwerks mit Azure unter Verwendung von ExpressRoute mit VPN-Failover.

AzureFirewallSubnet

Erstellen Sie ein Subnetz namens AzureFirewallSubnet mit einem Adressbereich von mindestens /26. Unabhängig von der Größe ist der Adressbereich /26 die empfohlene Größe und deckt alle zukünftigen Größeneinschränkungen ab. Dieses Subnetz unterstützt keine Netzwerksicherheitsgruppen (NSGs).

Azure Firewall erfordert dieses Subnetz. Wenn Sie ein virtuelles Netzwerkgerät (NVA) eines Partners verwenden, befolgen Sie dessen Netzwerkanforderungen.

Spoke-Netzwerkkonnektivität

Peering virtueller Netzwerke oder verbundene Gruppen stellen nicht transitive Beziehungen zwischen virtuellen Netzwerken dar. Wenn Sie virtuelle Spoke-Netzwerke zum Herstellen einer Verbindung miteinander benötigen, fügen Sie eine Peeringverbindung zwischen diesen Spokes hinzu, oder platzieren Sie sie in derselben Netzwerkgruppe.

Spoke-Verbindungen über Azure Firewall oder NVA

Die Anzahl der Peerings virtueller Netzwerke pro virtuellem Netzwerk ist begrenzt. Wenn zwischen mehreren Spokes eine Verbindung hergestellt werden muss, können die Peeringverbindungen zur Neige gehen. Verbundene Gruppen unterliegen ebenfalls Einschränkungen. Weitere Informationen finden Sie unter Grenzwerte für Netzwerke und Grenzwerte für verbundene Gruppen.

In diesem Szenario sollten Sie die Verwendung benutzerdefinierter Routen (User Defined Routes, UDRs) in Erwägung ziehen, um zu erzwingen, dass Spoke-Datenverkehr an Azure Firewall oder eine NVA gesendet wird, die als Router im Hub fungiert. Durch diese Änderung können die Spokes eine Verbindung untereinander herstellen. Um diese Konfiguration zu unterstützen, müssen Sie Azure Firewall mit aktivierter Konfiguration für Tunnelerzwingung implementieren. Weitere Informationen finden Sie unter Azure Firewall-Tunnelerzwingung.

Die Topologie in diesem Architekturentwurf erleichtert ausgehende Flows. Obwohl Azure Firewall in erster Linie der ausgehenden Sicherheit dient, kann es auch als Eingangspunkt verwendet werden. Weitere Überlegungen zum Eingangsrouting für NVA finden Sie unter Firewall und Application Gateway für virtuelle Netzwerke.

Spoke-Verbindungen mit Remotenetzwerken über ein Hubgateway

Um Spokes für die Kommunikation mit Remotenetzwerken über ein Hubgateway zu konfigurieren, können Sie Peerings virtueller Netzwerke oder verbundene Netzwerkgruppen verwenden.

So verwenden Sie Peerings virtueller Netzwerke im Peering-Setup für virtuelle Netzwerke:

  • Konfigurieren Sie die Peeringverbindung im Hub so, dass sie Gatewaytransit Zulässt.
  • Konfigurieren Sie die Peeringverbindung in jedem Spoke so, dass sie das Gateway des virtuellen Remotenetzwerks verwendet.
  • Konfigurieren Sie alle Peeringverbindungen so, dass sie weitergeleiteten Datenverkehr Zulassen.

Weitere Informationen finden Sie unter Erstellen eines Peerings virtueller Netzwerke.

So verwenden Sie verbundene Netzwerkgruppen

  1. Erstellen Sie in Virtual Network Manager eine Netzwerkgruppe, und fügen Sie virtuelle Mitgliedernetzwerke hinzu.
  2. Erstellen einer Hub-and-Spoke-Konnektivitätskonfiguration.
  3. Wählen Sie für die Spoke-Netzwerkgruppen die Option Hub als Gateway aus.

Weitere Informationen finden Sie unter Erstellen einer Hub-and-Spoke-Topologie mit Azure Virtual Network Manager.

Spoke-Netzwerkkommunikation

Es gibt zwei Hauptmethoden, mit denen virtuelle Spoke-Netzwerke untereinander kommunizieren können:

  • Kommunikation über eine NVA wie eine Firewall und einen Router. Diese Methode verursacht einen Hop zwischen den beiden Spokes.
  • Kommunikation mithilfe des Peerings virtueller Netzwerke oder Virtual Network Manager-Direktkonnektivität zwischen Spokes. Dieser Ansatz verursacht keinen Hop zwischen den beiden Spokes und wird zur Minimierung der Wartezeit empfohlen.

Kommunikation über eine NVA

Wenn Sie Konnektivität zwischen Spokes benötigen, sollten Sie Azure Firewall oder eine andere NVA im Hub bereitstellen. Erstellen Sie dann Routen, um den Datenverkehr von einem Spoke an die Firewall oder NVA weiterzuleiten, die dann an den zweiten Spoke weiterleiten kann. In diesem Szenario müssen Sie die Peeringverbindungen dahingehend konfigurieren, dass weitergeleiteter Verkehr zugelassen wird.

Diagramm, dass das Routing zwischen Spokes mithilfe von Azure Firewall zeigt.

Sie können auch ein VPN-Gateway verwenden, um Datenverkehr zwischen Spokes weiterzuleiten, obgleich sich diese Auswahl auf die Wartezeit und den Durchsatz auswirkt. Weitere Detailinformationen zur Konfiguration finden Sie unter Konfigurieren des VPN-Gatewaytransits für ein Peering virtueller Netzwerke.

Evaluieren Sie die Dienste, die Sie im Hub freigeben, um sicherzustellen, dass sich der Hub für eine größere Anzahl von Spokes skalieren lässt. Wenn Ihr Hub beispielsweise Firewalldienste bereitstellt, sollten Sie beim Hinzufügen mehrerer Spokes die Bandbreitenbeschränkungen Ihrer Firewalllösung berücksichtigen. Sie können einige dieser freigegebenen Dienste auf eine zweite Hubebene verlagern.

Direkte Kommunikation zwischen Spoke-Netzwerken

Um eine direkte Verbindung zwischen virtuellen Spoke-Netzwerken herzustellen, ohne das virtuelle Hubnetzwerk zu durchlaufen, können Sie Peeringverbindungen zwischen Spokes erstellen oder direkte Konnektivität für die Netzwerkgruppe aktivieren. Am besten ist es, Peering oder direkte Konnektivität mit virtuellen Spoke-Netzwerken, die Teil derselben Umgebung und Workload sind, zu beschränken.

Wenn Sie Virtual Network Manager verwenden, können Sie virtuelle Spoke-Netzwerke manuell zu Netzwerkgruppen hinzufügen oder Netzwerke automatisch auf Grundlage von Bedingungen, die Sie definieren, hinzufügen. Weitere Informationen finden Sie unter Spoke-to-Spoke-Netzwerke.

Das folgende Diagramm veranschaulicht die Verwendung von Virtual Network Manager für die direkte Konnektivität zwischen Spokes.

Diagramm, das die Verwendung von Virtual Network Manager für die direkte Konnektivität zwischen Spokes veranschaulicht.

Verwaltungsempfehlungen

Um Konnektivität und Sicherheitskontrollen zentral zu verwalten, verwenden Sie Virtual Network Manager, um neue Hub-and-Spoke-Topologien für virtuelle Netzwerke zu erstellen oder um ein Onboarding vorhandener Topologien durchzuführen. Die Verwendung von Virtual Network Manager stellt sicher, dass Ihre Hub-and-Spoke-Netzwerktopologien für ein großes zukünftiges Wachstum in mehreren Abonnements, Verwaltungsgruppen und Regionen vorbereitet sind.

Anwendungsfall-Beispielszenarien für Virtual Network Manager umfassen:

  • Demokratisierung der Verwaltung virtueller Spoke-Netzwerke in Gruppen wie Geschäftseinheiten oder Anwendungsteams. Demokratisierung kann zu einer großen Anzahl von Anforderungen an die Konnektivität zwischen virtuellen Netzwerken sowie an Netzwerksicherheitsregeln führen.
  • Standardisierung mehrerer Replikatarchitekturen in mehreren Azure-Regionen, um einen globalen Speicherbedarf für Anwendungen zu gewährleisten.

Für einheitliche Konnektivität und Netzwerksicherheitsregeln können Sie Netzwerkgruppen verwenden, um virtuelle Netzwerke in beliebigen Abonnements, Verwaltungsgruppen oder Regionen unter demselben Microsoft Entra-Mandanten zu gruppieren. Sie können ein Onboarding virtueller Netzwerke in Netzwerkgruppen automatisch oder manuell durchführen, indem Sie dynamische oder statische Mitgliedschaftszuweisungen vornehmen.

Sie definieren die Auffindbarkeit der virtuellen Netzwerke, die von Virtual Network Manager verwaltet werden, indem Sie Bereiche verwenden. Dieses Feature bietet Flexibilität für eine gewünschte Anzahl von Network Manager-Instanzen, was eine noch weitergehende Demokratisierung der Verwaltung für virtuelle Netzwerkgruppen ermöglicht.

Um virtuelle Spoke-Netzwerke in derselben Netzwerkgruppe untereinander zu verbinden, verwenden Sie Virtual Network Manager, um Peering virtueller Netzwerke oder direkte Konnektivität zu implementieren. Verwenden Sie die Option global mesh (Globales Peermesh), um die direkte Peermesh-Konnektivität auf Spoke-Netzwerke in unterschiedlichen Regionen zu erweitern. Das folgende Diagramm zeigt die globale Peermesh-Konnektivität zwischen Regionen.

Diagramm, das die regionsübergreifende direkte Konnektivität des globalen Spoke-Peermesh zeigt.

Sie können virtuelle Netzwerke innerhalb einer Netzwerkgruppe einem Baselinesatz von Sicherheitsverwaltungsregeln zuordnen. Sicherheitsverwaltungsregeln für Netzwerkgruppen verhindern, dass Besitzer virtueller Spoke-Netzwerke Baselinesicherheitsregeln überschreiben, während sie gleichzeitig ihre eigenen Sicherheitsregelsätze und Netzwerksicherheitsgruppen unabhängig hinzufügen können. Ein Beispiel für die Verwendung von Sicherheitsverwaltungsregeln in Hub-and-Spoke-Topologien finden Sie unter Tutorial: Erstellen eines geschützten Hub-and-Spoke-Netzwerks.

Um einen kontrollierten Rollout von Netzwerkgruppen, Konnektivität und Sicherheitsregeln zu ermöglichen, können Sie mit Konfigurationsbereitstellungen von Virtual Network Manager potenzielle Breaking Changes an Konfigurationen in Hub-and-Spoke-Umgebungen sicher freigeben. Erfahren Sie mehr über Konfigurationsbereitstellungen in Azure Virtual Network Manager.

Informationen zu den ersten Schritten mit Virtual Network Manager finden Sie unter Erstellen einer Hub-and-Spoke-Topologie mit Azure Virtual Network Manager.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Um einen Baselinesatz von Sicherheitsregeln sicherzustellen, stellen Sie sicher, dass Sie Sicherheitsverwaltungsregeln virtuellen Netzwerken in Netzwerkgruppen zuordnen. Sicherheitsverwaltungsregeln haben Vorrang vor Netzwerksicherheitsgruppen-Regeln, weshalb sie vor diesen ausgewertet werden. Wie Netzwerksicherheitsgruppen-Regeln unterstützen Sicherheitsverwaltungsregeln Priorisierung, Diensttags und L3-L4-Protokolle. Weitere Informationen finden Sie unter Sicherheitsverwaltungsregeln in Virtual Network Manager.

Verwenden Sie Virtual Network Manager-Bereitstellungen, um den kontrollierten Rollout potenzieller Breaking Changes in Netzwerkgruppensicherheits-Regeln zu ermöglichen.

Azure DDoS Protection, kombiniert mit bewährten Methoden für den Anwendungsentwurf, bietet erweiterte Features zur DDoS-Risikominderung, um besser vor DDoS-Angriffen zu schützen. Sie sollten Azure DDOS Protection in allen virtuellen Umkreisnetzwerken aktivieren.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Berücksichtigen Sie die folgenden kostenbezogenen Faktoren, wenn Sie Hub-and-Spoke-Netzwerke bereitstellen und verwalten. Weitere Informationen finden Sie unter Virtual Network – Preise.

Kosten von Azure Firewall

Diese Architektur stellt eine Azure Firewall-Instanz im Hubnetzwerk bereit. Die Verwendung einer Azure Firewall-Bereitstellung als gemeinsam genutzte Lösung, die von mehreren Workloads genutzt wird, kann im Vergleich zu anderen NVAs erheblich Cloudkosten sparen. Weitere Informationen finden Sie unter Azure Firewall im Vergleich zu virtuellen Netzwerkgeräten.

Um alle bereitgestellten Ressourcen effektiv zu nutzen, wählen Sie die richtige Azure Firewall-Größe aus. Entscheiden Sie, welche Features Sie benötigen und welche Dienstebene Ihren aktuellen Workloads am besten entspricht. Informationen zu den verfügbaren Azure Firewall-SKUs finden Sie unter Was ist Azure Firewall?.

Kosten privater IP-Adressen

Sie können private IP-Adressen verwenden, um Datenverkehr zwischen virtuellen Netzwerken mit Peering oder zwischen Netzwerken in verbundenen Gruppen weiterzuleiten. Es gelten die folgenden Kostenüberlegungen:

  • Eingehender und ausgehender Datenverkehr wird an beiden Enden der Netzwerke mit Peering oder der verbundenen Netzwerke in Rechnung gestellt. Bei einer Datenübertragung aus einem virtuellen Netzwerk in Zone 1 in ein anderes virtuelles Netzwerk in Zone 2 fällt beispielsweise für Zone 1 die Gebühr für die ausgehende Übertragung und für Zone 2 die Gebühr für die eingehende Übertragung an.
  • Unterschiedliche Zonen verfügen über unterschiedliche Übertragungsraten.

Planen Sie die IP-Adressierung auf Grundlage Ihrer Peeringanforderungen, und stellen Sie sicher, dass sich die Adressräume zwischen standortübergreifenden Orten und Azure-Standorten nicht überlappen.

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

Verwenden Sie Azure Network Watcher, um Netzwerkkomponenten mit den folgenden Tools zu überwachen und Probleme zu behandeln:

  • Traffic Analytics zeigt Ihnen die Systeme in Ihren virtuellen Netzwerken, die den meisten Traffic generieren. Sie können Engpässe visuell identifizieren, bevor sie zu Problemen werden.
  • Der Netzwerkleistungsmonitor überwacht Informationen zu ExpressRoute-Leitungen.
  • Die VPN-Diagnose unterstützt Sie bei der Problembehandlung von Site-to-Site-VPN-Verbindungen, die Ihre Anwendungen mit lokalen Benutzern verbinden.

Sie sollten auch erwägen, die Azure Firewall-Diagnoseprotokollierung zu aktivieren, um bessere Erkenntnisse hinsichtlich der DNS-Anforderungen sowie der Zulassen/Ablehnen-Ergebnisse (allow/deny) in den Protokollen zu erhalten.

Bereitstellen dieses Szenarios

Diese Bereitstellung umfasst ein virtuelles Hubnetzwerk und zwei verbundene Spokes. Ferner stellt sie eine Azure Firewall-Instanz und einen Azure Bastion-Host bereit. Optional kann die Bereitstellung auch virtuelle Computer im ersten Spoke-Netzwerk sowie ein VPN Gateway umfassen.

Sie können zwischen dem Peering virtueller Netzwerke oder verbundenen Virtual Network Manager-Gruppen wählen, um die Netzwerkverbindungen zu erstellen. Jede Methode bietet mehrere Bereitstellungsoptionen.

Verwenden des Peerings virtueller Netzwerke

  1. Führen Sie den folgenden Befehl aus, um eine Ressourcengruppe namens hub-spoke in der Region eastus für die Bereitstellung zu erstellen. Wählen Sie Ausprobieren aus, um eine eingebettete Shell zu verwenden.

    az group create --name hub-spoke --location eastus

  2. Führen Sie den folgenden Befehl aus, um die Bicep-Vorlage herunterzuladen.

    curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke/bicep/main.bicep > main.bicep

  3. Führen Sie den folgenden Befehl aus, um die Hub-and-Spoke-Netzwerkkonfiguration, Peerings virtueller Netzwerke zwischen dem Hub und den Spokes sowie einen Azure Bastion-Host bereitzustellen. Geben Sie nach entsprechender Aufforderung einen Benutzernamen und das Kennwort ein. Sie können diesen Benutzernamen mit Kennwort verwenden, um auf VMs in den Spoke-Netzwerken zuzugreifen.

    az deployment group create --resource-group hub-spoke --template-file main.bicep

Ausführliche Informationen und zusätzliche Bereitstellungsoptionen finden Sie in den Hub-and-Spoke-ARM- und Bicep-Vorlagen, die diese Lösung bereitstellen.

Verwenden verbundener Virtual Network Manager-Gruppen

  1. Führen Sie den folgenden Befehl aus, um eine Ressourcengruppe für die Bereitstellung zu erstellen. Wählen Sie Ausprobieren aus, um eine eingebettete Shell zu verwenden.

    az group create --name hub-spoke --location eastus

  2. Führen Sie den folgenden Befehl aus, um die Bicep-Vorlage herunterzuladen.

    curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/main.bicep > main.bicep

  3. Führen Sie die folgenden Befehle aus, um alle benötigten Module in ein neues Verzeichnis herunterzuladen.

    mkdir modules

curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/avnm.bicep > modules/avnm.bicep
curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/avnmDeploymentScript.bicep > modules/avnmDeploymentScript.bicep
curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/hub.bicep > modules/hub.bicep
curl https://raw.githubusercontent.com/mspnp/samples/main/solutions/azure-hub-spoke-connected-group/bicep/modules/spoke.bicep > modules/spoke.bicep

  4. Führen Sie den folgenden Befehl aus, um die Hub-and-Spoke-Netzwerkkonfiguration, virtuellen Netzwerkverbindungen zwischen dem Hub und den Spokes sowie einen Bastion-Host bereitzustellen. Geben Sie nach entsprechender Aufforderung einen Benutzernamen und das Kennwort ein. Sie können diesen Benutzernamen mit Kennwort verwenden, um auf VMs in den Spoke-Netzwerken zuzugreifen.

    az deployment group create --resource-group hub-spoke --template-file main.bicep

Ausführliche Informationen und zusätzliche Bereitstellungsoptionen finden Sie in den Hub-and-Spoke-ARM- und Bicep-Vorlagen, die diese Lösung bereitstellen.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Alejandra Palacios | Senior Customer Engineer

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Erkunden Sie die folgenden verwandten Architekturen: