Bearbeiten

Freigeben über

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.

Hub-Spoke ist eine der vom Cloud Adoption Framework empfohlenen Netzwerktopologien. Lesen Sie Definieren einer Azure-Netzwerktopologie, um zu verstehen, warum diese Topologie als bewährte Methode für viele Organisationen angesehen wird.

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.

Hub-Spoke-Konzepte

Hub-Spoke-Netzwerktopologien umfassen in der Regel die vielen der folgenden Architekturkonzepte:

  • virtuellen Hubnetzwerk – Das virtuelle Hubnetzwerk hostt gemeinsame 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. Der Hub enthält Ihren primären Ausgangspunkt und bietet einen Mechanismus zum Verbinden eines Gesprochenen mit einem anderen in Situationen, in denen der virtuelle Netzwerkdatenverkehr erforderlich ist.

    Ein Hub ist eine regionale Ressource. Organisationen, die ihre Workloads in mehreren Regionen haben, sollten über mehrere Hubs verfügen, eine pro Region.

    Der Hub ermöglicht die folgenden Konzepte:

    • standortübergreifende Gateway- – Standortübergreifende Konnektivität ist die Möglichkeit, verschiedene Netzwerkumgebungen miteinander zu verbinden und zu integrieren. Dieses Gateway ist in der Regel ein VPN oder ein ExpressRoute-Schaltkreis.

    • Ausgangskontrolle – Verwaltung und Regulierung von ausgehenden Datenverkehr, der aus virtuellen Peered-Netzwerken stammt.

    • (optional) Ingress-Steuerung – Verwaltung und Regulierung eingehender Datenverkehr zu Endpunkten, die in virtuellen Peered-Netzwerken vorhanden sind.

    • Remotezugriff – Der Remotezugriff ist, wie auf einzelne Arbeitslasten in Speichennetzwerken von einem anderen Netzwerkstandort als dem eigenen Netzwerk des Speichens zugegriffen wird. Dies könnte für die Daten- oder Kontrollebene der Workload sein.

    • Remote-Speichenzugriff für virtuelle Computer – Der Hub kann ein praktischer Ort sein, um eine organisationsübergreifende Remoteverbindungslösung für RDP- und SSH-Zugriff auf virtuelle Computer zu erstellen, die über speichennetzwerke verteilt werden.

    • Routing- – Verwaltet und leitet datenverkehr zwischen dem Hub und den verbundenen Speichen, um eine sichere und effiziente Kommunikation zu ermöglichen.

  • virtuelle Speichennetzwerke – Virtuelle Speichennetzwerke isolieren und verwalten Workloads separat in den einzelnen Speichen. Jede Workload kann mehrere Schichten umfassen, wobei mehrere Subnetze über Azure Load Balancer-Instanzen verbunden sind. Speichen können in verschiedenen Abonnements vorhanden sein und unterschiedliche Umgebungen darstellen, z. B. Produktion und Nichtproduktion. Eine Arbeitsauslastung könnte sogar über mehrere Speichen verteilt werden.

    In den meisten Szenarien sollte eine Speichen nur mit einem einzelnen Hubnetzwerk peered werden, und dieses Hubnetzwerk sollte sich in derselben Region wie der Speichen befinden.

    Diese Speichennetzwerke folgen den Regeln für standardmäßigen ausgehenden Zugriff. Ein Kernzweck dieser Hub-Spoke-Netzwerktopologie ist es, ausgehenden Internetdatenverkehr in der Regel über die vom Hub angebotenen Kontrollmechanismen zu leiten.

  • virtuelles Netzwerk querkonnektivität – Virtuelle Netzwerkkonnektivität ist der Pfad, in dem ein isoliertes virtuelles Netzwerk über einen Kontrollmechanismus mit einem anderen kommunizieren kann. Der Kontrollmechanismus erzwingt Berechtigungen und die zulässige Kommunikationsrichtung zwischen Netzwerken. Ein Hub bietet eine Option, um die Auswahl von netzwerkübergreifenden Verbindungen zu unterstützen, die über das zentrale Netzwerk fließen sollen.

  • DNS- - Hub-Spoke-Lösungen sind häufig dafür verantwortlich, eine DNS-Lösung bereitzustellen, die von allen peered Spokes verwendet werden soll, insbesondere für das standortübergreifende Routing und für private Endpunkt-DNS-Einträge.

