Microsoft AZ-700: Azure Virtual WAN & Hub-Spoke — Lernleitfaden

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Teil des Microsoft Azure Network Engineer AZ-700 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Virtual WAN versus klassisches Hub-and-Spoke: Das richtige Transitmodell wählen

Die Gestaltung des globalen Transits erfordert die Wahl zwischen Azure Virtual WAN (vWAN) und einem traditionellen Hub-and-Spoke-Modell, das aus VNets, NVAs und Peering aufgebaut ist. Virtual WAN bietet einen von Microsoft verwalteten globalen Backbone mit vHubs, die nativ VPN-, ExpressRoute- und P2S-Konnektivität hosten und automatisierte Routenverteilung, Site-to-Site-Skalierung und Integrationen mit SD-WAN-Partnern unterstützen. Für Organisationen, die viele Zweigstellenanbindungen, globales Routing und ein einfaches Betriebsmodell benötigen, reduziert vWAN den Orchestrierungsaufwand und verbessert die Ausfallsicherheit. Im Gegensatz dazu bietet ein manuelles Hub-and-Spoke-Modell (ein VNet mit einer Azure Firewall oder einer Drittanbieter-NVA in einem zentralen Hub und verbundenen Spokes) maximale Kontrolle über den Paketfluss, benutzerdefinierte NVA-Funktionen und oft niedrigere laufende Kosten bei kleinen Bereitstellungen. Die wichtigsten Kompromisse sind Durchsatz und Vorhersagbarkeit gegenüber granularer Kontrolle: vWAN-Hubs abstrahieren viele Details und bieten eine nahezu globale Skalierung, verursachen aber zusätzliche Kosten für den verwalteten Dienst und ermöglichen eine weniger flexible Anpassung des Paketpfads. Häufige Fallstricke sind die Annahme, dass vWAN automatisch transitives Peering zu nicht explizit verbundenen VNets bereitstellt; jeder Spoke oder jedes VNet muss verbunden und mit den Hub-Routentabellen verknüpft sein. Ein weiterer häufiger Fehler ist die Missachtung der Governance- und Subnetz-Namenskonventionen (z. B. das erforderliche AzureFirewallSubnet für Azure Firewall), die bei Nichtbeachtung automatisierte Bereitstellungen verhindern.

Gesicherter virtueller Hub, Azure Firewall und NVA-Integration

Das Modell des gesicherten virtuellen Hubs fügt dem vWAN Inspektions- und Richtlinienebenen hinzu, indem es Azure Firewall (oder eine Drittanbieter-NVA) und den Firewall Manager integriert, um Sicherheit, NAT und Routing für Spokes und lokale Standorte zu zentralisieren. Azure Firewall sollte im dedizierten AzureFirewallSubnet bereitgestellt werden, und Sie sollten sich basierend auf den Funktionen zwischen den Azure Firewall-SKUs entscheiden. Planen Sie Routentabellen sorgfältig: Hub-Routentabellen steuern den Datenverkehr zu Spokes, VPN-Standorten, P2S und ins Internet. Um den Datenverkehr per Force-Tunneling an eine NVA zu leiten, verknüpfen Sie die Spoke-Verbindung mit einer Hub-Routentabelle, die 0.0.0.0/0 an die NVA/Firewall weiterleitet. Berücksichtigen Sie Hochverfügbarkeit und Durchsatz: Azure Firewall ist zonal und unterstützt Autoscaling mit den SKUs Standard und Premium, aber Premium ist für TLS-Inspektion und IDPS erforderlich. Vermeiden Sie die Platzierung von Application Gateway- oder Private Link-Endpunkten in Subnetzen, die mit der Firewall-Infrastruktur geteilt werden; diese benötigen ihre eigenen Subnetze. Achten Sie auf die Erschöpfung von NAT- und SNAT-Ports bei großen ausgehenden Datenströmen; implementieren Sie SNAT-Pooling, Azure Firewall mit DNAT-Regeln oder verwenden Sie gegebenenfalls NAT Gateway.

Azure Firewall Standard vs. Premium: Standard unterstützt Stateful Firewall, FQDN-Filterung, grundlegendes SNAT/DNAT; Premium fügt TLS-Inspektion, IDPS, URL-Filterung und den Ausschluss von FQDN-Tags (Fully Qualified Domain Name) hinzu.
Load Balancer Basic vs. Standard: Standard unterstützt Zonenredundanz, Backend-Integritätsprüfungen und ist für den Private Link Service ILB erforderlich; Basic bietet keine Zonenresilienz und unterliegt strengeren Sicherheitsregeln.
VPN Gateway-SKUs: VpnGw1/2/3 (steigender Durchsatz und gleichzeitige Tunnel); verwenden Sie höhere Stufen für mehr S2S-Tunnel oder einen höheren Gesamtdurchsatz.

Private Konnektivitätsmuster: Private Link, Private Endpoints und Dienstendpunkte

Private Link und private Endpunkte bieten erstklassigen Zugriff auf PaaS, ohne den Datenverkehr über das Internet zu leiten; Dienstendpunkte sichern den Dienstzugriff, leiten den ausgehenden Verkehr aber weiterhin über den öffentlichen Dienst-Backbone. Verwenden Sie einen privaten Endpunkt, wenn Sie private IPs pro Ressource und eine DNS-Integration benötigen; verwenden Sie Dienstendpunkte, wenn Sie eine einfachere Zugriffskontrolle auf Subnetzebene benötigen und es für Sie akzeptabel ist, den ausgehenden Dienstverkehr über den Dienst-Backbone zu leiten. Wichtige betriebliche Details umfassen die DNS-Auflösung: Private Endpunkte erfordern die Aktualisierung des lokalen DNS oder von Azure DNS Private Zones, damit Clients die private IP auflösen; bedingte Weiterleitungen an lokale DNS-Server sind für S2S-verbundene Netzwerke üblich. Abonnementübergreifende Private Link Service-Szenarien werden unterstützt, wenn sich die Ressourcen im selben Azure AD-Tenant befinden; stellen Sie den Private Link Service hinter einem Standard Internal Load Balancer (ILB) bereit, um Skalierbarkeit und Zonenredundanz zu gewährleisten. Ein häufiger Fallstrick ist die Verwendung eines Basic ILB oder einer falschen SKU, was die Backend-Integrität und -Skalierung einschränkt. Für einen Private Link Service, der ein hohes Verbindungsvolumen unterstützt, verwenden Sie einen Standard ILB, Scale-Set-Backends und ziehen Sie mehrere Endpunkt-NICs pro Backend-Instanz in Betracht. Berücksichtigen Sie auch den DDoS-Schutz: Aktivieren Sie DDoS Protection Standard für öffentlich zugängliche NICs und planen Sie die Skalierung von SNAT-Ports und den Einsatz von NAT Gateway, wo viele ausgehende Verbindungen entstehen.

vWAN-Hub-Routingtabellen und praktisches Routendesign

vWAN verwendet Hub-Routingtabellen, um den Datenverkehr zwischen verbundenen Spokes, lokalen Standorten und dem Internet zu steuern. Jede Verbindung (Standort, VNet, P2S) kann einer Hub-Routingtabelle zugeordnet werden; Routenprioritäten und Weitergaberegeln bestimmen die endgültige Weiterleitung. Ein gutes Design beginnt mit einer Standard-Hub-Routingtabelle, die für das Internet bestimmten Verkehr an Azure Firewall oder eine NVA weiterleitet, und spezialisierten Routingtabellen für Zweigstellen, die einen lokalen Breakout erfordern. BGP von lokalen VPN-Geräten propagiert Präfixe in den Hub, und Sie können diese an Spokes weiterverteilen oder mit Routingtabellen filtern. Eine häufige Fehlerquelle sind widersprüchliche benutzerdefinierte Routen (UDRs) in Spoke-VNets, die versuchen, die Hub-Weitergabe zu überschreiben; bei vWAN haben Hub-Routingtabellen Vorrang für Verbindungen untereinander, aber UDRs in Spokes beeinflussen weiterhin den lokalen Egress. Für Forced Tunneling ordnen Sie Spoke-Verbindungen einer Hub-Routingtabelle zu, die 0.0.0.0/0 an Ihr ausgewähltes Inspektionsgerät leitet. Überwachen und planen Sie die Routenlimits: vWAN-Hubs haben eine maximale Anzahl an gelernten und angekündigten Präfixen – entwerfen Sie Präfix-Zusammenfassungen und BGP-Communities oder Filter, um innerhalb der Limits zu bleiben. Testen Sie immer die DNS-Auflösung und Split-DNS für private Endpunkte und dokumentieren Sie das Failover-Verhalten für Multi-Hub-Aktiv/Aktiv-Designs, um die SLAs für Resilienz zu erfüllen.

