Migrieren und Modernisieren des Netzwerkentwurfspfads

Dieses Handbuch bietet einen sequenzierten Lesepfad über den Azure Netzwerkentwurfsleitfaden für Kunden, die PaaS-Dienste, Container und verwaltete Datenbanken einführen. Führen Sie die nummerierten Schritte aus, um ein mehrregioniges, sicherheitsschichtiges Netzwerk zu erstellen, das moderne Anwendungsarchitekturen unterstützt.

Overview

Migrations- und Modernisierungsprojekte gehen über virtuelle Maschinen hinaus und umfassen Azure-native Dienste: Azure Kubernetes Service (AKS) für Container, Azure App Service für Webanwendungen, Azure SQL-Datenbank und Azure Cosmos DB für verwaltete Datenbanken sowie Azure Front Door für die globale Verteilung des Datenverkehrs. Ihr Netzwerk muss private Konnektivität zu diesen PaaS-Diensten, mehrregionaktiven Bereitstellungen und einer strengen Sicherheitssegmentierung zwischen Anwendungsebenen unterstützen.

Ihre Zielarchitektur verwendet eine Dual-Hub-Topologie, die zwei Azure Regionen umfasst. VNets von IT-verwalteten Hubs beherbergen gemeinsam genutzte Dienste wie Azure Firewall und VPN Gateway. Anwendungsteams verantworten ihre Spoke-VNets und kontrollieren ihre eigenen Private-Link-Subnetze für die PaaS-Konnektivität. Der Datenverkehr gelangt über Azure Front Door oder Azure Traffic Manager, wird durch die Hub-Firewall geprüft und erreicht Anwendungsdienste, die in isolierten Spokes ausgeführt werden.

Dieser Lesepfad führt Sie durch 14 wesentliche Artikel in fünf Phasen. Der Weg ist länger als bei Lift and Shift, da moderne Architekturen Entscheidungen über Muster für eingehenden Datenverkehr, private PaaS-Anbindung, Web Application Firewalls und DDoS-Schutz erfordern, die bei reinen IaaS-Entwürfen aufgeschoben werden können. Mit zwei Meilensteinprüfpunkten können Sie ermitteln, wann Sie fortfahren können, wenn Ihre Workload nicht alle Komponenten benötigt.

Voraussetzungen

  • Lesen Sie die Übersicht zur Planung und zum Entwurf von Azure-Netzwerken zur Orientierung über die verfügbaren Dienste.
  • Wissen Sie, auf welche PaaS-Dienste Ihre Anwendungen abzielen (AKS, App Service, Azure SQL, Azure Cosmos DB oder andere).
  • Ermitteln Sie, ob sich Ihre Bereitstellung über mehrere Azure-Regionen erstreckt (Aktiv-Aktiv oder Aktiv-Passiv).
  • Identifizieren Sie Ihr Eingangsmuster: Dient Ihre Anwendung öffentlichem Webdatenverkehr, mobilem API-Datenverkehr oder nur internem Datenverkehr?

Ihr Lesepfad

Phase 1: Stiftungen

1. Virtuelle Netzwerke und Subnetze

Dimensionieren Sie Ihre Subnetze für AKS-Knotenpools, für App Service-Umgebung (ASE) delegierte Subnetze und Private Link-Subnetze. Wenn Sie AKS Container Networking Interface (CNI)-Überlagerung verwenden, stammen pod-IP-Adressen aus einem separaten Überlagerungs-CIDR und verbrauchen keinen VNet-Subnetzraum. Nur Knoten-IPs erfordern Subnetzadressen. Planen Sie Ihren Overlay-CIDR-Bereich so, dass er die Skalierung der Pods unterstützt, und weisen Sie für jeden Diensttyp dedizierte Subnetze zu.

2. IP-Adressplanung

Planen Sie die IP-Zuweisung über zwei Regionen hinweg für eine Aktiv/Aktiv-Bereitstellung. Ihre primären und Sicherungsregionen benötigen nicht überlappende Adressräume, die VNet-Peering und regionsübergreifende Replikation unterstützen. Weisen Sie große Bereiche zu, um zukünftige Spoke-Zusätze aufzunehmen.

3. Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen

Konzipieren Sie eine strikte Segmentierung, damit nur der Datenverkehr des Load Balancers die Anwendungs-Subnetze erreicht. Blockieren Sie den direkten Internetzugriff auf Anwendungsschichten. Verwenden Sie Anwendungssicherheitsgruppen (APPLICATION Security Groups, ASGs), um Regeln basierend auf der Workloadrolle anstelle einzelner IP-Adressen anzuwenden.

Phase 2: Topologie

4. Hub-and-Spoke-Topologie

Stellen Sie eine Dual-Hub-Topologie für mehrere Regionen bereit. Das IT-Abonnement besitzt sowohl Hub-VNets als auch verwaltet gemeinsame Dienste wie Azure Firewall, VPN Gateway und DNS-Weiterleitungen. Anwendungsteams sind für ihre Spoke-VNets verantwortlich und verwalten Private-Link-Subnetze, AKS-Cluster und Anwendungsressourcen innerhalb ihres zugewiesenen Adressraums.

5. Netzwerk mit mehreren Regionen

Entwerfen Sie eine aktive Bereitstellung in primären und Backupregionen. Konfigurieren Sie regionsübergreifendes VNet-Peering zwischen Hubs, richten Sie Failoverrouting ein, und planen Sie den Ausfall einer Region. Beide Regionen bedienen gleichzeitig den Datenverkehr, wobei Azure Front Door Anfragen basierend auf Latenz und Integritätstests verteilt.

Note

Meilenstein: Topologie abgeschlossen. Ihre duale Hub-, Multiregion-Topologie ist vorhanden. Wenn Ihre Anwendung nur intern ohne ins Internet zugängliche Endpunkte ist, können Sie mit Schritt 9 (ausgehender Internetzugriff) fortfahren und von dort aus fortfahren.

Was Sie überspringen: Die Schritte 6–8 decken den Interneteingang, die Anwendungsbereitstellung und -leistung sowie den privaten PaaS-Zugriff ab. Das Überspringen ist sicher, wenn Ihre Workload keine öffentlich zugänglichen Endpunkte und keine Private Link Anforderungen aufweist.

Wichtig: Selbst interne Anwendungen benötigen häufig Private Link (Schritt 8), wenn sie eine Verbindung mit Azure SQL, Azure Storage, Azure Key Vault oder anderen PaaS-Diensten über private Endpunkte herstellen. Wenn Ihre Anwendung einen dieser Dienste verwendet, führen Sie Schritt 8 aus, bevor Sie zu Schritt 9 wechseln.

Verbleibende Artikel: Sechs Artikel nach dem Überspringen (Schritte 9–14) im Vergleich zu neun Artikeln ohne Überspringen (Schritte 6–14).

Phase 3: Konnektivität

6. Interneteingang

Die Muster des kundenseitigen Datenverkehrs bestimmen die äußere Gestalt Ihrer Architektur. Verwenden Sie Azure Front Door für Webanwendungen, die globalen Lastenausgleich, Zwischenspeicherung und Web Application Firewall (WAF) benötigen. Verwenden Sie Azure Traffic Manager für mobile oder API-Anwendungen, bei denen DNS-basiertes Routing mit Integritätssonden ausreichend ist.

7. Übermittlung und Leistung der Anwendung

Wählen Sie basierend auf Ihrem Anwendungstyp zwischen Azure Front Door und Azure Traffic Manager. Webanwendungen profitieren von front Door Layer 7-Funktionen: TLS Offload, Caching, URL-basiertes Routing und integrierte WAF. Mobile und API-Back-Ends verwenden Traffic Manager für Failover auf DNS-Ebene mit geringerem Mehraufwand.

8. Privater Zugang zu PaaS