Komponenten

  • 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.

    Diese Architektur verbindet virtuelle Netzwerke mit dem Hub, indem Peeringverbindungen verwendet werden, die nicht transitive Verbindungen mit niedriger Latenz zwischen virtuellen Netzwerken sind. Peered virtual networks can exchange traffic over the Azure backbone without needing a router. In einer Hub-Spoke-Architektur ist das direkte Peering virtueller Netzwerke miteinander minimal und für Spezielle Fallszenarien reserviert.

  • 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. In dieser Architektur wird Azure Bastion als verwaltetes Angebot verwendet, um direkten VM-Zugriff über verbundene Speichen zu unterstützen.

  • 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.

    In dieser Architektur verfügt azure Firewall über mehrere potenzielle Rollen. Die Firewall ist der primäre Ausgangspunkt für internetspezifischen Datenverkehr aus den virtuellen Peered-Netzwerken. Die Firewall kann auch verwendet werden, um eingehenden Datenverkehr mithilfe von IDPS-Regeln zu prüfen. Und schließlich kann die Firewall auch als DNS-Proxyserver verwendet werden, um FQDN-Datenverkehrsregeln zu unterstützen.

  • VPN-Gateway- ist ein bestimmter Typ von virtuellem Netzwerkgateway, der verschlüsselten Datenverkehr zwischen einem virtuellen Netzwerk in Azure und einem anderen Netzwerk über das öffentliche Internet sendet. Sie können auch das VPN-Gateway verwenden, um verschlüsselten Datenverkehr zwischen anderen virtuellen Hubnetzwerken über das Microsoft-Netzwerk zu senden.

    In dieser Architektur wäre dies eine Möglichkeit, einige oder alle Speichen mit dem Remotenetzwerk zu verbinden. Speichen würden in der Regel kein eigenes VPN-Gateway bereitstellen und stattdessen die vom Hub angebotene zentrale Lösung verwenden. Sie müssen die Routingkonfiguration einrichten, um diese Konnektivität zu verwalten.

  • Azure ExpressRoute-Gateway austauscht IP-Routen und leitet den Netzwerkdatenverkehr zwischen Ihrem lokalen Netzwerk und Ihrem virtuellen Azure-Netzwerk weiter. In dieser Architektur würde ExpressRoute eine alternative Option zu einem VPN-Gateway verwenden, um einige oder alle Speichen mit einem Remotenetzwerk zu verbinden. Speichen würden ihre eigene ExpressRoute nicht bereitstellen, und stattdessen würden diese Speichen die zentrale Lösung verwenden, die vom Hub angeboten wird. Wie bei einem VPN-Gateway müssen Sie die Routingkonfiguration einrichten, um diese Konnektivität zu verwalten.

  • 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. In dieser Architektur ist Azure Monitor die Protokoll- und Metriksenke für die Hubressourcen und für Netzwerkmetriken. Azure Monitor kann auch als Protokollierungssenke für Ressourcen in Speichennetzwerken verwendet werden, aber das ist eine Entscheidung für die verschiedenen verbundenen Workloads und wird von dieser Architektur nicht vorgeschrieben.

Alternativen

Diese Architektur umfasst die Erstellung, Konfiguration und Wartung mehrerer Azure-Ressourcengrundtypen, nämlich: virtualNetworkPeerings, routeTablesund subnets. Azure Virtual Network Manager ist ein Verwaltungsdienst, der Ihnen hilft, virtuelle Netzwerke über Azure-Abonnements, Regionen und Microsoft Entra-Verzeichnisse zu gruppieren, zu konfigurieren, bereitzustellen und zu verwalten. Mit Virtual Network Manager können Sie Netzwerkgruppen definieren, um Ihre virtuellen Netzwerke zu identifizieren und logisch zu segmentieren. Sie können verbundenen Gruppen verwenden, mit denen virtuelle Netzwerke innerhalb einer Gruppe miteinander kommunizieren können, als wären sie manuell verbunden. Diese Ebene fügt eine Abstraktionsebene über diese Grundtypen hinzu, um sich auf die Beschreibung der Netzwerktopologie im Vergleich zur Implementierung dieser Topologie zu konzentrieren.

