Regionsübergreifende und Multicloudkonnektivität

Dieser Artikel hilft Ihnen, Azure Workloads in mehreren Regionen zu verbinden und die Konnektivität mit anderen Cloudanbietern wie Amazon Web Services (AWS) und Google Cloud zu erweitern.

Inhalt dieses Artikels

In diesem Artikel werden die Entwurfsentscheidungen für die Verbindung Azure virtuellen Netzwerke (VNets) über Regionen hinweg und das Einrichten von Netzwerkpfaden zu Workloads behandelt, die in anderen Clouds ausgeführt werden. Sie erfahren, wann Sie globalen VNet-Peering, Virtual WAN, ExpressRoute Global Reach, Standort-zu-Standort-VPN und Azure Route Server für regionsübergreifende und multicloud-Szenarien verwenden.

Wer diesen Artikel benötigt

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

  • Ihre Architektur umfasst mehrere Azure Regionen und benötigt eine private Konnektivität zwischen ihnen.
  • Sie müssen Azure Workloads mit AWS, Google Cloud oder einem anderen externen Netzwerk verbinden.
  • Sie müssen Global VNet Peering, Virtual WAN, ExpressRoute Global Reach, Standort-zu-Standort-VPN oder Azure Route Server vergleichen.
  • Sie müssen eine robuste Konnektivität für Notfallwiederherstellung, globale Expansion oder Multicloud-Vorgänge entwerfen.

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.

Heben und Verschieben des Fokus: Fügen Sie diesen Artikel nur dann in Ihren Lesepfad ein, wenn Ihre Migration mehrere Azure Regionen umfasst oder eine Verbindung mit einer anderen Cloud herstellt. Die meisten Lift-and-Shift-Projekte beginnen mit einer einzelnen Region und fügen später regionenübergreifende Konnektivität hinzu, wenn die Notfallwiederherstellung oder die geografische Erweiterung zu einer Priorität wird.

Modernisierungsfokus: Fügen Sie diesen Artikel ein, wenn Für Ihre Modernisierung eine explizite regionsübergreifende private Konnektivität erforderlich ist, die über den Artikel mit mehreren Regionen hinausgeht. Sie benötigen diese Anleitung, wenn Spokes in verschiedenen Regionen direkte Kommunikationspfade erfordern oder wenn Ihre Aktiv/Aktiv-Bereitstellung privates Peering zwischen regionalen Hubs benötigt.

Cloudübergreifender Fokus: Dieser Artikel ist Ihre zentrale Entwurfsentscheidung. Lesen Sie es, bevor Sie zwischen Hub-Spoke und Virtual WAN für Ihre cloudübergreifende Transitarchitektur wählen. Sie verwenden diesen Artikel, um Ihre vorhandene Multicloudtopologie zu entdecken, Dienste zwischen AWS oder Google Cloud und Azure zuzuordnen und zu definieren, wie Azure eine Verbindung mit Workloads herstellt, die während der Migration in anderen Clouds verbleiben.

Azure Dienste und Features

Azure bietet mehrere Dienste für die regionsübergreifende und multicloud-Konnektivität. Jeder Dienst behandelt unterschiedliche Skalierungs-, Bandbreiten- und Verwaltungsanforderungen.

Service Was es bietet Wann wird es verwendet?
Globales VNet-Peering Private Konnektivität mit geringer Latenz zwischen VNets in verschiedenen Azure Regionen. Der Datenverkehr bleibt auf dem Microsoft Backbone. Die Bandbreite ist nur durch die SKU des virtuellen Computers (VM) begrenzt, nicht durch ein Gateway. Direkte Kommunikation zwischen zwei VNets in verschiedenen Regionen ohne Gateway-Appliance.
Azure Virtual WAN (Standardebene) Von Microsoft verwalteter globaler Transit-Hub, der VNets, Zweigstellen und Remotebenutzer in allen Regionen verbindet. Stellt transitives Routing zwischen allen verbundenen Netzwerken bereit. Organisationen mit vielen Regionen und Zweigstellen, die eine beliebige Konnektivität benötigen, ohne einzelne Peeringverbindungen zu verwalten.
ExpressRoute über Cloud-Exchange Dedizierte cloudübergreifende Verbindung über einen Exchange-Anbieter eines Drittanbieters (z. B. Equinix oder Megaport). Bietet private Konnektivität mit hoher Bandbreite zu AWS oder Google Cloud. Multicloud-Architekturen mit SLA-Anforderungen für Bandbreite, bei denen Datenverkehr das öffentliche Internet nicht durchlaufen darf.
Standort-zu-Standort-VPN zu anderen Clouds Verschlüsselter IPsec-Tunnel zwischen Azure VPN Gateway und dem VPN-Gateway eines anderen Cloudanbieters (AWS Virtual Private Gateway oder Google Cloud VPN). Multicloud-Konnektivität für Test-, Entwicklungs- oder Produktionsszenarien, in denen dedizierte Schaltkreise nicht gerechtfertigt sind.
Azure Route Server Ermöglicht den dynamischen BGP-Routenaustausch zwischen Ihrem VNet und virtuellen Netzwerkgeräten (NVAs). Fügt NVA-gelernte Routen in die Azure SDN-Routing-Fabric ein. Benutzerdefiniertes Routing mit NVAs von Drittanbietern in einem Hub-VNet oder komplexes Multicloud-Routing, das eine BGP-Verteilung an Azure verbundene Netzwerke erfordert.

Funktionsweise des globalen VNet-Peerings

Global VNet Peering erstellt eine direkte Verbindung zwischen zwei virtuellen Netzwerken in verschiedenen Azure Regionen. Die Verknüpfung läuft vollständig über das Microsoft Backbone und durchläuft nie das öffentliche Internet. Nachdem Sie eine Peeringbeziehung konfiguriert haben, können Ressourcen in jedem VNet mit privaten IP-Adressen kommunizieren, als wären sie im selben Netzwerk.

Im Gegensatz zu gatewaybasierten Ansätzen führt Peering keinen einzelnen Drosselpunkt ein. Die Bandbreite zwischen per Peering verbundenen VNets richtet sich nach der VM-SKU auf jeder Seite. Es gibt keine dedizierte Gateway-Appliance, die den Durchsatz begrenzt. Mit diesem Design wird das globale VNet-Peering zur Option mit der niedrigsten Latenz für die regionsübergreifende Kommunikation zwischen einer kleinen Anzahl von VNets.

Peering ist jedoch nicht transitiv. Wenn VNet A mit VNet B per Peering verbunden ist und VNet B mit VNet C per Peering verbunden ist, kann Datenverkehr von VNet A VNet C nicht über VNet B erreichen. Jedes VNet-Paar, das direkte Kommunikation benötigt, braucht eine eigene Peeringverbindung. In einem Hub-Spoke-Modell bedeutet dies, dass Sie die regionalen Hub-VNets in der Regel miteinander per Peering koppeln und benutzerdefinierte Routen (UDRs) oder NVAs verwenden, um den Spoke-zu-Spoke-Datenverkehr regionsübergreifend über die Hubs weiterzuleiten.

Virtual WAN – globaler Transit

Azure Virtual WAN (Standardebene) entfernt die Notwendigkeit, Peering zwischen regionalen Hubs manuell zu konfigurieren. Wenn Sie Virtual WAN Hubs in mehreren Regionen bereitstellen, stellt Microsoft automatisch Hub-zu-Hub-Verbindungen über das Backbone her. Routen, die in einem Hub gelernt wurden, werden an alle anderen Hubs weitergegeben, wodurch ein beliebiges Transit-Fabric erstellt wird.

Diese automatische Weiterleitung bedeutet, dass ein Spoke-VNet, das mit einem Hub in East US verbunden ist, ein Spoke-VNet erreichen kann, das mit einem Hub in West Europe verbunden ist, ohne dass zusätzliches Peering oder eine Routentabellenkonfiguration erforderlich ist. Virtual WAN erweitert diese Transitivität auch auf Zweigstellen (verbunden über Standort-zu-Standort-VPN oder ExpressRoute) und Remotebenutzer (verbunden über Point-to-Site-VPN). Das Ergebnis ist ein vollständig vermaschtes, globales, von Microsoft verwaltetes Netzwerk.

Aktivieren Sie für die Datenverkehrsprüfung zwischen Regionen Routing Intent auf gesicherten virtuellen Hubs. Routing Intent erzwingt den hubübergreifenden Datenverkehr über Azure Firewall und ermöglicht Ihnen so einen zentralen Einblick sowie die Durchsetzung von Richtlinien in allen Regionen, ohne einzelne NVAs in jedem Hub bereitstellen und verwalten zu müssen.

Wie man auswählt

Verwenden Sie die folgenden Entscheidungstabellen, um den richtigen Konnektivitätsansatz für Ihr Szenario auszuwählen.

Regionsübergreifende Konnektivitätsoptionen

Diagramm mit regionsübergreifenden Verbindungsmustern, einschließlich globaler VNet-Peering, Virtual WAN Hub-zu-Hub-Transit und cloudübergreifender VPN-Pfade.

Ihr Szenario Empfohlener Ansatz Warum?
Zwei VNets in verschiedenen Regionen benötigen direkte Kommunikation Globales VNet-Peering Niedrigste Latenz relativ zu Internetpfaden, kein Gateway-Engpass, einfach zu konfigurieren. Bandbreitenskalierung mit VM-SKU.
Viele Regionen, viele Niederlassungen, verwalteter Transit erforderlich Azure Virtual WAN (Standardebene) Bietet transitives Any-to-Any-Routing über alle verbundenen Hubs hinweg. Microsoft verwaltet die Routinginfrastruktur.
Verbinden lokaler Websites miteinander über Azure Globale ExpressRoute-Reichweite Verbindet zwei ExpressRoute-Schaltkreise, sodass der lokale Datenverkehr das Microsoft Backbone durchläuft. Es ist nicht nötig, den Datenverkehr über Azure-VNets umzuleiten.
Benutzerdefiniertes Routing oder NVAs von Drittanbietern in einem regionalen Hub Azure Route Server Ermöglicht das dynamische BGP-Peering zwischen NVAs und Azure. Von der NVA erlernte Routen werden automatisch in Spoke-VNets eingespeist.

Multicloud-Konnektivitätsoptionen

Ihr Szenario Empfohlener Ansatz Warum?
Hohe Bandbreite und SLA, die für cloudübergreifenden Datenverkehr erforderlich ist ExpressRoute über Cloud Exchange-Anbieter Stellt dedizierte Kapazität mit vorhersagbarer Latenz bereit. Der Exchange-Anbieter verbindet Ihren ExpressRoute-Schaltkreis mit dem Direct Connect-Dienst der anderen Cloud.
Budgetbeschränkte, Tests oder Workloads mit geringem Durchsatz Standort-zu-Standort-VPN Verwendet vorhandene Internetverbindung ohne Schaltungskosten. Geeignet, wenn Bandbreitenanforderungen bescheiden sind.
Hybrid plus Multicloud (lokal, Azure und eine andere Cloud) ExpressRoute Global Reach + Cloud Exchange Kombiniert Global Reach für Verbindungen von lokalen Umgebungen zu Azure mit einem Cloud-Exchange für die Konnektivität von Azure zu anderen Clouds und schafft so ein einheitliches privates Backbone.

Überlegungen zum Entwurf

Bei den meisten Lift-and-Shift-Migrationen ist die standortübergreifende Konnektivität eine zukünftige Erweiterungsüberlegung anstelle einer täglichen Anforderung. Die anfängliche Bereitstellung zielt wahrscheinlich auf eine einzelne Azure Region ab.

Wenn Sie eine zukünftige Erweiterung planen:

  • Globaler VNet-Peering: Verwenden Sie das globale VNet-Peering zwischen regionalen Hub-VNets, wenn Sie eine zweite Azure Region hinzufügen. Dieser Ansatz bietet Ihnen private Konnektivität mit geringer Latenz, ohne eine Gateway-Appliance bereitzustellen. Der Datenverkehr bleibt auf dem Microsoft Backbone und skaliert mit Ihrer VM-SKU.
  • Aufgeschobene Komplexität: Vermeiden Sie die Bereitstellung von Virtual WAN oder ExpressRoute Global Reach, bis Ihre IT-Landschaft über zwei Regionen hinauswächst oder Anforderungen an die Anbindung von Niederlassungen hinzukommen.
  • DR-Vorbereitung: Auch wenn die regionsübergreifende Konnektivität heute nicht benötigt wird, dokumentieren Sie, welche Workloads Notfallwiederherstellung erfordern, und planen Sie die Peeringtopologie vorab, damit Sie sie bei Bedarf schnell bereitstellen können.

Ihre modernisierte Architektur verwendet Aktiv/Aktiv-Bereitstellungen in allen Regionen. Regionsübergreifendes Peering ermöglicht die direkte Sprach-zu-Speichen-Kommunikation, wenn Ihre Anwendungsebenen regionale Grenzen umfassen.

Wichtige Entwurfsentscheidungen für die Modernisierung:

  • Regionsübergreifendes Peering für Aktiv/Aktiv: Koppeln Sie die Hub-VNets Ihrer primären und Backup-Region per Peering, um einen bidirektionalen Datenverkehr zu ermöglichen. Anwendungsteams in den ContosoBiz- und ContosoCare-Spokes können Ressourcen in beiden Regionen über den Peeringpfad des Hubs erreichen.
  • Routing über Hubs: Da globales VNet-Peering nicht transitiv ist, leiten Sie den regionenübergreifenden Spoke-Datenverkehr über die regionale Hub-NVA oder die Azure Firewall. Verwenden Sie benutzerdefinierte Routen (USER-Defined Routes, UDRs), um den regionübergreifenden Datenverkehr über die Hubfirewall zur Überprüfung zu leiten.
  • Selektives Peering: Nicht alle Spokes benötigen regionenübergreifende Konnektivität. Koppeln Sie nur die Hub-VNets per Peering und verwenden Sie die Routenweitergabe, um bestimmte Spoke-VNets zu erreichen, die an Aktiv/Aktiv-Workloads teilnehmen.

In diesem Artikel entwerfen Sie Ihre Multicloud-Konnektivitätsarchitektur. Bevor Sie Azure Infrastruktur planen, müssen Sie Ihre vorhandene Cloudtopologie und Kartendienste zwischen Anbietern ermitteln.

Cloudübergreifender Ermittlungsworkflow

  1. Entdecken Sie Ihre vorhandene Topologie: Verwenden Sie Workload Discovery auf AWS und das Google Cloud Network Intelligence Center, um Ihre aktuelle Virtual Private Cloud (VPC)-Topologie, Peering-Beziehungen und Datenverkehrsmuster abzubilden.
  2. Datenverkehrsflüsse identifizieren: Dokumentieren Sie die VPC-zu-VPC-Kommunikation, ein- und ausgehende Internetpfade sowie Verzweigungs-zu-Cloud-Verbindungen in Ihrer AWS- oder Google-Cloud-Umgebung.
  3. Zuordnen von Diensten zu Azure Entsprechungen: Die Schlüsselzuordnungen für den Verbindungsentwurf lauten wie folgt:
AWS / Google Cloud Service Azure-Äquivalent
Transit-Gateway Azure Virtual WAN
VPC / VPC-Netzwerk Virtuelles Azure-Netzwerk
Sicherheitsgruppen/Firewallregeln Netzwerksicherheitsgruppen (NSGs)

Vollständige AWS-to-Azure- und Google Cloud-to-Azure-Servicezuordnungen finden Sie in der Checkliste zur cloudübergreifenden Ermittlung.

Entscheidungen zur Konnektivitätsarchitektur

Nachdem Sie die Erkennung und Servicezuordnung abgeschlossen haben, entscheiden Sie Folgendes:

  • Transitmodell: Wählen Sie Virtual WAN aus, wenn Sie über mehrere VPCs, Filialen, Regionen oder Cloud-Kanten verfügen. Virtual WAN bietet das Azure-Äquivalent zu AWS Transit Gateway mit verwaltetem Any-to-Any-Routing.
  • Cloudübergreifendes VPN: Stellen Sie VPN Gateway Verbindungen von Ihrem Virtual WAN Hub (oder Hub-VNet) zu AWS Virtual Private Gateway und Google Cloud VPN bereit. Verwenden Sie IPsec-Tunnel für verschlüsselte cloudübergreifende Kommunikation.
  • Anwendungen, die bleiben: Identifizieren Sie Workloads, die während der Migration in AWS oder Google Cloud verbleiben. Diese Workloads benötigen eine dauerhafte Konnektivität über die cloudübergreifenden VPN-Tunnel, bis die Migration abgeschlossen ist.

Voraussetzungen

Bevor Sie eine regionsübergreifende oder multicloudbasierte Konnektivität implementieren, bestätigen Sie die folgenden Anforderungen:

  • Zwei oder mehr Azure Regionen mit bereitgestellten VNets: Ihre Workloads müssen bereits in mehreren Regionen vorhanden (oder geplant sein). Informationen zur VNet-Planung finden Sie im Artikel zu VNets und Subnetzen .
  • Hub-Spoke- oder Virtual WAN Topologie: Regionsübergreifende Designs bauen auf einer etablierten Topologie in jeder Region auf. Siehe den Artikel zu Hub-Spoke oder den Artikel zu Virtual WAN.
  • ExpressRoute-Schaltkreise (für globale Reichweite): Wenn Sie beabsichtigen, lokale Standorte zu verbinden, benötigen Sie vorhandene ExpressRoute-Schaltkreise an jedem Standort. Weitere Informationen finden Sie im Artikel zur Hybridkonnektivität.
  • Cloudübergreifender Kontozugriff: Für multicloud VPN oder Austauschkonnektivität benötigen Sie administrativen Zugriff auf die Netzwerkkonsole des anderen Cloudanbieters, um die Remoteseite der Verbindung zu konfigurieren.

Sicherheitsüberlegungen

Die regionsübergreifende und multicloud-Konnektivität führt spezifische Sicherheitsbedenken ein, die in Bereitstellungen mit einer Region nicht vorhanden sind.

Regionenübergreifende Datenverkehrsüberprüfung

Globaler VNet-Peering ist nicht transitiv. Der Datenverkehr zwischen peered VNets fließt direkt, ohne einen Firewall- oder Inspektionspunkt zu durchlaufen. Wenn Sie den regionsübergreifenden Datenverkehr prüfen müssen, leiten Sie ihn über eine virtuelle Netzwerk-Appliance (NVA) oder Azure Firewall in jedem regionalen Hub weiter.

Aktivieren Sie für Virtual WAN Routingabsicht mit Richtlinien für privaten Datenverkehr auf gesicherten virtuellen Hubs. Routing Intent erzwingt hubübergreifenden Datenverkehr über von Azure Firewall Manager verwaltete Firewalls, die eine zentrale, regionsübergreifende Überprüfung des Datenverkehrs bieten. Für diese Konfiguration ist die Stufe "Standard Virtual WAN" erforderlich.

Verschlüsseln von cloudübergreifenden Verbindungen

Standort-zu-Standort-VPN-Tunnel zu anderen Clouds werden standardmäßig verschlüsselt (IPsec/IKE). ExpressRoute-Verbindungen über einen Cloudaustausch sind jedoch privat, aber nicht auf der Netzwerkebene verschlüsselt. Wenn Sie eine Verschlüsselung über ExpressRoute benötigen, stellen Sie MACsec auf ExpressRoute Direct-Schaltkreisen bereit, oder verwenden Sie die TLS-Verschlüsselung auf Anwendungsebene.

Bei cloudübergreifendem Datenverkehr, der einen Cloudaustausch ohne VPN-Überlagerung durchläuft, erwägen Sie die Bereitstellung eines NVA-basierten IPsec-Tunnels innerhalb des ExpressRoute-Pfads. Dieser Ansatz fügt Verschlüsselung hinzu, ohne die Bandbreiten- und Latenzvorteile eines dedizierten Schaltkreises aufzugeben. Alternativ können Sie auf der Anwendungsebene gegenseitige TLS (MTLS) verwenden, damit jeder Dienstendpunkt Identität überprüft und Daten unabhängig vom zugrunde liegenden Transport verschlüsselt. Die Wahl hängt davon ab, ob Sie eine Verschlüsselung auf Netzwerkebene (all-traffic) benötigen oder die Verschlüsselung auf der Anwendungsebene erzwingen können.

Kostenaspekte

Bei allen regionenübergreifenden Verbindungen entstehen Gebühren für die Datenübertragung. Global VNet Peering, der Inter-Hub-Datenverkehr von Virtual WAN und regionsübergreifende Tunnel für VPN Gateway werden alle nach ausgangsbasierter Preisgestaltung abgerechnet. Die Preise variieren je nach Zonenpaar:

  • Intra-kontinental (z. B. von Ost-USA in die West-USA): Niedrigerer Preis pro GB, in der Regel im Bereich der standardmäßigen Egress-Preise für die Region.
  • Interkontinental (z. B. Ost-USA nach Westeuropa): Höherer Preis pro GB aufgrund längerer Backbone-Strecken und kontinentübergreifender Kapazität.

Virtual WAN erhebt eine Gebühr pro Verbindungseinheit für jedes Spoke-VNet bzw. jede Niederlassung, das bzw. die an einen Hub angebunden ist, sowie eine Datenverarbeitungsgebühr für Datenverkehr, der über einen gesicherten Hub geleitet wird, auf dem Azure Firewall ausgeführt wird. Diese mehrstufige Preisgestaltung bedeutet, dass Virtual WAN mehr als einfaches globales VNet-Peering für Architekturen mit nur wenigen Regionen und wenigen Speichen kosten kann, aber es bietet eine bessere Einheitsökonomie im Maßstab, wenn Dutzende von Filialen und Regionen eine Verbindung herstellen.

Für die Multicloud-Konnektivität über einen Cloud-Exchange fallen Portgebühren und Cross-Connect-Gebühren des Exchange-Anbieters sowie Azure-ExpressRoute-Leitungsgebühren und Direct-Connect-Gebühren des anderen Cloudanbieters an. Standort-zu-Standort-VPN vermeidet Schaltkreiskosten, verursacht aber weiterhin Standardausgangsgebühren für Daten, die Azure verlassen.

Anleitung: Platzieren Sie Workloads mit hohem Datenverkehr nach Möglichkeit in derselben Region. Reservieren Sie regionsübergreifende Pfade für die Synchronisierung der Steuerungsebene, die asynchrone Replikation und das Failover für die Notfallwiederherstellung, da es sich dabei in der Regel um Datenströme mit geringem Volumen handelt.

Notfallwiederherstellungsmuster

Die regionsübergreifende Konnektivität ist eine grundlegende Grundlage für die Notfallwiederherstellung (DR). Der von Ihnen gewählte Ansatz bestimmt Ihr Wiederherstellungszeitziel (Recovery Time Objective, RTO) und Ihr Wiederherstellungspunktziel (Recovery Point Objective, RPO).

Active-active

Beide Regionen dienen gleichzeitig dem Produktionsverkehr. Ein globaler Lastenausgleich (z. B. Azure Front Door oder Azure Traffic Manager) verteilt Anforderungen über Regionen hinweg. Wenn eine Region fehlschlägt, verschiebt sich der Datenverkehr mit minimaler Unterbrechung in die überlebende Region. Dieses Muster liefert den niedrigsten RTO (Sekunden bis Minuten), erfordert jedoch eine vollständige Infrastruktur in beiden Regionen und bidirektionalen Datensynchronisierungen, wodurch Kosten und Komplexität erhöht werden.

Active-passive

Eine Region bedient den Produktivverkehr, während die zweite Region mit vorab bereitgestellter (aber gegebenenfalls kleiner dimensionierter) Infrastruktur in Bereitschaft bleibt. Die Replikation hält die Daten der passiven Region aktuell. Im Fehlerfall schalten Sie die passive Region aktiv und leiten Sie den Datenverkehr um. RTO hängt davon ab, wie schnell Sie passive Ressourcen skalieren und DNS- oder Lastenausgleichsfailover ausführen, in der Regel dauert dies Minuten bis zu mehreren zehn Minuten.

Pilotlicht

Eine minimale Präsenz in der sekundären Region (mit replizierten Datenbanken und bereitgestellter zentraler Netzwerkinfrastruktur), jedoch ohne aktive Rechenressourcen. Beim Failover stellen Sie Rechenressourcen für die Anwendung bereit oder skalieren sie und schalten den Datenverkehr um. Dieser Ansatz minimiert die Kosten im stabilen Betrieb, erhöht jedoch die RTO, da die Rechenressourcen erst gestartet werden müssen, bevor die Region Datenverkehr verarbeiten kann.

Bei allen Mustern stellt die regionenübergreifende Konnektivität (Global VNet Peering oder Virtual-WAN-Inter-Hub) den privaten Datenpfad für den Replikationsverkehr bereit. Stellen Sie sicher, dass Ihre DR-Runbooks etwaige Verzögerungen bei der Routenweitergabe berücksichtigen und dass die Regeln der Netzwerksicherheitsgruppe (NSG) in der sekundären Region den Failover-Datenverkehr zulassen.

Schlüsseleinschränkungen

Constraint Auswirkungen
Globaler VNet-Peering ist nicht transitiv Dass VNet A mit VNet B und VNet B mit VNet C per Peering verbunden ist, bedeutet nicht, dass A C erreichen kann. Sie müssen A direkt mit C per Peering verbinden oder eine Transitlösung wie Virtual WAN verwenden.
Virtual WAN im Basic-Tarif unterstützt keine Transitivität Die grundlegende Virtual WAN unterstützt keine transitive VNet-zu-VNet-Konnektivität. Verwenden Sie die Standardebene für die regionsübergreifende Übertragung.
ExpressRoute Global Reach erfordert Premium-SKU für geopolitische Verbindungen Schaltkreise in verschiedenen geopolitischen Regionen (z. B. USA und Europa) erfordern das Premium-Add-On. Standard-SKU-Schaltkreise verbinden sich nur innerhalb derselben geopolitischen Grenze.
Für AWS empfohlenes Active-Active-VPN-Gateway AWS Virtual Private Gateway erstellt zwei Tunnel pro VPN-Verbindung. Konfigurieren Sie Azure VPN Gateway im aktiven Modus, um alle verfügbaren Tunnel zu verwenden und asymmetrisches Routing zu vermeiden.

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:

Netzwerk mit mehreren Regionen: Planen Sie die Multiregion-Konnektivität und das Failover, wenn Ihre Migration über eine Region hinausgeht.

Als Nächstes in Ihrer Modernisierungsreise:

Netzwerküberwachung und Beobachtbarkeit: Ermöglichen Sie die Observierbarkeit in allen Regionen für die Produktionsbereitschaft.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Virtual WAN Topologie: Verwenden Sie Virtual WAN als Transithub für Ihre Multicloud- und Multibranch-Konnektivität.

  • Last updated on