Erstellen Sie Private Link Subnetze in den einzelnen Speichen-VNet für PaaS-Dienstkonnektivität. Anwendungsteams verwalten ihre eigenen privaten Endpunkte: AKS ruft Containerimages über Private Link ab, Web-Apps stellen eine Verbindung mit Azure SQL über private Endpunkte her, und kein PaaS-Datenverkehr durchläuft das öffentliche Internet. Für jede Spoke ein eigenes Subnetz für Private-Link-Ressourcen vorsehen.

Note

Meilenstein: Konnektivität abgeschlossen. Ihre Eingangs- und private PaaS-Konnektivität sind konfiguriert.

Verbleibende Schritte: Ausgehender Ausgang (Schritt 9), Azure Firewall (Schritt 10), Web Application Firewall (Schritt 11), DDoS-Schutz (Schritt 12), DNS-Sicherheit (Schritt 13) und Netzwerküberwachung (Schritt 14) für 6 Artikel insgesamt.

Unverzichtbar für alle Bereitstellungen: Die Schritte 9–10 (ausgehender Datenverkehr und Azure Firewall) gelten für jede Modernisierungsbereitstellung. Ihre Hubfirewall steuert den gesamten ausgehenden Datenverkehr und stellt eine zentrale Überprüfung bereit, unabhängig davon, ob Ihre Workload öffentlich zugänglich oder nur intern ist.

Nur öffentliche Endpunkte: Die Schritte 11–12 (WAF- und DDoS-Schutz) gelten nur, wenn Ihre Anwendung öffentlich zugängliche Endpunkte über Azure Front Door, Anwendungsgateway oder eine öffentliche Load Balancer verfügbar macht. Nur interne Workloads können diese beiden Artikel überspringen und mit Schritt 13 (DNS-Sicherheit) fortfahren.

9. Ausgehender Internetzugriff

Leiten Sie den gesamten ausgehenden Datenverkehr aus den Spokes mithilfe von benutzerdefinierten Routen (UDRs) an die Firewall des Hubs weiter. Die Hubfirewall fungiert als SNAT-Punkt (Source Network Address Translation) für alle Ausgangspunkte. Die IT verwaltet die Firewallregeln zentral, sodass Anwendungsteams keine ausgehenden Steuerelemente umgehen können.

Phase 4: Sicherheit

10. Azure Firewall

Konfigurieren Sie Azure Firewall in beiden Hub-VNets als SNAT- und Destination Network Address Translation (DNAT)-Punkt. Der gesamte Eingehende Datenverkehr durchläuft die Firewall, bevor er die Anwendungsebene erreicht. Verwenden Sie Firewallrichtlinien, um den Ost-West-Datenverkehr zwischen Speichen und Nord-Süd-Datenverkehr zum Internet zu steuern.

11. Web Application Firewall

Stellen Sie WAF auf Azure Front Door oder Azure Application Gateway für Ihre Webanwendungen bereit. WAF schützt vor den Open Web Application Security Project (OWASP) Top-10-Bedrohungen, SQL-Injection, Cross-Site-Scripting und anderen Angriffen auf HTTP-Ebene. Verwenden Sie verwaltete Regelsätze, und fügen Sie benutzerdefinierte Regeln für die spezifischen Muster Ihrer Anwendung hinzu.

12. DDoS-Schutz

Aktivieren Sie Azure DDoS-Schutz für alle öffentlichen IP-Ressourcen. DDoS Protection bietet eine durchgängige Überwachung des Datenverkehrs, automatische Angriffsabwehr und Kostenschutzgarantien. Kombinieren Sie den DDoS-Schutz mit WAF für die mehrschichtige Abwehr von Volumetric- und Application-Layer-Angriffen.

13. DNS-Sicherheit und Auflösung privater Namen

Konfigurieren Sie öffentliche DNS-Zonen für Ihre kundenorientierten Domänen mit CNAME-Einträgen, die auf Azure Front Door- oder Traffic Manager-Endpunkte verweisen. Wenden Sie Role-Based Access Control (RBAC) auf DNS-Zonen an, sodass nur autorisierte Teams Datensätze ändern können. Aktivieren Sie DNS-Sicherheitserweiterungen (DNSSEC) für Zonen, die eine kryptografische Überprüfung erfordern.

Phase 5: Vorgänge

14. Netzwerküberwachung und Observierbarkeit

Die Produktionsbereitschaft erfordert eine Überwachung von Tag 1. Aktivieren Sie Azure Network Watcher für konnektivitätsdiagnose, Netzwerk-Leistungsmonitor für die Latenznachverfolgung und Ablaufprotokolle für die Datenverkehrsanalyse. Anwendungsteams überwachen ihre eigenen AKS- und ASE-Workloads. Das Plattformteam überwacht die Hubinfrastruktur und die regionsübergreifende Konnektivität.

Bedingte Artikel

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

Zustand Artikel Wann einbeziehen
Hybride Koexistenz Hybridkonnektivität Ihre modernisierten Anwendungen müssen während des Übergangszeitraums mit lokalen Systemen koexistieren
VM-Administratorzugriff erforderlich Entwickler- und Administratorzugriff Ihre Umgebung umfasst VMs, die einen sicheren RDP/SSH-Zugriff zusammen mit PaaS-Workloads benötigen
Großer verwalteter Bestand Zentrale Netzwerkverwaltung Sie verwalten eine VNet-Landschaft mit mehreren Abonnements und mehreren Teams, die eine zentralisierte Richtliniendurchsetzung erfordert.
Cloudübergreifend Regionsübergreifende und Multicloudkonnektivität Ihre Architektur erfordert eine explizite, regionsübergreifende private Konnektivität, die über das multiregionenübergreifende Netzwerk hinausgeht.
Sehr kleine Arbeitsauslastung Flache Netzwerktopologie Sie verfügen über eine einzelne Workload, die die Komplexität der Hub-and-Spoke-Topologie nicht rechtfertigen kann.

Zusammenfassung

Wenn Sie diesem Lesepfad gefolgt sind, haben Sie eine regionenübergreifende, mehrschichtig abgesicherte Netzwerkarchitektur für PaaS-Workloads entwickelt. Ihr Design umfasst eine Dual-Hub-Topologie mit IT-verwalteten gemeinsam genutzten Diensten, eine Active-Active-Multiregion-Architektur mit Azure Front Door oder Azure Traffic Manager, Private-Link-Konnektivität für PaaS-Dienste, zentrale Firewall-Inspektion für alle Datenströme, WAF- und DDoS-Schutz für öffentliche Endpunkte sowie DNS mit RBAC und DNSSEC. Diese Architektur unterstützt moderne Anwendungsmuster, während gleichzeitig eine zentrale Sicherheitssteuerung aufrechterhalten wird.

Überprüfungsprüfliste

Verwenden Sie diese Checkliste, um zu bestätigen, dass Ihr Modernisierungsnetzwerkdesign abgeschlossen ist:

  • Dual-Hub-Topologie, die in primären und Backupregionen bereitgestellt wird.
  • Nicht überlappende Adressräume, die sowohl Regionen als auch zukünftigen Spokes zugewiesen sind.
  • Azure Front Door oder Azure Traffic Manager, konfiguriert für globalen eingehenden Datenverkehr, wenn Ihr Workload öffentlich erreichbar ist.
  • Private Link-Subnetze, die in jedem Spoke-VNet bereitgestellt werden, das PaaS-Abhängigkeiten beherbergt.
  • Benutzerdefinierte Routen leiten den ausgehenden Datenverkehr des Spoke-Netzwerks über die Hub-Firewall.
  • Azure Firewall in beiden Hub-VNets für eingehende, Ost-West- und ausgehende Inspektionen bereitgestellt.
  • WAF-Richtlinien, die auf öffentliche Webendpunkte angewendet werden, falls zutreffend.
  • DDoS-Schutz für öffentliche IP-Ressourcen aktiviert, falls zutreffend.
  • DNS-Zonen und private DNS-Auflösung, die für private Endpunkte konfiguriert sind.
  • Network Watcher, Datenflussprotokolle sowie regionsübergreifende Konnektivitätsüberwachung aktiviert.

Nächste Schritte

  • Last updated on