Es wird empfohlen, die Verwendung von Virtual Network Manager als Möglichkeit zu bewerten, um Ihre Zeitausgaben mit Netzwerkverwaltungsvorgängen zu optimieren. Bewerten Sie die Kosten des Diensts anhand Ihres berechneten Werts/Ihrer Einsparungen, um festzustellen, ob Virtual Network Manger ein Nettovorteil für die Größe und Komplexität Ihres Netzwerks ist.

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.

Zu den Vorteilen der Verwendung eines vom Kunden verwalteten Hubs und einer Speichenkonfiguration gehören:

  • Kostenersparnis
  • Überwinden von Abonnementgrenzen
  • Workloadisolation
  • Flexibilität
    • Mehr Kontrolle darüber, wie virtuelle Netzwerkgeräte (NVAs) bereitgestellt werden, z. B. Anzahl der NICs, Anzahl von Instanzen oder die Computegröße.
    • Verwendung von NVAs, die von virtual WAN nicht unterstützt werden

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.

Azure-Landungszonen

Die Azure-Zielzonenarchitektur basiert auf der Hub-Spoke-Topologie. In dieser Architektur wird die gemeinsam genutzten Ressourcen und das Netzwerk des Hubs von einem zentralen Plattformteam verwaltet, während Die Sprecher ein Mitbesitzmodell mit dem Plattformteam und dem Workload-Team teilen, das das Speichennetzwerk verwendet. Alle Hubs befinden sich in einem "Konnektivitätsabonnement" für die zentrale Verwaltung, während virtuelle Speichennetzwerke über viele einzelne Workload-Abonnements hinweg vorhanden sind, die als Anwendungszielzonenabonnements bezeichnet werden.

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 mindestens 26Adressbereich. Der adressbereich /26 bietet dem Subnetz genügend Skalierbarkeitskonfigurationsoptionen, um zu verhindern, dass die Größenbeschränkungen des Gateways in Zukunft erreicht werden und eine höhere Anzahl von ExpressRoute-Schaltkreisen berücksichtigt werden kann. Weitere Informationen zum Einrichten des Gateways finden Sie unter Hybridnetzwerk mit einem VPN-Gateway.

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.
  • Private Verknüpfung kann verwendet werden, um einzelne Ressourcen selektiv anderen virtuellen Netzwerken zur Verfügung zu stellen. Wenn Sie beispielsweise ein internes Lastenausgleichsmodul für ein anderes virtuelles Netzwerk verfügbar machen, ohne Peering- oder Routingbeziehungen zu erstellen oder aufrechtzuerhalten.

Weitere Informationen zu Speichennetzwerkmustern finden Sie unter Spoke-to-Spoke-Netzwerk.

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.

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.

Ü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.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie an Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Übersicht über die Zuverlässigkeitssäule.

Verwenden Sie Verfügbarkeitszonen für Azure-Dienste im Hub, die diese unterstützen.

Im Allgemeinen empfiehlt es sich, mindestens einen Hub pro Region zu haben und nur Speichen mit diesen Hubs aus derselben Region zu verbinden. Diese Konfiguration hilft Regionen im Bulkhead, um einen Fehler im Hub einer Region zu vermeiden, was zu weit verbreiteten Netzwerkroutingfehlern in nicht verwandten Regionen führt.

Um eine höhere Verfügbarkeit zu erzielen, können Sie ExpressRoute mit einem VPN für Failoverzwecke kombinieren. Siehe Verbinden eines lokalen Netzwerks mit Azure mithilfe von ExpressRoute mit VPN-Failover- und befolgen Sie die Anleitungen zum Entwerfen und Entwerfen von Azure ExpressRoute zur Resilienz.

Stellen Sie aufgrund der Implementierung von FQDN-Anwendungsregeln durch Azure Firewall sicher, dass alle Ressourcen, die über die Firewall gehen, denselben DNS-Anbieter wie die Firewall selbst verwenden. Ohne diesen Fall blockiert Azure Firewall möglicherweise legitimen Datenverkehr, da die IP-Auflösung des FQDN der Firewall von der IP-Auflösung des Datenverkehrsgebers desselben FQDN unterscheidet. Das Integrieren von Azure Firewall-Proxy als Teil der speichen-DNS-Auflösung ist eine Lösung, um sicherzustellen, dass FQDNs sowohl mit dem Datenverkehrshersteller als auch mit der Azure-Firewall synchronisiert werden.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für sicherheitsrelevante.

Um vor DDoS-Angriffen zu schützen, aktivieren Sie Azure DDOS Protection in jedem virtuellen Umkreisnetzwerk. Jede Ressource mit einer öffentlichen IP ist anfällig für einen DDoS-Angriff. Auch wenn Ihre Workloads nicht öffentlich verfügbar gemacht werden, verfügen Sie immer noch über öffentliche IPs, die geschützt werden müssen, z. B.:

  • Öffentliche IPs der Azure Firewall
  • Öffentliche IP-Adressen des VPN-Gateways
  • Öffentliche IP-Adresse der ExpressRoute-Steuerungsebene

Um das Risiko eines nicht autorisierten Zugriffs zu minimieren und strenge Sicherheitsrichtlinien durchzusetzen, legen Sie in Netzwerksicherheitsgruppen (NSGs) immer explizite Verweigerungsregeln fest.

Verwenden Sie die Azure Firewall Premium--Version, um TLS-Inspektion, Netzwerkangriffserkennung und -präventionssystem (IDPS) und URL-Filterung zu aktivieren.

Sicherheit von Virtual Network Manager

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.

Kostenoptimierung

Die Kostenoptimierung geht es um Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Prüfliste für die Überprüfung der 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?.

Direktes Peering

Die selektive Verwendung direkter Peerings oder einer anderen nicht hubgesteuerten Kommunikation zwischen Speichen kann die Kosten der Azure Firewall-Verarbeitung vermeiden. Einsparungen können für Netzwerke mit Arbeitslasten mit hohem Durchsatz, geringer Risikokommunikation zwischen Speichen, z. B. Datenbanksynchronisierung oder großen Dateikopievorgängen, erheblich sein.

Operative Exzellenz

Operational Excellence deckt die Betriebsprozesse ab, mit denen eine Anwendung bereitgestellt und in der Produktion ausgeführt wird. Weitere Informationen finden Sie unter Prüfliste für die Überprüfung von Operational Excellence.

Aktivieren Sie Diagnoseeinstellungen für alle Dienste, z. B. Azure Bastion, Azure Firewall und Ihr vorkonfiguriertes Gateway. Bestimmen Sie, welche Einstellungen für Ihre Vorgänge aussagekräftig sind. Deaktivieren Sie Einstellungen, die nicht sinnvoll sind, um unnötige Kosten zu vermeiden. Ressourcen wie Azure Firewall können ausführlich mit der Protokollierung verwendet werden, und Sie können hohe Überwachungskosten verursachen.

Verwenden Sie Verbindungsüberwachung für die End-to-End-Überwachung, um Anomalien zu erkennen und Netzwerkprobleme zu identifizieren und zu beheben.

Verwenden Sie Azure Network Watcher-, um Netzwerkkomponenten zu überwachen und zu beheben, einschließlich der Verwendung Traffic Analytics-, um Ihnen die Systeme in Ihren virtuellen Netzwerken anzuzeigen, die den größten Datenverkehr generieren. Sie können Engpässe visuell identifizieren, bevor sie zu Problemen werden.

Wenn Sie ExpressRoute verwenden, verwenden Sie ExpressRoute Traffic Collector, in dem Sie Ablaufprotokolle für die Netzwerkflüsse analysieren können, die über Ihre ExpressRoute-Schaltkreise gesendet werden. ExpressRoute-Datenverkehrssammler bietet Ihnen Einblicke in den Datenverkehr, der über Microsoft Enterprise Edge-Router fließt.

Verwenden Sie FQDN-basierte Regeln in azure Firewall für andere Protokolle als HTTP(n) oder beim Konfigurieren von SQL Server. Die Verwendung von FQDNs senkt den Verwaltungsaufwand für die Verwaltung einzelner IP-Adressen.

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.

Automatisierung mit Azure Virtual Network Manager

Um Konnektivitäts- und Sicherheitskontrollen zentral zu verwalten, verwenden Sie Azure Virtual Network Manager, um neue Hub- und Speichen-Virtual Network-Topologien zu erstellen oder vorhandene Topologien zu integrieren. 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.

Um das Erstellen und Verwalten von Routenkonfigurationen zu vereinfachen und zu optimieren, können Sie automatisierte Verwaltung von benutzerdefinierten Routen (UDRs) in Azure Virtual Network Managerverwenden.

Um die Verwaltung von IP-Adressen zu vereinfachen und zu zentralisieren, können Sie IP-Adressverwaltung (IPAM) in Azure Virtual Network Managerverwenden. IPAM verhindert IP-Adressraumkonflikte in lokalen und cloudbasierten virtuellen Netzwerken.

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

Leistungseffizienz

Die Leistungseffizienz ist die Fähigkeit Ihrer Arbeitsauslastung, um die Anforderungen der Benutzer effizient zu erfüllen. Weitere Informationen finden Sie Übersicht über die Säule "Leistungseffizienz".

Für Workloads, die von lokalen zu virtuellen Computern in einem virtuellen Azure-Netzwerk kommunizieren, die niedrige Latenz und hohe Bandbreite erfordern, sollten Sie ExpressRoute FastPath-verwenden. FastPath ermöglicht es Ihnen, Datenverkehr direkt an virtuelle Computer in Ihrem virtuellen Netzwerk von der lokalen Bereitstellung aus zu senden, um das virtuelle ExpressRoute-Netzwerkgateway zu umgehen und die Leistung zu erhöhen.

Für Die Sprach-zu-Speichen-Kommunikation, die geringe Latenz erfordert, sollten Sie Speichennetzwerkkonfigurieren.

Wählen Sie die entsprechende Gateway-SKU- aus, die Ihren Anforderungen entsprechen, z. B. Anzahl der Point-to-Site- oder Standort-zu-Standort-Verbindungen, erforderliche Pakete pro Sekunde, Bandbreitenanforderungen und TCP-Flüsse.

Bei Latenzsensiblen Flüssen, z. B. SAP oder Zugriff auf Speicher, erwägen Sie die Umgehung der Azure Firewall oder sogar das Routing über den Hub überhaupt. Sie können von Azure Firewall eingeführte Latenz testen, um Ihre Entscheidung zu informieren. Sie können Features wie VNet-Peering- verwenden, die zwei oder mehr Netzwerke verbindet, oder Azure Private Link, mit dem Sie eine Verbindung mit einem Dienst über einen privaten Endpunkt in Ihrem virtuellen Netzwerk herstellen können.

Verstehen Sie, dass das Aktivieren bestimmter Features in der Azure-Firewall, z. B. Das System zur Erkennung und Verhinderung von Angriffen (Intrusion Detection and Prevention System, IDPS), Ihren Durchsatz reduziert. Weitere Informationen finden Sie unter Azure Firewall Performance.

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.

Beitragende

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

Hauptautoren:

Andere Mitwirkende:

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

Nächste Schritte

Erweiterte Szenarien

Ihre Architektur unterscheidet sich möglicherweise von dieser einfachen Hub-Spoke-Architektur. Im Folgenden finden Sie eine Liste mit Anleitungen für einige erweiterte Szenarien:

Erkunden Sie die folgenden verwandten Architekturen: