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. Informationen dazu, warum diese Topologie als bewährte Methode für viele Organisationen angesehen wird, finden Sie unter "Definieren einer Azure-Netzwerktopologie ".

Architecture

Diagramm, das eine Hub-Speichen-Virtual Network-Topologie in Azure zeigt, in der Speichennetzwerke über den Hub oder direkt verbunden sind.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Hub-spoke concepts

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

  • Virtuelles Hubnetzwerk – Das virtuelle Hubnetzwerk hostt gemeinsam genutzte 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:

    • Cross-premise gateway - Cross-premise connectivity is the ability to connect and integrate different network environments to one another. Dieses Gateway ist in der Regel ein VPN oder ein ExpressRoute-Schaltkreis.

    • Egress control - The management and regulation of outbound traffic that originates in the peered spoke virtual networks.

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

    • Remote access - Remote access is how individual workloads in spoke networks are accessed from network location other than the spoke's own network. 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 - Manages and directs traffic between the hub and the connected spokes to enable secure and efficient communication.

  • Virtuelle Speichennetzwerke – Speichen-virtuelle Netzwerke 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 den 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 cross-connectivity – 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 solutions are often responsible for providing a DNS solution to be used by all peered spokes, especially for cross-premises routing and for private endpoint DNS records.

Components

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

    This architecture connects virtual networks to the hub by using peering connections which are non-transitive, low-latency connections between virtual networks. 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 is a fully managed service that provides more secure and seamless Remote Desktop Protocol (RDP) and Secure Shell Protocol (SSH) access to VMs without exposing their public IP addresses. In dieser Architektur wird Azure Bastion als verwaltetes Angebot verwendet, um direkten VM-Zugriff über verbundene Speichen zu unterstützen.

  • Azure Firewall is a managed cloud-based network security service that protects Virtual Network resources. 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 is a specific type of virtual network gateway that sends encrypted traffic between a virtual network on Azure and different network over the public internet. 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.

  • Das Azure ExpressRoute-Gateway austauscht IP-Routen und leitet den Netzwerkdatenverkehr zwischen Ihrem lokalen Netzwerk und Ihrem virtuellen Azure-Netzwerk weiter. In dieser Architektur wäre ExpressRoute die alternative Option zu einem VPN-Gateway, 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 can collect, analyze, and act on telemetry data from cross-premises environments, including Azure and on-premises. 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.

Alternatives

Diese Architektur umfasst die Erstellung, Konfiguration und Wartung mehrerer Azure-Ressourcengrundtypen, nämlich: virtualNetworkPeerings, routeTablesund subnets. Azure Virtual Network Manager ist ein Verwaltungsdienst, der Sie beim Gruppieren, Konfigurieren, Bereitstellen und Verwalten virtueller Netzwerke über Azure-Abonnements, Regionen und Microsoft Entra-Verzeichnisse hinweg unterstützt. With Virtual Network Manager, you can define network groups to identify and logically segment your virtual networks. You can use connected groups that allow virtual networks within a group to communicate with each other as if they were manually connected. 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 Manager ein Nettovorteil für die Größe und Komplexität Ihres Netzwerks ist.

Scenario details

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:

  • Cost savings
  • Überwinden von Abonnementgrenzen
  • Workload isolation
  • Flexibility
    • 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.

Recommendations

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. Siehe Erstellen eines virtuellen Netzwerk-Peerings – Ressourcen-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 einem Adressbereich von mindestens 26. 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

Create a subnet named AzureFirewallSubnet with an address range of at least /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. For more information, see Networking limits and Connected groups limits.

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 forced tunneling.

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 Hub-NVA-Eingangsrouting finden Sie unter Firewall und Anwendungsgateway 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.

To use virtual network peerings, in the virtual network Peering setup:

  • Configure the peering connection in the hub to Allow gateway transit.
  • Konfigurieren Sie die Peeringverbindung in den einzelnen Speichen, um das Gateway des virtuellen Remotenetzwerks zu verwenden.
  • Configure all peering connections to Allow forwarded traffic.

Weitere Informationen finden Sie unter Erstellen eines virtuellen Netzwerk-Peerings.

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 Speichennetzwerkgruppen"Hub" als Gateway aus.

Weitere Informationen finden Sie unter Erstellen einer Hub- und Speichentopologie 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.

For more information on spoke-to-spoke networking patterns, see Spoke-to-spoke networking.

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, das das Routing zwischen Speichen mithilfe der 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. Konfigurationsdetails finden Sie unter Konfigurieren der VPN-Gatewaydurchleitung für virtuelle Netzwerkpeering.

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 Verbindung zwischen Speichen zeigt.

Considerations

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.

Reliability

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.

Use Availability zones for Azure services in the hub that support them.

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

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.

Security

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

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 Basissatz von Sicherheitsregeln sicherzustellen, müssen Sie Sicherheitsadministratorregeln 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 "Sicherheitsadministratorregeln" in Virtual Network Manager.

Use Virtual Network Manager deployments to facilitate controlled rollout of potentially breaking changes to network group security rules.

Cost Optimization

Die Kostenoptimierung geht es um Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie in der Prüfliste für die Entwurfsüberprüfung für die Kostenoptimierung.

Berücksichtigen Sie die folgenden kostenbezogenen Faktoren, wenn Sie Hub-and-Spoke-Netzwerke bereitstellen und verwalten. Weitere Informationen finden Sie unter "Preise für virtuelle Netzwerke".

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 vs. Netzwerk virtual appliances.

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?

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

Operational Excellence

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

Aktivieren Sie Diagnoseeinstellungen für alle Dienste, z. B. Azure Bastion, Azure Firewall und Ihr standortübergreifendes 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.

Use Connection monitor for end-to-end monitoring to detect anomalies and to identify and troubleshoot network issues.

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

Wenn Sie ExpressRoute verwenden, verwenden Sie ExpressRoute Traffic Collector , wo 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 basierend auf Ihren Peeringanforderungen, und stellen Sie sicher, dass sich der Adressraum nicht überlappend über standortübergreifende Standorte und Azure-Standorte hinweg.

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-Virtuelle Netzwerktopologien 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.

To ensure uniform connectivity and network security rules, you can use network groups to group virtual networks in any subscription, management group, or region under the same Microsoft Entra tenant. Sie können ein Onboarding virtueller Netzwerke in Netzwerkgruppen automatisch oder manuell durchführen, indem Sie dynamische oder statische Mitgliedschaftszuweisungen vornehmen.

You define discoverability of the virtual networks that Virtual Network Manager manages by using Scopes. 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.

To connect spoke virtual networks in the same network group to each other, use Virtual Network Manager to implement virtual network peering or direct connectivity. Use the global mesh option to extend mesh direct connectivity to spoke networks in different regions. Das folgende Diagramm zeigt die globale Peermesh-Konnektivität zwischen Regionen.

Diagramm, das die direkte Verbindung mit speichen-Gittern über Regionen 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 Sicherheitsadministratorregeln in Hub- und Speichentopologien finden Sie im Lernprogramm: Erstellen eines gesicherten Hub- und Speichennetzwerks.

To facilitate a controlled rollout of network groups, connectivity, and security rules, Virtual Network Manager configuration deployments help you safely release potentially breaking configuration changes to hub and spoke environments. Weitere Informationen finden Sie unter Konfigurationsbereitstellungen in Azure Virtual Network Manager.

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

Um die Verwaltung von IP-Adressen zu vereinfachen und zu zentralisieren, können Sie die IP-Adressverwaltung (IPAM) in Azure Virtual Network Manager verwenden. 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- und Speichentopologie mit Azure Virtual Network Manager.

Performance Efficiency

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

For workloads that communicate from on-premises to virtual machines in an Azure virtual network that require low latency and high bandwidth, consider using ExpressRoute FastPath. 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.

For spoke-to-spoke communications that require low-latency, consider configuring spoke-to-spoke networking.

Choose the appropriate gateway SKU that meet your requirements, such as number of point-to-site or site-to-site connections, required packets-per-second, bandwidth requirements, and TCP flows.

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 die von der Azure Firewall eingeführte Latenz testen , um Ihre Entscheidung zu informieren. You can use features such as VNet peering that connects two or more networks or Azure Private Link that enables you to connect to a service over a private endpoint in your virtual network.

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

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.

Contributors

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

Principal authors:

Other contributors:

Um nicht öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Next steps

Advanced scenarios

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: