Multiregion-Netzwerkdesign

In diesem Artikel wird erläutert, wie Sie Azure Netzwerke entwerfen, die sich über mehrere Regionen erstrecken. Ein Multiregion-Netzwerk bietet hohe Verfügbarkeit gegenüber regionalen Ausfällen, dient geografisch verteilten Benutzern mit geringerer Latenz und unterstützt behördliche Datenhaltungsanforderungen.

Inhalt dieses Artikels

In diesem Artikel werden Zonen- und regionale Redundanzen, regionsübergreifende Routingstrategien, Hubtopologieoptionen für Multiregion-Bereitstellungen, aktive und passive Failovermuster und Überlegungen zur Replikationslatenz behandelt.

Wer diesen Artikel benötigt

Lesen Sie diesen Artikel, wenn Ihre Umgebung einer der folgenden Bedingungen entspricht:

  • Ihre Workload erfordert Schutz durch Notfallwiederherstellung gegen den vollständigen Ausfall einer Azure-Region.
  • Sie dienen Benutzern in mehreren Regionen und müssen die Netzwerklatenz minimieren.
  • Gesetzliche oder Complianceanforderungen setzen fest, dass Daten innerhalb bestimmter geografischer Grenzen verbleiben.
  • Ihre Geschäftskontinuitätsziele definieren ein Wiederherstellungszeitziel (Recovery Time Objective, RTO), das eine einzelne Region nicht allein erfüllen kann.

Wenn Ihre Workload in nur einer Region ausgeführt wird und zonenredundante Bereitstellungen Ihre Verfügbarkeitsanforderungen erfüllen, benötigen Sie derzeit möglicherweise noch kein Design für mehrere Regionen. Beginnen Sie mit einer Hub-and-Spoke-Topologie oder Virtual WAN in einer Region, und erweitern Sie sie später.

Lift-and-Shift-Fokus: Legacyworkloads können häufig nicht über Regionen hinweg aktiv-aktiv ausgeführt werden. Planen Sie die Notfallwiederherstellung mit Azure Site Recovery und einem Hub in der Wiederherstellungsregion anstelle eines vollständigen Aktiv/Aktiv-Designs.

Modernisierungsfokus: Stellen Sie kundenorientierte Apps in zwei Regionen mit zonenredundanten SKUs bereit, wobei nicht überlappender Adressraum verwendet wird, damit Regionen bei Bedarf peeren können.

Cloudübergreifender Fokus: Verwenden Sie Azure Virtual WAN, um mehrere Regionen und Filialen zu verbinden, und planen Sie das regionsübergreifende Routing neben Ihrem cloudübergreifenden Transit.

Azure Dienste und Features

In der folgenden Tabelle sind die Azure Dienste und Features aufgeführt, die multiregionsübergreifende Netzwerke ermöglichen:

Dienst oder Feature Rolle im Multiregion-Design Weitere Informationen
Azure Traffic Manager DNS-basiertes Datenverkehrsrouting über Regionen hinweg für jedes Protokoll Übersicht über Traffic Manager
Azure Front Door – der Dienst für Web-Traffic-Management Globale HTTP/HTTPS-Lastverteilung mit CDN und WAF am Netzwerkrand Übersicht zu Front Door
Globales VNet-Peering Private Konnektivität mit hoher Bandbreite zwischen virtuellen Netzwerken in verschiedenen Regionen Peering in virtuellen Netzwerken
Globale ExpressRoute-Reichweite Verbindet lokale Websites über das Azure Backbone miteinander. Globale ExpressRoute-Reichweite
Azure Virtual WAN (Multi-Hub) Microsoft-verwalteter globaler Transit mit automatischem Inter-Hub-Routing Global Transit von Virtual WAN
Azure Virtual Network Manager (AVNM) Automatisiert regionsübergreifende Peeringtopologie und Netzwerkgruppenverwaltung AVNM-Übersicht

Warum mehrere regionenübergreifende Netzwerke erforderlich sind

Ein virtuelles Netzwerk (VNet) umfasst eine einzelne Region. Subnetze innerhalb dieses VNet umfassen alle Verfügbarkeitszonen in der Region, aber das VNet selbst kann sich nicht über Regionsgrenzen erstrecken. Multiregion-Netzwerk bedeutet daher, mehrere VNets, eine oder mehrere pro Region bereitzustellen und sie mit regionsübergreifenden Diensten zu verbinden.

Diagramm einer Aktiv/Aktiv-Topologie mit zwei Regionen, bei der Azure Front Door und WAF den globalen eingehenden Datenverkehr an die Regionen Westeuropa und USA, Osten weiterleiten, die jeweils ein Hub-VNet mit Azure Firewall und Azure Bastion enthalten, das per Peering mit einem Workload-Spoke-VNet verbunden ist, wobei globales VNet-Peering über das Microsoft-Backbone die beiden Regionen miteinander verbindet.

Diese grundlegende Einschränkung formen jedes Multiregion-Design:

  • Jede Region benötigt einen eigenen VNet-Adressraum (nicht überlappend mit anderen Regionen für Peering).
  • Der regionsübergreifende Datenverkehr erfordert einen expliziten Konnektivitätsmechanismus: Globales VNet-Peering, Virtual WAN inter-hub- oder gatewaybasiertes Routing.
  • Globale Lastverteilungsdienste (Traffic Manager oder Front Door) leiten Benutzer an die richtige regionale Bereitstellung weiter.

Informationen zur Subnetz- und Adressplanung finden Sie unter IP-Adressplanung.

Verfügbarkeitszonen im Vergleich zu regionalen Redundanzen

Bevor Sie eine Multiregion-Topologie entwerfen, verstehen Sie die beiden Ebenen der Infrastrukturredundanz in Azure:

Grad Schützt vor Mechanismus Example
Verfügbarkeitszonen Einzelner Rechenzentrumsfehler innerhalb einer Region Physisch getrennte Rechenzentren mit unabhängiger Leistung, Kühlung und Netzwerk zonenredundante Azure Firewall über 3 Zonen hinweg bereitgestellt
Regionale Redundanz Vollständiger Ausfall der Region (Naturkatastrophen, weit verbreiteter Ausfall) Bereitstellen von Workloads in zwei oder mehr Azure Regionen Aktiv-/Aktiv-Webanwendung in „USA, Osten“ und „USA, Westen“

Beginnen Sie mit Zonenredundanz. Zonenredundante Bereitstellungen schützen vor den häufigsten Ausfallszenarien (einzelne Rechenzentrumsprobleme) ohne die Komplexität des Multiregion-Routings. Fügen Sie regionale Redundanz hinzu, wenn Ihr Unternehmen Schutz vor regionsweiten Ausfällen erfordert oder wenn Sie geografisch verteilte Benutzer bedienen müssen.

Referenz zu zonenredundanten Netzwerkdiensten

In der folgenden Tabelle sind zonenredundante Bereitstellungsoptionen für Kernnetzwerkdienste aufgeführt. Stellen Sie diese in jeder Region bereit, in der Sie Workloads ausführen:

Service Zonenredundante Option Hinweise
Azure Firewall Übergreifende Bereitstellung in mehreren Verfügbarkeitszonen Verteilt auf alle drei Zonen in der Region
Standard-Lastenausgleich Zonenredundantes Front-End Standardverhalten für Standard-SKU
Application Gateway v2 Zonenredundante Bereitstellung Erfordert die SKU Standard_v2 oder WAF_v2
VPN Gateway Aktiv/Aktiv mit zonenredundanten SKUs Verwenden Sie AZ-Suffix-SKUs (VpnGw1AZ, VpnGw2AZ usw.)
ExpressRoute-Gateway Zonenredundante SKUs Verwenden Sie ErGw1AZ, ErGw2AZ oder ErGw3AZ
Azure Bastion Zonenredundant (Vorschau) Basic-, Standard- und Premium-SKUs
NAT-Gateway (StandardV2) Zonen-redundant StandardV2-SKU erforderlich; die Standard-SKU ist nur zonenbasiert verfügbar

So wählen Sie einen regionsübergreifenden Datenverkehrsroutingansatz aus

Verwenden Sie die folgende Entscheidungstabelle, um den richtigen Dienst für das Routing des Datenverkehrs zwischen Regionen auszuwählen:

Ihre Anforderung Empfohlener Dienst So funktioniert es
Failover mit mehreren Regionen oder Lastverteilung für jedes Protokoll (HTTP, TCP, UDP) Azure Traffic Manager Gibt die beste Endpunkt-IP durch DNS-Auflösung zurück. Der Client stellt eine direkte Verbindung mit dem Endpunkt bereit. Die Failovergeschwindigkeit hängt von DNS-TTL ab (in der Regel 30 bis 300 Sekunden).
Globaler HTTP/HTTPS-Lastenausgleich mit CDN, WAF und schnellem Failover Azure Front Door – der Dienst für Web-Traffic-Management Beendet Verbindungen an Edge-Points of Presence (PoPs). Leitet Anforderungen an das nächstgelegene fehlerfreie Back-End weiter. Stellt Failover auf Verbindungsebene (Sekunden, nicht DNS-TTL abhängig) bereit.
Privater Back-End-Datenverkehr zwischen Regionen (Replikation, interne APIs) Globales VNet-Peering Verbindet VNets regionsübergreifend über das Microsoft-Backbone. Peering ist nicht transitiv; jede Peering-Beziehung ist explizit. Gebühren pro GB für den Datentransfer fallen an.
Lokale Standort-zu-Standort-Konnektivität über Azure Globale ExpressRoute-Reichweite Verbindet zwei ExpressRoute-Schaltkreise, sodass lokale Standorte über das Microsoft Backbone kommunizieren, ohne Hubrouter zu durchlaufen.

Tip

Kombinieren Sie diese Dienste. Verwenden Sie z. B. Front Door für benutzerorientierten HTTP-Datenverkehr und globalen VNet-Peering für die Back-End-Replikation zwischen Regionen.

So wählen Sie eine Multiregion-Hubtopologie aus

Nachdem Sie sich entschieden haben, Ihr Netzwerk über Regionen hinweg zu erweitern, wählen Sie ein Hubmuster für die Verwaltung der regionsübergreifenden Konnektivität aus:

Faktor Hub pro Region (traditionell) Virtual WAN mit mehreren Hubs
Regionsübergreifende Verbindungen Kunde konfiguriert globales VNet-Peering zwischen regionalen Hubs und verwaltet UDRs. Automatisches Inter-Hub-Routing: Alle Virtual-WAN-Hubs sind standardmäßig miteinander verbunden
Management Vollständige Kundenkontrolle über Routing, Firewallregeln und Peering Microsoft verwaltete Hubinfrastruktur mit richtlinienbasierter Verwaltung
Am besten geeignet für: Organisationen, die granulare Kontrolle über das Routing, benutzerdefinierte NVAs oder bestehende Investitionen in Hub-Infrastrukturen benötigen Unternehmen mit vielen Regionen, mehr als 30 Niederlassungen oder einer Präferenz für verwaltete Infrastruktur
Globaler Transit Erfordert eine explizite Peering- und UDR-Konfiguration zwischen jedem Hubpaar. Integriert: Datenverkehr zwischen beliebigen zwei Hubs wird automatisch weitergeleitet
Scaling Fügen Sie Hubs und Peerings manuell hinzu (AVNM kann dies automatisieren) Hubs über die Virtual-WAN-Konfiguration hinzufügen: Routingupdates erfolgen automatisch
Kostenmodell Hub-VNet-Ressourcen (Firewall, Gateway, Peering) separat abgerechnet Virtual WAN – Preise pro Einheit zuzüglich verbundener Ressourcen

Einen detaillierten Vergleich der Hub-and-Spoke-Topologie und Virtual WAN in einer einzelnen Region finden Sie unter Hub-and-Spoke-Topologie und Virtual WAN.

Überlegungen zum Entwurf

Schwerpunkt auf regionenübergreifendem Lift-and-shift-Design

  • Für Legacy-Workloads, die nicht zonen- oder regionsübergreifend ausgelegt werden können, sollten Sie statt auf Aktiv/Aktiv auf Notfallwiederherstellung setzen: Replizieren Sie sie mit Azure Site Recovery in eine Wiederherstellungsregion.
  • Erstellen Sie einen Hub in der Wiederherstellungsregion, der den primären Hub widerspiegelt, sodass Failoverdatenverkehr dieselben gemeinsamen Dienste aufweist.
  • Verwenden Sie Azure Traffic Manager oder DNS-Failover, um Benutzer während eines regionalen Ausfalls umzuleiten.
  • Sorgen Sie dafür, dass der Adressraum der Wiederherstellungsregion nicht mit der primären Region überlappt, um Konflikte während des Failovers und späterer Peerings zu vermeiden.

Modernisieren des Designfokus für mehrere Regionen

  • Stellen Sie kundenbezogene Workloads im Aktiv/Aktiv-Betrieb über zwei Regionen hinweg mit zonenredundanten SKUs bereit, um ein Höchstmaß an Resilienz zu erreichen.
  • Weisen Sie den primären und den Backupregionen nicht überlappende Adressbereiche zu, damit Aktiv/Aktiv-Spokes später globales VNet-Peering ohne Neuadressierung nutzen können.
  • Wählen Sie Ihre Übermittlungsebene nach App-Typ aus: Azure Front Door für Web-Apps und Traffic Manager für Nicht-Web-Apps, die über regionale öffentliche Endpunkte verteilt werden.
  • Schalten Sie die Hub-Firewall (SNAT und DNAT) vor die öffentlichen Endpunkte jeder Region, sodass eingehender Datenverkehr überprüft wird, bevor er die Back-Ends erreicht.

Fokus auf cloud-übergreifendes, multiregionales Design

  • Verwenden Sie Azure Virtual WAN, um mehrere Azure-Regionen, Niederlassungen und Cloud-Edge-Standorte mit automatischem Any-to-Any-Routing miteinander zu verbinden.
  • Planen Sie zusammengefasste, nicht überlappende Adressbereiche über Regionen und Clouds hinweg, sodass das Transitrouting einfach bleibt.
  • Beenden Sie cloudübergreifende IPsec-Verbindungen auf regionalen gesicherten Hubs, und lassen Sie Virtual WAN Routing zwischen Hubs verarbeiten.
  • Verteilen Sie den öffentlichen eingehenden Datenverkehr mithilfe von Front Door oder Traffic Manager auf mehrere Regionen und behalten Sie die Inspektion bei jeder regionalen Hub-Firewall bei.

Voraussetzungen

Stellen Sie vor dem Entwerfen eines Multiregion-Netzwerks folgendes sicher:

  • Eine Topologie mit einer einzigen Region wurde bereitgestellt und getestet. Beginnen Sie mit hub-and-spoke oder Virtual WAN.
  • Definierte Anforderungen an hohe Verfügbarkeit und Notfallwiederherstellung: RTO, Recovery Point Objective (RPO) und Compliance-Mandate.
  • Erstellt einen nicht überlappenden IP-Adressplan in allen Regionen. Siehe IP-Adressplanung.
  • Ermittelt, welche Workloads nur regionale Redundanz im Vergleich zur Zonenredundanz benötigen.

Aktiv-aktiv und aktiv-passive Bereitstellungsmuster

Ihr Bereitstellungsmodell für mehrere Regionen bestimmt, wie der Datenverkehr im Normalbetrieb und bei einem regionalen Ausfall geleitet wird:

Active-active

Beide Regionen bedienen den Datenverkehr gleichzeitig. Ein globaler Lastenausgleichsdienst wie Traffic Manager oder Front Door verteilt Anfragen anhand der Nähe, der Leistung oder der Gewichtung auf verschiedene Regionen.

Wann Active-Active verwendet wird:

  • Ihre Anwendung kann Anforderungen in jeder Region ohne regionsspezifische Statusabhängigkeiten verarbeiten.
  • Sie benötigen das niedrigstmögliche RTO (das Failover erfolgt sofort, da die funktionsfähige Region den Datenverkehr bereits verarbeitet).
  • Sie möchten kapazität in beiden Regionen während des normalen Betriebs (Kosteneffizienz) nutzen.

Überlegungen zum Netzwerk:

  • Beide Regionen müssen über identische Netzwerkinfrastruktur verfügen, einschließlich Firewalls, Gateways und Lastenausgleichsmodulen.
  • Die Datenreplikation zwischen Regionen muss beide Bereitstellungen auf dem aktuellen Stand halten.
  • DNS-TTL- und Integritätstestintervalle bestimmen, wie schnell der Traffic Manager Datenverkehr verschiebt. Front Door ermöglicht ein schnelleres Failover auf Verbindungsebene.

Active-passive

Eine Region (primär) übernimmt den gesamten Datenverkehr. Die sekundäre Region bleibt bereit, bedient jedoch keine Benutzeranforderungen bis zu einem Failoverereignis.

Wann aktiv-passiv verwendet werden soll:

  • Ihre Anwendung verfügt über strenge Schreibbereichsanforderungen oder kann den Zustand nicht einfach replizieren.
  • Kosteneinschränkungen verhindern, dass die volle Kapazität in zwei Regionen gleichzeitig ausgeführt wird.
  • Ihre RTO-Toleranz berücksichtigt die Zeit, die für die Aktivierung der sekundären Region erforderlich ist.

Überlegungen zum Netzwerk:

  • Die Netzwerkinfrastruktur der passiven Region kann kleinere Ebenen oder reduzierte Kapazität bis zum Failover verwenden.
  • Automatisiertes Failover erfordert Integritätstests mit geeigneten Schwellenwerten (vermeiden Sie Flapping).
  • Testen Sie das Failover regelmäßig. Netzwerkkonfigurationen in der passiven Region können abweichen, wenn sie nicht validiert werden.
  • Halten Sie Routentabellen und NSG-Regeln zwischen Regionen synchronisiert. Verwenden Sie Infrastruktur-as-Code-Vorlagen, um sicherzustellen, dass die passive Region dem Sicherheitsstatus der primären Region entspricht.
  • Stellen Sie VPN- oder ExpressRoute-Gateways in der passiven Region vorab bereit. Die Gatewaybereitstellung kann 20 bis 45 Minuten dauern. Das ist für die meisten RTO-Ziele zu langsam.

Auswahl zwischen Active-Active- und Active-Passive-Netzwerkkonfigurationen

Die Wahl zwischen aktivem und aktivem passivem Netzwerk wirkt sich auf die Größenanpassung, Kosten und betriebstechnische Komplexität des Netzwerks aus:

Consideration Active-active Active-passive
Netzwerkkapazität Volle Kapazität in beiden Regionen Reduzierte Kapazität in passiver Region (Skalierung beim Failover)
Gatewaybereitstellung Immer in beiden Regionen eingeschaltet Vorab bereitgestellt, kann jedoch kleinere Ebenen verwenden
Regionsübergreifende Datensynchronisierung Kontinuierlicher, bidirektionaler Replikationsverkehr Unidirektionale asynchrone Replikation im Standbymodus
Firewallregeln Identische Regelsätze, beide aktiv erzwungen Identische Regelsätze, aber das passive Set wird selten verwendet
IP-Adressierung Beide Regionen kündigen sich bei einem globalen Load Balancer an Nur primäre Region kündigt bis zum Failover an
Operatives Risiko Unten: Beide Pfade werden kontinuierlich ausgeübt Höher: Passiver Pfad kann driften oder nicht getestete Konfigurationen aufweisen

Datenreplikation und Latenz

Die regionsübergreifende Replikation führt zu Netzwerklatenz, die sich auf den Anwendungsentwurf auswirkt. Azure-Regionen innerhalb derselben Geografie weisen in der Regel eine Round-Trip-Latenz von 1–10 ms für nahe beieinander liegende Regionspaare (z. B. East US zu East US 2) und von 30–70 ms für weit voneinander entfernte Regionspaare (z. B. East US zu West US) auf. Transatlantische oder transpazifische Regionspaare können 100 ms überschreiten.

Wichtige Entwurfsüberlegungen:

  • Replikationstopologie: Wählen Sie die synchrone Replikation nur für Regionspaare mit geringer Latenz (< 10 ms) aus. Verwenden Sie die asynchrone Replikation für entfernte Paare, um eine Beeinträchtigung der Anwendungsleistung zu vermeiden.
  • Bandbreitenplanung: Schätzen Sie die Anforderungen des Replikationsdurchsatzes, und berücksichtigen Sie die Kosten für die globale VNet-Peering-Datenübertragung pro GB. Große Replikationsvolumen zwischen weit voneinander entfernten Regionen können erhebliche Gebühren für ausgehenden Datenverkehr verursachen.
  • Konfliktlösung: Aktive Muster mit bidirektionalen Schreibvorgängen erfordern Konfliktlösungsstrategien auf der Anwendungs- oder Datenbankebene. Das Netzwerk bietet Konnektivität, aber Anwendungen müssen Schreibkonflikte behandeln.
  • Private Endpunkte für paaS-Replikation: Verwenden Sie beim Replizieren von Azure SQL, Cosmos DB oder Storage über Regionen hinweg private Endpunkte in jeder Region, um den Replikationsverkehr auf dem Microsoft Backbone beizubehalten und öffentliche Internetexposition zu vermeiden.

Kostenaspekte

Multiregion-Netzwerke erhöhen die Kosten durch doppelte Infrastruktur und regionsübergreifende Datenübertragung. Planen Sie Ihr Budget für diese primären Kostentreiber:

  • Regionsübergreifende Datenübertragung: Für Global VNet Peering und den Virtual WAN-Inter-Hub-Datenverkehr werden pro GB Gebühren berechnet, wenn Daten Regionsgrenzen überschreiten. Der Datenverkehr innerhalb einer Region zwischen per Peering verbundenen VNets in derselben Region verursacht innerhalb derselben Zone keine zusätzlichen Kosten und wird für zonenübergreifenden Datenverkehr zu einem niedrigeren Tarif berechnet.
  • Duplizierte Netzwerkgeräte: Jede Region erfordert eine eigene Firewall, einen Lastenausgleich und Gatewayinstanzen. Aktiv/Aktiv-Bereitstellungen verdoppeln diese Kosten. Aktiv/Passiv-Bereitstellungen können Kosten senken, indem in der Standby-Region kleinere Leistungsstufen genutzt und diese beim Failover hochskaliert werden.
  • Gebühren für den globalen Lastenausgleich: Sowohl Traffic Manager als auch Front Door berechnen Gebühren auf Grundlage von DNS-Abfragen oder verarbeiteten Anfragen. Front Door berechnet zusätzlich Gebühren für die Datenübertragung von Edge-PoPs an Backends.
  • ExpressRoute und VPN Gateway: Multiregion-Designs erfordern häufig Gatewayinstanzen in jeder Region. ExpressRoute-Schaltkreise, die mehrere Regionen verbinden, fügen monatliche Portgebühren und getaktete Datengebühren pro GB hinzu.
  • Optimieren mit Datenverkehrslokalität: Entwerfen Sie Anwendungsebenen, um regionsübergreifende Aufrufe zu minimieren. Platzieren Sie Lesereplikate in jeder Region gemeinsam mit den Rechenressourcen, um die für die Replikation erforderliche Bandbreite zu reduzieren und latenzempfindliche Abfragen zu unterstützen.

Sicherheitsüberlegungen

Ein regionenübergreifendes Netzwerk bringt Sicherheitsaspekte mit sich, die über Single-Region-Bereitstellungen hinausgehen:

  • Der Datenverkehr bleibt auf dem Microsoft Backbone. Der gesamte regionsübergreifende Datenverkehr über Global VNet Peering oder Virtual WAN Inter-Hub-Konnektivität durchläuft das Microsoft-Backbone-Netzwerk, nicht das öffentliche Internet.
  • Stellen Sie zonenredundante Firewalls in jeder Region bereit. Jeder regionale Hub benötigt eine eigene Firewallinstanz für die Datenverkehrsüberprüfung. Stellen Sie Firewalls über mehrere Verfügbarkeitszonen hinweg bereit, um die Sicherheit auch bei Ausfällen einzelner Zonen aufrechtzuerhalten.
  • Front Door WAF bietet Sicherheit am Netzwerkrand. Wenn Sie Front Door verwenden, prüft die integrierte Web Application Firewall den Datenverkehr, bevor sie eine regionale Bereitstellung erreicht. Dies bietet eine erste Verteidigungsebene am Netzwerkrand.
  • Planen Sie das DNS-Failover sorgfältig. Das Failover von Traffic Manager hängt von DNS-TTL ab. Kürzere TTLs ermöglichen ein schnelleres Failover, erhöhen aber das DNS-Abfragevolumen. Front Door bietet Failover auf Verbindungsebene, das nicht vom Ablauf des Client-DNS-Caches abhängt.
  • ExpressRoute Global Reach-Datenverkehr bleibt privat. Der Datenverkehr zwischen lokalen Websites, die über globale Reichweite verbunden sind, berührt niemals das öffentliche Internet. Es bleibt auf dem Microsoft Backbone zwischen Schaltkreisen.
  • Sichere regionsübergreifende Replikationskanäle. Back-End-Replikationsdatenverkehr über globales VNet-Peering ist standardmäßig privat; für vertrauliche Daten während der Übertragung sollten jedoch Netzwerksicherheitsgruppen und Verschlüsselung angewendet werden.

Wenn Ihr Multiregion-Design bestimmte Szenarien umfasst, die an anderer Stelle in diesem Handbuch behandelt werden, lesen Sie:

Weitere Informationen

Weitere Informationen zu den in diesem Artikel erläuterten Diensten und Konzepten finden Sie in den folgenden Ressourcen:

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:

Stellen Sie eine Verbindung mit Ihrem lokalen Netzwerk her: Nachdem Sie die Notfallwiederherstellung geplant haben, richten Sie VPN- oder ExpressRoute-Konnektivität mit lokalem Netzwerk ein.

Als Nächstes in Ihrer Modernisierungsreise:

Entwerfen Sie Ihre Interneteingangsmuster: Bestimmen Sie, wie der Kundendatenverkehr Ihre Anwendungen in Ihren primären und Sicherungsregionen erreicht.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Richten Sie verschlüsselte Tunnel für Ihre anderen Clouds ein: Konfigurieren Sie nach der Multiregion-Planung die cloudübergreifende VPN-Konnektivität.

  • Last updated on