Praktisches Problem: Anwendungsfallszenario

Szenario: Contoso Manufacturing betreibt eine globale Azure-Präsenz mit einer bestehenden Hub-and-Spoke-VNet-Architektur in zwei Regionen, mehreren lokalen Standorten, die über SD-WAN verbunden sind, und der Anforderung, die Sicherheit zu zentralisieren und private PaaS-Konnektivität über Abonnements hinweg bereitzustellen.

Herausforderung: Sie benötigen einen skalierbaren, verwalteten globalen Transit, der die Inspektion (TLS-Inspektion, IDPS) zentralisiert, viele Zweigstellenverbindungen über SD-WAN unterstützt und mehrere Speicher- und Datenbank-PaaS-Ressourcen privat für Spokes und lokale Standorte bereitstellt, ohne sie öffentlich zugänglich zu machen.

Empfohlener Ansatz:

Stellen Sie Azure Virtual WAN (vWAN) bereit und erstellen Sie gesicherte virtuelle Hubs in jeder Region. Aktivieren Sie in jedem Hub Azure Firewall Premium (für TLS-Inspektion und IDPS) und integrieren Sie es mit dem Firewall Manager. Ordnen Sie den Hub den vWAN-Partner-SD-WAN-Verbindungen für einen direkten „Branch On-Ramp“ zu.
Konfigurieren Sie Hub-Routingtabellen so, dass sie für das Internet bestimmten und regionsübergreifenden Verkehr an Azure Firewall Premium leiten; erstellen Sie spezialisierte Routingtabellen für Zweigstellen, die einen lokalen Egress durchführen müssen. Verwenden Sie BGP vom SD-WAN, um lokale Präfixe in vWAN anzukündigen, und wenden Sie Präfixfilter an, um eine Überfrachtung der Routen („Route Bloat“) zu vermeiden.
Stellen Sie für PaaS-Dienste Private Link-Dienste in einem dedizierten VNet pro Region hinter einem Standard Internal Load Balancer bereit und stellen Sie Private Endpoints in Spoke-VNets und lokal über vWAN-Konnektivität zur Verfügung. Verwenden Sie Azure DNS Private Zones und bedingte Weiterleitungen, um die lokale Auflösung sicherzustellen.
Aktivieren Sie DDoS Protection Standard auf öffentlichen Endpunkten, stellen Sie ein NAT Gateway für umfangreiche ausgehende SNAT-Anforderungen in Spokes bereit und überwachen Sie SNAT/DNAT-Metriken. Verwenden Sie Firewall Manager-Richtlinien für die zentrale Verteilung von Regeln und konfigurieren Sie die Protokollierung in einem zentralen Log Analytics-Arbeitsbereich.

Begründung: Dieser Ansatz nutzt vWAN für skalierbare Zweigstellenkonnektivität und globalen Transit, verwendet Azure Firewall Premium für die zentralisierte, erweiterte Inspektion, die durch Sicherheitsrichtlinien gefordert wird, und Private Link für den sicheren PaaS-Zugriff ohne öffentliche Exposition – und schafft so eine Balance zwischen Verwaltbarkeit, Sicherheit und betrieblicher Skalierbarkeit.

← Netzwerküberwachung · Alle Domänen

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →