Cloudübergreifender Netzwerkentwurfspfad

Dieser Leitfaden bietet einen sequenzierten Lesepfad über den Azure Netzwerkentwurfsleitfaden für Kunden, die Azure mit Amazon Web Services (AWS), Google Cloud verbinden oder Workloads von einem anderen Cloudanbieter migrieren. Führen Sie die nummerierten Schritte aus, um sichere, überwachte Konnektivität zwischen Azure und Ihrer vorhandenen Cloudinfrastruktur zu entwerfen.

Warum die Entdeckung zuerst kommt

Cloudübergreifende Netzwerke verbinden Azure mit einer oder mehreren externen Cloudumgebungen. Sie können Workloads in AWS oder Google Cloud ausführen, die private Konnektivität zu Azure-Diensten benötigen, oder Sie können Anwendungen aus einer anderen Cloud in Azure migrieren und gleichzeitig die Verbindung zu Anwendungen beibehalten, die zurückbleiben. Auf beide Weise muss Ihr Azure Netzwerk in die Infrastruktur integriert werden, die Sie auf der anderen Seite nicht vollständig steuern.

Dieser Lesepfad beginnt mit einer Einführung statt mit dem Azure-Infrastrukturdesign. Sie erfassen zunächst Ihre vorhandene Multicloud-Topologie (um zu verstehen, welche Workloads wo ausgeführt werden, wie alles miteinander verbunden ist und welcher Datenverkehr zwischen den Clouds fließt), bevor Sie die Azure-Seite konzipieren. Dieser Ermittlungsansatz verhindert Überarbeitungen: Wenn Sie Azure Netzwerk entwerfen, ohne Ihre AWS- oder Google Cloud-Topologie zu verstehen, riskieren Sie IP-Adresskonflikte, Konnektivitätslücken und Sicherheitsblindpunkte.

Ihre Zielarchitektur verwendet Azure Virtual Wide Area Network (WAN) als Transit-Hub (das Azure Äquivalent des AWS Transit Gateways) mit IPSec-VPN-Tunneln zu AWS Virtual Private Gateway und Google Cloud VPN. Azure Firewall in einem sicheren virtuellen Hub überprüft den gesamten cloudübergreifenden und zweigübergreifenden Datenverkehr. DNS erfordert eine sorgfältige Cutover-Planung, damit die Namensauflösung während der Migration über Cloud-Grenzen hinweg weiterhin funktioniert.

Voraussetzungen

  • Lesen Sie die Übersicht zur Planung und zum Entwurf von Azure-Netzwerken zur Orientierung über die verfügbaren Azure-Netzwerkdienste.
  • Vollständige Topologieermittlung Ihrer AWS- und Google Cloud-Umgebungen:
    • AWS: Führen Sie AWS Migration Hub oder Workload Discovery auf AWS aus, um Virtual Private Clouds (VPCs), Transitgateways und inter-RPC-Konnektivität zu inventarisieren.
    • Google Cloud: Verwenden Sie das Network Intelligence Center, um VPC-Netzwerke, Cloud Interconnect-Anhänge und Firewallregeln abzubilden.
  • Dokumentieren Sie cloudübergreifende Datenverkehrsflüsse: welche Anwendungen zwischen Clouds kommunizieren, erforderliche Bandbreite, Latenzempfindlichkeit und Verschlüsselungsanforderungen.
  • Erstellen Sie einen Bestand an IP-Adressbereichen in allen drei Clouds, um Überlappungen zu identifizieren.

Ihr Lesepfad

Die folgenden Phasen führen Sie durch das cloudübergreifende Netzwerkdesign in Sequenz.

Phase 1: Ermittlung

Beginnen Sie mit der Ermittlung. Verstehen Sie Ihre Mehrcloudlandschaft, bevor Sie Azure Infrastruktur entwerfen.

1. Regionsübergreifende und Multicloudkonnektivität

Dieser Artikel ist Ihr zentraler Entscheidungspunkt für den Entwurf. Erfassen Sie Ihre Multicloud-Topologie: welche AWS-VPCs und Google-Cloud-VPCs eine Verbindung mit Azure benötigen, welcher Datenverkehr zwischen den Clouds fließt und welches Architekturmuster zu Ihrer Größenordnung passt. Verwenden Sie die Dienstzuordnung zwischen Cloudanbietern (Transit Gateway zu Virtual WAN, Sicherheitsgruppen zu Netzwerksicherheitsgruppen, VPC-Peering zu VNet-Peering), um Ihr vorhandenes Design in Azure-Begriffe zu übersetzen.

2. Azure Virtual WAN

Virtual WAN ist das empfohlene Transitmodell, wenn Sie über mehrere VPCs, Zweigstellen, Regionen oder Cloud-Edges verfügen. Virtual WAN bietet das Azure-Äquivalent von AWS Transit Gateway: automatisiertes Routing, zentrale Sicherheit und Skalierung über mehrere Niederlassungen und Regionen hinweg. Bewerten Sie, ob Ihre cloudübergreifende IT-Landschaft den Einsatz von Virtual WAN rechtfertigt oder ob eine einfachere Hub-Spoke-Architektur mit VPN Gateway ausreichend ist.

Phase 2: Grundlagen

3. Virtuelle Netzwerke und Subnetze

Entwerfen Sie Ihr Azure VNet als Zielzone für migrierte oder verbundene Workloads. Zuordnung von AWS-VPC- und Google-Cloud-VPC-Konzepten: VPC-Subnetze werden zu Azure-Subnetzen, Verfügbarkeitszonen werden Azure-Verfügbarkeitszonen zugeordnet und Routentabellen folgen ähnlichen Mustern. Konzentrieren Sie sich auf die Subnetzgröße für die Workloads, die in Azure landen.

4. IP-Adressplanung

Planen Sie einen sich nicht überschneidenden Adressraum über alle drei Clouds hinweg. Dieser Schritt ist für die cloudübergreifende Konnektivität von entscheidender Bedeutung: Wenn sich Ihre Azure-VNet-Bereiche mit den AWS-VPC-Bereichen oder den Google-Cloud-VPC-Bereichen überschneiden, können Sie keine VPN-Tunnel zwischen ihnen herstellen. Dokumentieren Sie jeden CIDR-Block, der in allen Umgebungen verwendet wird, bevor Sie Azure Adressraum zuordnen.

5. Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen

Spiegeln Sie Ihre AWS-Sicherheitsgruppen und Google Cloud-Firewallregeln als Azure Netzwerksicherheitsgruppen (Network Security Groups, NSGs) wieder. Übersetzen Sie Ihre vorhandenen Zulassungs- und Ablehnungsregeln in das NSG-Format. Verwenden Sie Anwendungssicherheitsgruppen (APPLICATION Security Groups, ASGs), um die tagbasierte Gruppierung zu replizieren, die AWS Security Group-Verweise bereitstellen.

Phase 3: Konnektivität

6. Hybridkonnektivität

Richten Sie IPSec-VPN-Tunnel zwischen Azure und AWS oder Google Cloud für die verschlüsselte cloudübergreifende Übertragung ein. Verbinden Sie Azure VPN Gateway (oder Virtual WAN VPN-Verbindungen) mit AWS Virtual Private Gateway und Google Cloud VPN. Wählen Sie die Tunnelbandbreite basierend auf Ihren anforderungen für den cloudübergreifenden Datenverkehr aus. Planen Sie redundante Tunnel, um einzelne Fehlerpunkte zu vermeiden.

Phase 4: Sicherheit

7. DNS-Sicherheit und Auflösung privater Namen

Planen Sie Ihre Strategie für die DNS-Umstellung, bevor Sie Workloads migrieren. Anwendungen in AWS oder Google Cloud lösen Hostnamen auf, die nach der Migration möglicherweise auf Azure verweisen müssen. Konfigurieren Sie Azure DNS Private Resolver mit Outbound-Endpunkten für die cloudübergreifende Namensauflösung. Eine schrittweise Anleitung zur Migration finden Sie in der DNS-Übernahmeprüfliste weiter unten in diesem Artikel.

8. Azure Firewall

Stellen Sie Azure Firewall in einem sicheren virtuellen Hub bereit, um den gesamten cloudübergreifenden und zweigübergreifenden Datenverkehr zu prüfen. Jedes Paket, das zwischen Azure und AWS oder Google Cloud durchläuft, durchläuft die Firewall zur Protokollierung und Richtlinienerzwingung. Verwenden Sie Netzwerkregeln für cloudübergreifende Datenverkehrsmuster und Bedrohungserkennungsfilter, um bekannte schädliche Ziele zu blockieren.

Phase 5: Vorgänge

9. Netzwerküberwachung und Beobachtbarkeit

Cloudübergreifende Umgebungen sind schwieriger zu diagnostizieren, da Sie nicht beide Enden jeder Verbindung kontrollieren. Aktivieren Sie Azure Network Watcher für Konnektivitätstests, VPN-Tunneldiagnose und Paketerfassung. Überwachen Sie die Tunnel-Betriebszeit, die Latenz zwischen Clouds und den Durchsatz anhand Ihrer Kapazitätsanforderungen. Legen Sie Warnungen für Tunneltrennungen fest, die sich auf die Verfügbarkeit von cloudübergreifenden Anwendungen auswirken.

Bedingte Artikel

Fügen Sie diese Artikel basierend auf Ihren spezifischen Anforderungen ein:

Zustand Artikel Wann einbeziehen
Öffentlich zugängliche Anwendung Interneteingang Ihre migrierte Anwendung ist internetgeschützt (direkter öffentlicher Zugriff erforderlich)
HTTP/HTTPS-Anwendung Web Application Firewall Layer 7 WAF ist für öffentlich zugängliche Webanwendungen erforderlich
Layer 7-Verteilung erforderlich Anwendungsbereitstellung und -leistung Nach der Migration benötigen Sie eine globale oder regionale Datenverkehrsverteilung.
Öffentliche Endpunkte DDoS-Schutz Sie haben Anforderungen an die Verfügbarkeit öffentlich zugänglicher Dienste.
Hub-and-Spoke bevorzugt Hub-and-Spoke-Topologie Ihre cloudübergreifende Infrastruktur ist klein genug, dass Virtual WAN nicht gerechtfertigt ist.
Azure mit mehreren Regionen Netzwerk mit mehreren Regionen Ihr Azure Ziel umfasst mehrere Regionen über die cloudübergreifende Konnektivität hinaus
VM-Administratorzugriff Entwickler- und Administratorzugriff Sie benötigen sicheren RDP/SSH-Zugriff auf Azure gehostete VMs
Zentralisierter Ausgang Ausgehender Internetzugriff Die Richtlinie für den zentralen Internetzugang ist Teil Ihres Zieldesigns.
Großer VNet-Besitz Zentrale Netzwerkverwaltung Die Azure-Umgebung entwickelt sich zu einer zentral verwalteten Umgebung mit mehreren Abonnements
Private PaaS-Endpunkte Privater PaaS-Zugriff Ihre Zielarchitektur umfasst Azure PaaS-Dienste mit privaten Endpunkten

Prüfliste für cloudübergreifende Ermittlung

Bevor Sie Ihre Azure-Netzwerkinfrastruktur konzipieren, ordnen Sie Ihre vorhandenen Clouddienste den entsprechenden Azure-Diensten zu. Diese Zuordnung beschleunigt Entwurfsentscheidungen und verhindert nicht übereinstimmende Erwartungen.

Zuordnung von AWS- zu Azure-Diensten

AWS-Dienst Azure-Äquivalent Hinweise
Transit-Gateway Azure Virtual WAN Zentraler Routing-Hub für Multi-VPC-, Multiregion- und Multicloud-Umgebungen
VPC Virtuelles Azure-Netzwerk Isolierte Netzwerkgrenze mit Subnetzen und Routentabellen
VPC-Peering VNet-Peering Direkte Konnektivität zwischen zwei virtuellen Netzwerken
Sicherheitsgruppen Netzwerksicherheitsgruppen (NSGs) Zustandsbasierte Datenverkehrsfilterung auf Subnetz- oder Netzwerkschnittstellenebene
Netzwerk-ACLs NSGs (Subnetzebene) Azure NSGs kombinieren sowohl Sicherheitsgruppen- als auch NACL-Funktionen
Virtuelles privates Netzwerk-Gateway VPN Gateway IPSec VPN-Endpunkt
Direkte Verbindung Azure ExpressRoute Dedizierte private Konnektivität (nicht über öffentliches Internet)
Route 53 private gehostete Zonen Privates DNS-Zonen in Azure Privates DNS Namensauflösung in virtuellen Netzwerken
Routingtabellen Benutzerdefinierte Routen (UDRs) Benutzerdefiniertes Routing zum Überschreiben von Azure-Systemrouten oder impliziten AWS-Routen
Elastic Load Balancer (ALB/NLB) Azure Load Balancer/ Anwendungsgateway L4- und L7-Lastenausgleich; Application Gateway bietet WAF-Funktionen ähnlich wie AWS ALB mit AWS WAF
AWS WAF Azure-Webanwendungsfirewall Layer 7 HTTP/HTTPS-Schutz
Netzwerkfirewall Azure Firewall Zustandsbehaftete Netzwerkfirewall mit Bedrohungserkennung

Zuordnung von Google-Cloud-Diensten zu Azure-Diensten

Google Clouddienst Azure-Äquivalent Hinweise
VPC-Netzwerk Virtuelles Azure-Netzwerk Globale Ressource in Google Cloud; regional in Azure (VNet-Peering für regionenübergreifendes Verwenden)
Cloud-Verbindung Azure ExpressRoute Dedizierte private Konnektivität
Cloud-VPN VPN Gateway IPSec-VPN-Tunnel
Cloud NAT Azure NAT Gateway Ausgehender Internetzugriff für private Ressourcen
Cloudrouter Azure Route Server Dynamischer BGP-Routenaustausch mit virtuellen Netzwerkgeräten
Cloud-Rüstung Azure-Webanwendungsfirewall Layer 7 DDoS und Anwendungsschutz
Firewall-Regeln Netzwerksicherheitsgruppen Datenverkehrsfilterung (Google Cloud-Regeln sind global; Azure-NSGs gelten pro Subnetz oder pro NIC)
Private Cloud-DNS-Zonen Privates DNS-Zonen in Azure Auflösung privater Namen in Netzwerken
Zentrum für Netzwerkintelligenz Azure Network Watcher Netzwerküberwachung, Diagnose und Topologievisualisierung

Checkliste für die DNS-Umschaltung

Die DNS-Umschaltung ist der Schritt mit dem höchsten Risiko bei der cloudübergreifenden Migration. Befolgen Sie diese Checkliste, um Lösungsfehler während des Übergangs zu minimieren.

Vor der Migration

  1. Lower Time to Live (TTL)-Werte für alle DNS-Einträge, die sich ändern. Stellen Sie TTL mindestens 48 Stunden vor der Umschaltung auf 60–300 Sekunden ein. Dieser Schritt stellt sicher, dass Caches schnell ablaufen, wenn Sie Datensätze aktualisieren.
  2. Dokumentieren Sie jeden DNS-Record, der auf die Infrastruktur verweist, die Sie migrieren: A-Records für Server, CNAME-Records für Dienste, MX-Records für E-Mail und SRV-Records für die Diensterkennung.
  3. Konfigurieren Sie Azure DNS Private Resolver mit Outbound-Endpunkten in Ihrem Azure VNet. Dieser Resolver leitet Abfragen für AWS/Google Cloud gehostete Zonen während des Koexistenzzeitraums an die entsprechenden upstream-DNS-Server weiter.
  4. Testen Sie die Vorwärts- und Rückwärtsauflösung von Azure-VNets zu in AWS/Google Cloud gehosteten Namen, bevor Sie Workloads migrieren.

Während der Migration

  1. Aktualisieren Sie CNAME-Einträge für Dienste, die zu Azure wechseln. Verweisen Sie CNAMEs auf Endpunkte von Azure Front Door, Azure Traffic Manager oder Azure Application Gateway, während die einzelnen Dienste migriert werden.
  2. Aktualisieren Von Host A-Einträgen für einzelne Server, die migriert werden. Ersetzen Sie die AWS- oder Google Cloud-IP-Adressen durch Azure private IP-Adressen in Ihren DNS-Zonen.
  3. Halten Sie die bedingte Weiterleitung aktiv, damit Namen in Zonen, die Sie noch nicht migriert haben, weiterhin über die DNS-Server des ursprünglichen Cloud-Anbieters aufgelöst werden.

Nach der Migration

  1. Überprüfen Sie die Auflösung von allen Standorten: lokale Clients, Azure VNets und alle verbleibenden AWS- oder Google Cloud-Workloads müssen alle migrierten Namen ordnungsgemäß auflösen.
  2. Erhöhen Sie TTL-Werte wieder auf Produktionsniveaus (3.600 Sekunden oder höher), nachdem Sie die stabile Auflösung bestätigt haben.
  3. Entfernen Sie bedingte Weiterleitungen für Zonen, die vollständig zu Azure DNS migriert werden. Behalten Sie Weiterleitungen nur für Zonen bei, die in AWS oder Google Cloud verbleiben.

Was Sie erstellt haben

Indem Sie diesem Lesepfad folgen, haben Sie Azure mit Ihrer vorhandenen AWS- oder Google Cloud-Umgebung mit verschlüsselter Übertragung, zentralisierter Firewall-Inspektion und überwachter Konnektivität verbunden. Ihr Design umfasst:

  • Multicloudtopologieermittlung und Dienstzuordnung
  • Virtual WAN oder eine Hub-and-Spoke-Transitarchitektur
  • IPSec VPN-Tunnel zu AWS und Google Cloud
  • Azure Firewall für die cloudübergreifende Datenverkehrsüberprüfung
  • DNS-Umstellung mit Private Resolver für die cloudübergreifende Namensauflösung
  • Überwachung des Tunnelzustands und der Leistung mit Network Watcher

Nächste Schritte

  • Last updated on