Azure Virtual WAN Netzwerktopologie

In diesem Artikel wird erläutert, wie Sie ein Netzwerk mit Azure Virtual WAN entwerfen. Virtual WAN bietet Microsoft verwaltete Hubinfrastruktur mit automatischem Routing, systemeigener SD-WAN Integration und integrierter globaler Übertragung zwischen Hubs.

Inhalt dieses Artikels

In diesem Artikel werden die Hubarchitektur von Virtual WAN, automatisches Routing und Routenweitergabe, der Vergleich der Tarife Basic und Standard, die Routingabsicht zur Überprüfung des Datenverkehrs, SD-WAN-Integrationsmuster und das Kostenmodell von Virtual WAN behandelt.

Wer diesen Artikel benötigt

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

  • Sie benötigen verwaltete Transit-Konnektivität für viele Niederlassungen, Standorte, Remotebenutzer oder verbundene virtuelle Netzwerke.
  • Sie möchten von Microsoft verwaltetes Routing und Konnektivität für Zweigstellen nutzen, anstatt selbst einen benutzerdefinierten Transit-Hub aufzubauen und zu betreiben.
  • Sie müssen Azure Virtual WAN mit dem Hub-and-Spoke-Modell vergleichen, bevor Sie sich für eine Topologie entscheiden.
  • Sie erwarten, dass Ihr Netzwerk über eine kleine Anzahl manuell verwalteter Konnektivitäts-Edges hinaus wachsen wird.

Tip

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

Lift-and-Shift-Schwerpunkt: Überspringen Sie diesen Artikel, wenn Sie eine Standard-Lift-and-Shift-Migration durchführen. Die meisten Lift-and-Shift-Umgebungen verfügen über weniger als 30 Niederlassungsverbindungen und werden in einer oder zwei Regionen betrieben. Eine herkömmliche Hub-and-Spoke-Topologie mit VPN Gateway bietet ausreichende Konnektivität. Erwägen Sie Virtual WAN nur, wenn Sie viele Zweigstellen haben oder eine schnelle Erweiterung planen.

Modernisierungsschwerpunkt: Dieser Artikel ist relevant, wenn Ihr Modernisierungsprogramm Anforderungen an den Transit im Filialmaßstab oder über viele Regionen hinweg umfasst. Eine duale Hub-Spoke-Architektur mit VPN-Gateways in jeder Region deckt die meisten Modernisierungsszenarien ab. Virtual WAN wird dann relevant, wenn die Routing-Komplexität ein Maß erreicht, das die manuelle UDR-Verwaltung nicht mehr bewältigen kann.

Cloudübergreifender Fokus: Virtual WAN ist das empfohlene Transitmodell, wenn Sie über mehrere virtuelle private Clouds (VPCs), Zweigniederlassungen, Regionen oder Cloud-Edges verfügen. Virtual WAN dient als Azure-Äquivalent zum AWS Transit Gateway, das zentrale Routing- und Konnektivitätsverwaltung im großen Maßstab bereitstellt. Wenn Sie von einer AWS-Umgebung migrieren, die Transit Gateway verwendet, entspricht Virtual WAN diesem Modell direkt.

Azure Dienste und Features

In der folgenden Tabelle sind die Azure Dienste und Features aufgeführt, die eine Virtual WAN Topologie unterstützen:

Dienst oder Feature Rolle in Virtual WAN Weitere Informationen
Azure Virtual WAN Stellt das verwaltete globale Transitnetzwerk und die Hubinfrastruktur bereit. übersicht über Virtual WAN
Virtueller Hub Microsoft verwaltetes virtuelles Netzwerk, das Routing- und Gatewaydienste hostt Routing virtueller Hubs
VPN Gateway (im Hub) Standort-zu-Standort- und Point-to-Site-VPN-Konnektivität für Zweigstellen Virtual WAN VPN Gateway
ExpressRoute-Gateway (im Hub) Private Konnektivität von lokalen Rechenzentren über ExpressRoute-Schaltkreise Virtual WAN: ExpressRoute
Azure Firewall Manager Zentrale Sicherheitsrichtlinienverwaltung für gesicherte virtuelle Hubs Firewall-Manager – Übersicht
Routingabsicht Automatische Verkehrslenkung mithilfe einer Sicherheitslösung ohne benutzerdefinierte Routentabellen Routing-Intent

So funktioniert es

Diagramm einer Virtual-WAN-Topologie mit zwei regionalen Hubs, virtuellen Spoke-Netzwerken, Niederlassungen, die über VPN verbunden sind, und ExpressRoute-Leitungen. Das Inter-Hub-Routing erfolgt über das Microsoft-Backbone.

In einer Virtual WAN Topologie:

  1. Eine Virtual WAN Ressource fungiert als Container auf oberster Ebene, der einen oder mehrere virtuelle Hubs über Regionen hinweg gruppiert.
  2. Jeder virtuelle Hub ist ein Microsoft verwaltetes virtuelles Netzwerk. Der Hub enthält Dienstendpunkte für VPN-, ExpressRoute- und Firewalldienste. Sie stellen das virtuelle Hubnetzwerk nicht direkt bereit oder verwalten es nicht.
  3. Spoke-virtuelle Netzwerke sind über VNet-Verbindungen mit einem virtuellen Hub verbunden (ähnlich wie beim Peering in traditionellen Hub-Spoke-Topologien). Der virtuelle Hubrouter verarbeitet das gesamte Routing automatisch.
  4. Zweigstellen stellen eine Verbindung über Standort-zu-Standort-VPN- oder ExpressRoute-Gateways her, die innerhalb des virtuellen Hubs bereitgestellt werden.
  5. Wenn Sie mehrere Hubs bereitstellen, werden sie automatisch über das Microsoft Backbone verbunden, das den globalen Transit ohne vom Kunden verwaltetes Routing ermöglicht.

Routing virtueller Hubs

Der virtuelle Hubrouter verwaltet das gesamte Routing zwischen verbundenen virtuellen Netzwerken, Verzweigungen und anderen Hubs. Wichtige Verhaltensweisen:

  • Automatische Übertragung: Virtuelle Netzwerke, die mit demselben Hub verbunden sind, können ohne UDRs kommunizieren. Der Hubrouter verteilt Routen standardmäßig zwischen allen Verbindungen.
  • Inter-Hub-Transit: Routen werden automatisch zwischen Hubs in derselben Virtual WAN verteilt. Der Datenverkehr zwischen Regionen fließt über das Microsoft Backbone.
  • Routentabellen: Für erweiterte Isolationsszenarien (z. B. das Isolieren der Entwicklung aus der Produktion) können Sie benutzerdefinierte Routentabellen innerhalb des Hubs erstellen, um die Routenverteilung zu steuern.
  • Aggregatdurchsatz: Der virtuelle Hubrouter unterstützt den Aggregatdurchsatz von bis zu 50 GBit/s, wenn er mit den maximal 50 Routinginfrastruktureinheiten konfiguriert ist. Die Standardbereitstellung verwendet 2 Routinginfrastruktureinheiten (3 GBit/s). Sie skalieren den Durchsatz, indem Sie die Routinginfrastruktureinheiten in Hubeinstellungen erhöhen.

Note

Automatisches Routing gilt für die Standardmäßige Transitkonnektivität. Benutzerdefinierte Szenarien, die Datenverkehr über virtuelle Netzwerkgeräte (NVAs) im Hub weiterleiten, erfordern möglicherweise benutzerdefinierte Routentabellen.

Wie man auswählt

In diesem Abschnitt können Sie die richtige Topologie und Ebene für Ihre Umgebung auswählen.

Hub-Spoke im Vergleich zu Virtual WAN

Verwenden Sie diese Tabelle, um zu ermitteln, ob eine herkömmliche Hub-Spoke-Topologie oder Virtual WAN die richtige Wahl für Ihre Umgebung ist:

Faktor Hub-and-Spoke (herkömmlich) Azure Virtual WAN
Management Vom Kunden verwaltetes virtuelles Hubnetzwerk Microsoft-verwaltete Hubinfrastruktur
Optimal für Bis zu ~30 VPN-Verzweigungsverbindungen 30+ VPN-Zweigstellen oder viele Azure Regionen
Routing Der Kunde konfiguriert UDRs für Spoke-zu-Spoke-Datenverkehr Automatisches Routing im virtuellen Hub
SD-WAN Integration Manuelle NVA-Bereitstellung und -Konfiguration Systemeigene SD-WAN Partnerintegration
Globaler Transit Erfordert das vom Kunden verwaltete Routing zwischen Regionen Integriert: Alle Hubs verbinden sich automatisch
Kostenmodell Hub-VNet-Ressourcen separat berechnet (Firewall, Gateway, Bastion) Bereitstellungseinheits- und Skalierungseinheitspreise

Tip

Virtual WAN ist eine Skalierungsalternative zu Hub-Spoke, keine Ersatzlösung. Organisationen mit weniger als 30 Filialen, einer einzelnen Region und einem Bedarf an voller Kontrolle über Hubressourcen sollten eine herkömmliche Hub-and-Spoke-Topologie verwenden.

Überlegungen zur Migration: Wenn Sie von einem herkömmlichen Hub-Spoke zu Virtual WAN wechseln, planen Sie eine parallel ausgeführte Migration. Stellen Sie einen Virtual WAN Hub zusammen mit Ihrem vorhandenen Hub bereit, migrieren Sie speichenverbindungen inkrementell, und überprüfen Sie das Routing nach jeder Verbindungsmigration. Virtual WAN das Importieren vorhandener UDR-Konfigurationen nicht unterstützt, daher müssen Sie das Routing neu entwerfen, um das automatische Verteilungsmodell des Hubrouters zu verwenden.

Wann bleiben Sie mit Hub-Spoke: Wählen Sie herkömmliche Hub-Spokes aus, wenn Sie präzise Kontrolle über das virtuelle Hubnetzwerk benötigen (z. B. die Bereitstellung von benutzerdefinierten NVAs direkt im Hub-Subnetz), wenn Ihre Organisation in einer einzelnen Region mit weniger als 10 Filialen arbeitet oder wenn Complianceanforderungen die vom Kunden verwaltete Routinginfrastruktur vorgeschrieben haben.

Standard im Vergleich zum Basic-Tarif

Virtual WAN bietet zwei Ebenen. Wählen Sie die Ebene aus, die Ihren Routing- und Konnektivitätsanforderungen entspricht:

Funktion Basic Standard
Standort-zu-Standort-VPN-Verbindung ✅ ✅
Point-to-Site-VPN ❌ ✅
ExpressRoute ❌ ✅
VNet-zu-VNet-Übertragung ❌ ✅
Transit zwischen Hubs ❌ ✅
Azure Firewall im Hub ❌ ✅
NVA im Hub ❌ ✅

Important

Sie können ein Upgrade von der Stufe "Basic" auf "Standard" durchführen, aber Sie können kein Downgrade von Standard zu Standard durchführen. Wählen Sie "Standard" aus, wenn Sie Transitrouting, ExpressRoute-Konnektivität oder Sicherheitsintegration benötigen.

Kostenmodell

Virtual WAN verwendet eine einheitenbasierte Preisgestaltung, die sich vom herkömmlichen Hub-Spoke-Modell unterscheidet:

  • Bereitstellungseinheiten (Hub): Sie zahlen eine Gebühr pro Stunde für den virtuellen Hub selbst. Diese Gebühr ist ein fester Kostenposten für die Infrastruktur des verwalteten Hubs.
  • Skalierungseinheiten (Gateways): VPN- und ExpressRoute-Gateways werden basierend auf der Anzahl der von Ihnen bereitgestellten Skalierungseinheiten in Rechnung gestellt. Mehr Skalierungseinheiten erhöhen die Bandbreitenkapazität und die Kosten proportional.
  • Routinginfrastruktureinheiten: Der Hubrouter wird pro Routinginfrastruktureinheit in Rechnung gestellt. Die Standardbereitstellung umfasst zwei Einheiten (3 GBit/s). Sie können für Umgebungen mit hohem Durchsatz bis zu 50 Einheiten (50 GBit/s) skalieren.
  • Datenverarbeitung: Sie bezahlen für Daten, die über den Hub verarbeitet werden, einschließlich VNet-zu-VNet, Branch-to-VNet und Inter-Hub-Datenverkehr. Internetgebundener Datenverkehr, der über Azure Firewall weitergeleitet wird, weist separate Datenverarbeitungsgebühren auf.
  • Add-On für den gesicherten Virtual Hub: Wenn Sie Azure Firewall über Firewall Manager bereitstellen, fallen zusätzlich zu den Virtual WAN-Hub-Kosten die standardmäßigen Gebühren für Azure Firewall an.

Vergleichen Sie die Kosten mit einer herkömmlichen Hub-Spoke-Topologie. Für kleine Bereitstellungen mit minimalen Filialen kann ein vom Kunden verwalteter Hub kostengünstiger sein. Bei einer großen Anzahl von Niederlassungen (30+) gleichen die Automatisierung und die verwaltete Infrastruktur bei Virtual WAN den Stückpreis in der Regel aus. Detaillierte Preise finden Sie unter Virtual WAN Preiskonzepten.

Gesicherter virtueller Hub: Wann der Firewall-Manager verwendet werden soll

Ein gesicherter virtueller Hub integriert Azure Firewall (oder eine unterstützte NVA) in Firewall Manager für zentralisierte Richtlinien:

Konfiguration Verwenden Sie, wenn Vorteil
Standard Virtual Hub (keine Firewall) Nur Branch-zu-VNet-Konnektivität, Sicherheit wird auf Spoke-Ebene gehandhabt Einfachste Bereitstellung, niedrigste Kosten
Gesicherter virtueller Hub mit Firewall-Manager Zentrale Datenverkehrsüberprüfung für privaten und Internetdatenverkehr Eine konsistente Richtlinie und Routingabsicht machen UDRs überflüssig
Gesicherter virtueller Hub mit NVA-Partner Vorhandene Firewallinvestitionen von Drittanbietern, spezifische Featureanforderungen Verwenden vorhandener Anbietertools und Know-how

Routingabsicht

Routing Intent vereinfacht die Steuerung des Datenverkehrs in Virtual WAN, indem der Datenverkehr automatisch über eine Sicherheitslösung (Azure Firewall oder eine unterstützte NVA) geleitet wird, ohne benutzerdefinierte Routentabellen oder UDRs zu erfordern.

Wenn Sie die Routingabsicht aktivieren, deklarieren Sie Richtlinien für zwei Datenverkehrstypen:

  • Internetdatenverkehr: Sämtlicher für das Internet bestimmter Datenverkehr aus verbundenen virtuellen Netzwerken wird über die Sicherheitslösung im Hub geleitet.
  • Privater Datenverkehr: Der gesamte Datenverkehr zwischen virtuellen Netzwerken, Zweigstellen und anderen Hubs wird über die Sicherheitslösung geleitet.

Die Routingabsicht entfernt die Notwendigkeit, Routingtabellen manuell zu verwalten. Die Virtual-WAN-Steuerebene konfiguriert automatisch alle erforderlichen Routen in allen verbundenen Hubs und Spoke-virtuellen Netzwerken.

Note

Routingabsicht erfordert einen gesicherten virtuellen Hub mit Azure Firewall oder einem unterstützten NVA-Partner. Sie ist nur auf der Standardebene verfügbar.

Warning

Die Änderungen der Routingtabelle, die von der Routingabsicht vorgenommen werden, sind unumkehrbar. Sie können die Routingabsicht entfernen, aber durch das Entfernen wird ihre vorherige defaultRouteTable-Konfiguration nicht automatisch wiederhergestellt. Speichern Sie eine Momentaufnahme Ihrer Konfiguration, bevor Sie die Routingabsicht aktivieren, da Sie alle vorherigen Routen manuell wiederherstellen müssen, wenn Sie sie später entfernen.

Verbindungsgrenzen und Skalierbarkeit

Virtual WAN unterstützt umfangreiche Bereitstellungen:

  • Bis zu 1.000 STANDORT-zu-Standort-VPN-Verbindungen pro virtuellem Hub.
  • Mehrere Hubs pro Virtual WAN (eine pro Region oder mehrere pro Region zur Isolation).
  • Bis zu 50 GBit/s Aggregatdurchsatz pro Hubrouter (erfordert maximal 50 Routinginfrastruktureinheiten. Der Standardwert ist 2 Einheiten bei 3 GBit/s).
  • Any-to-Any-Konnektivität über alle VNet-Verbindungen, VPN-Verzweigungen und ExpressRoute-Schaltkreise innerhalb desselben Hubs hinweg.

Für Organisationen, die die Grenzwerte eines einzelnen Hubs überschreiten, stellen Sie zusätzliche Hubs in denselben oder verschiedenen Regionen bereit. Die Virtual WAN behandelt automatisch das Routing zwischen Hubs.

SD-WAN-Partnerintegration

Virtual WAN bietet systemeigene Integration mit SD-WAN Partnergeräten. Partnergeräte können:

  • Exportieren Sie Geräteinformationen zu Zweigstellen programmgesteuert nach Azure.
  • Laden Sie die Azure-Konfiguration automatisch herunter.
  • Richten Sie IPsec/IKE-Konnektivität mit dem virtuellen Hub ohne manuelle Konfiguration ein.

Durch diese Automatisierung wird die Bereitstellungszeit von Branches in großem Maßstab von Tagen auf Minuten reduziert. Die aktuelle Liste der unterstützten Partner finden Sie unter Virtual WAN Partner.

Funktionsweise der Partnerautomatisierung

SD-WAN Partner verwenden die Virtual WAN Konnektivitätsautomatisierungs-API, um Verzweigungsgerätelebenszyklus programmgesteuert zu verwalten:

  • Geräteregistrierung: Der Partnercontroller registriert Zweigstellengeräte mit der Virtual WAN Ressource, einschließlich Gerätemetadaten und Bandbreitenanforderungen.
  • Konfigurationsdownload: Die Partnerplattform ruft die Hubgatewaykonfiguration (IP-Adressen, vorab freigegebene Schlüssel, BGP-Einstellungen) ohne manuelle Portalinteraktion ab.
  • Tunneleinrichtung: Das Partnergerät richtet IPsec-Tunnel mithilfe der heruntergeladenen Konfiguration an das VPN-Gateway des virtuellen Hubs ein.
  • Laufende Zustandsüberwachung: Die Partnerplattform überwacht den Zustand der Tunnel und kann die Verbindung wiederherstellen, wenn Tunnel ausfallen.

Partner wie VMware SD-WAN, Fortinet SD-WAN, Cisco Viptela und Versa Networks unterstützen dieses Automatisierungsmodell. Jeder Partner implementiert über die Virtual WAN-API eine eigene Orchestrierungsebene. Bewerten Sie partnerspezifische Funktionen wie anwendungsfähiges Routing, Datenverkehrsoptimierung und lokale Internet-Breakout, bevor Sie einen Partner auswählen.

Überlegungen zum Entwurf

Bei den meisten Lift-and-Shift-Migrationen ist Virtual WAN nicht die Starttopologie. Bewerten, wenn sie gerechtfertigt wird:

  • Wenn Virtual WAN gerechtfertigt wird. Wenn Ihre Lift-and-Shift-Umgebung mehr als 30 Niederlassungsstandorte umfasst, sich über drei oder mehr Azure-Regionen erstreckt oder eine SD-WAN-Integration erfordert, reduziert das automatisierte Routing von Virtual WAN den Betriebsaufwand im Vergleich zur Verwaltung von UDRs in vielen Hub-Spoke-Peerings.
  • Hub-Spoke reicht für kleinere Bestände aus. Ein einzelner Hub mit VPN Gateway verarbeitet bis zu 30 Standort-zu-Standort-Verbindungen und 500 Speichen-Peerings. Wenn Ihre Migration innerhalb dieser Grenzen bleibt, ist das herkömmliche Hub-Spoke-Modell einfacher und kostengünstiger.
  • Ein Migrationspfad ist vorhanden. Wenn Sie mit Hub-Spoke beginnen und später Virtual WAN benötigen, können Sie migrieren, indem Sie einen Virtual WAN Hub zusammen mit Ihrem vorhandenen Hub bereitstellen und inkrementelle Speichenverbindungen verschieben.

Multiregion-Bereitstellungen erfordern nicht automatisch Virtual WAN. Bewerten Sie Ihre Routing-Komplexität:

  • Eine Dual-Hub-and-Spoke-Architektur reicht oft aus. Stellen Sie für aktiv aktive Architekturen in zwei Regionen einen Hub in jeder Region mit VNet-Peering zwischen Hubs bereit. Dieses Architekturmuster deckt die meisten Modernisierungsszenarien ohne den Mehraufwand durch die Preisgestaltung pro Einheit von Virtual WAN ab.
  • Wenn die Komplexität zu Virtual WAN führt. Wenn Ihre Modernisierung über zwei Regionen hinaus wächst, standortübergreifende Konnektivität zwischen Regionen hinzufügt oder eine automatische Routenweitergabe zwischen Hubs ohne manuelle UDR-Verwaltung erfordert, vereinfacht Virtual WAN den Betrieb.
  • Verwechseln Sie Multiregion nicht mit Virtual WAN. Die Entscheidung, Virtual WAN zu verwenden, hängt von der Anzahl der Zweigstellen, der Regionsanzahl und der Routingkomplexität ab. Multiregion allein ist keine ausreichende Rechtfertigung.

Virtual WAN bietet mit Azure das Äquivalent zum AWS Transit Gateway für einen zentralisierten, skalierbaren Transit:

  • Entsprechung des Transit Gateway Der virtuelle Hub von Virtual WAN fungiert wie AWS Transit Gateway: Er leitet den Datenverkehr automatisch zwischen verbundenen virtuellen Netzwerken, Niederlassungen und cloudübergreifenden VPN-Tunneln weiter. Wenn Sie von AWS migrieren, vereinfacht diese Zuordnung Ihre Architekturübersetzung.
  • Sicherer virtueller Hub (gesicherter virtueller Hub). Stellen Sie Azure Firewall über Firewall-Manager im virtuellen Hub bereit. Aktivieren Sie die Routingabsicht, um den gesamten privaten und Internetdatenverkehr über die Firewall umzuleiten. Dies bietet eine zentrale Inspektion für cloudübergreifenden Datenverkehr, der in Azure eintritt.
  • VPN-Verbindungen mit Google Cloud und AWS. Erstellen Sie Standort-zu-Standort-VPN-Verbindungen vom Virtual WAN Hub zu Google Cloud VPN (HA VPN) und AWS Virtual Private Gateways. Virtual WAN unterstützt bis zu 1.000 VPN-Verbindungen pro Hub, wodurch mehr Arbeitslasten migriert werden können.
  • Multiregion-Planung. Stellen Sie virtuelle Hubs in jeder Azure Region bereit, in der migrierte Anwendungen landen. Inter-Hub-Routing wird automatisch über das Microsoft-Backbone weitergegeben und entspricht dem Transit-Gateway-Peering-Modell in AWS.

Prerequisites

Bevor Sie eine Virtual WAN Topologie implementieren:

  • Verstehen von Hub-Spoke-Konzepten. Virtual WAN baut auf dem Hub-Spoke-Modell auf. Überprüfen Sie die Hub-and-Spoke-Topologie für grundlegende Konzepte.
  • Inventarisieren Sie Ihre Zweigstellenstandorte. Dokumentieren Sie die Anzahl der Filialen, ihre geografische Verteilung und die aktuelle Konnektivität (VPN, MPLS, SD-WAN).
  • Definieren Sie Ihre Regionsstrategie. Bestimmen Sie, welche Azure Regionen Workloads hosten und wo Sie virtuelle Hubs benötigen.
  • Wählen Sie Ihren Tarif aus. Entscheiden Sie zwischen "Basic" (nur Standort-zu-Standort-VPN) und "Standard" (vollständige Übertragung, ExpressRoute, Firewall), basierend auf der Vergleichstabelle der Ebene in diesem Artikel.
  • Bewerten Sie die Sicherheitsanforderungen. Ermitteln Sie, ob eine zentralisierte Überprüfung (geschützter virtueller Hub) oder Sicherheit pro Spoke geeignet ist.

Sicherheitsüberlegungen

  • Gesicherter virtueller Hub. Stellen Sie Azure Firewall über Firewall-Manager bereit, um konsistente Sicherheitsrichtlinien für alle verbundenen virtuellen Netzwerke und Verzweigungen anzuwenden. Der Firewall-Manager bietet eine zentrale Regelverwaltung über mehrere gesicherte Hubs hinweg.
  • Routingabsicht. Aktivieren Sie Routingabsicht, um privaten und Internetdatenverkehr automatisch über Ihre Sicherheitslösung zu steuern. Mit diesem Ansatz wird verhindert, dass Datenverkehr die Inspektion umgeht, indem die manuelle Routingkonfiguration eliminiert wird.
  • Einschränkungen von NVA-in-hub. Im Hub bereitgestellte virtuelle Netzwerkgeräte verfügen über unterschiedliche Funktionen als Azure Firewall. Überprüfen Sie die Featureparität mit Ihren Sicherheitsanforderungen, bevor Sie einen NVA-Partner auswählen.
  • SD-WAN Sicherheitsmodell. Wenn Sie SD-WAN Partnergeräte integrieren, hängt die Datenverkehrssicherheit von der Implementierung des Partners ab. Bewerten Sie die Verschlüsselungs-, Authentifizierungs- und Funktionen zur Datenverkehrsüberprüfung des Partners.
  • Isolation des Datenverkehrs zwischen Hubs. Der Datenverkehr zwischen virtuellen Hubs fließt über das Microsoft Backbone und durchläuft das öffentliche Internet nicht. Das Backbone ist ein privates Netzwerk, der Datenverkehr wird jedoch standardmäßig nicht auf der Netzwerkebene verschlüsselt. Verwenden Sie TLS auf Anwendungsebene für vertrauliche Daten zwischen Regionen.

Weitere Informationen

Nächste Schritte

Tip

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

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

Hybridkonnektivität: Verbinden Sie Ihre migrierten Workloads über VPN Gateway oder ExpressRoute wieder mit der lokalen Umgebung.

Als Nächstes in Ihrer Modernisierungsreise:

Planen Sie Ihre Bereitstellung in mehreren Regionen: Erweitern Sie Ihre Architektur auf mehrere Regionen, um Aktiv/Aktiv-Resilienz zu erzielen.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Entwerfen Sie Ihre Azure Zielzonen-VNets: Erstellen Sie die Azure Virtual Network Foundation für Ihre verbundenen und migrierten Workloads.

  • Last updated on