Microsoft AZ-700: Azure Virtual Network Design — 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.

Adressraum- und Subnetzplanung

Eine disziplinierte IP-Adressierungsplanung verhindert zukünftige Nacharbeiten und vermeidet Kollisionen mit On-Premises-Netzwerken oder anderen VNets. Verwenden Sie hierarchische CIDR-Blöcke (zum Beispiel ein /16 pro großer Geschäftseinheit, /24 pro VNet, /26–/22 pro Subnetz je nach Rolle) und reservieren Sie zusammenhängende Bereiche für Erweiterungen, Peering und VPN/S2S-Site-Mappings. Azure erzwingt Namens- und Subnetzanforderungen für mehrere Plattformdienste: GatewaySubnet muss existieren (und so dimensioniert sein, dass es das VPN-Gateway und seine Skalierungseinheiten umfasst), AzureFirewallSubnet muss dediziert sein und AzureFirewallSubnet heißen, und AzureBastionSubnet muss ein dediziertes /27 oder größer sein. Application Gateway und viele virtuelle Netzwerk-Appliances (NVAs) erfordern ebenfalls dedizierte Subnetze (keine anderen Ressourcen). Planen Sie eine Adressüberschneidungsfreiheit zwischen gepeerten VNets und On-Premises-Bereichen; überlappende Adressräume machen Peering, VPN und Routing unmöglich. Ziehen Sie die Subnetzdelegierung in Betracht, wenn Sie Plattformdienste (AKS, verwaltete Azure Database-Instanzen) bereitstellen, und vermeiden Sie die Platzierung von NSGs oder UDRs, die mit den erforderlichen Plattformrouten für diese Dienste in Konflikt stehen. Eine häufige Fehlerquelle ist die Unterdimensionierung des GatewaySubnet oder AzureFirewallSubnet; diese Dienste können skalieren und benötigen im Laufe der Zeit zusätzliche IPs. Abwägungen: Kleinere CIDRs sparen Adressraum, erhöhen aber das Risiko zukünftiger Neukonfigurationen; größere CIDRs kosten nichts, vergrößern aber die Verwaltungsoberfläche. Dokumentieren Sie alle Zuweisungen und reservieren Sie Blöcke für private PaaS-Endpunkte, Jump-Hosts, Überwachungsagenten und Egress-NAT-Kapazität.

VNet-Peering, Gateway-Transit und Routenpriorität

VNet-Peering bietet Konnektivität mit geringer Latenz und hoher Bandbreite, ist aber nicht transitiv: Verkehr von einem gepeerten Spoke wird nicht automatisch durch ein zweites gepeertes VNet geroutet, um On-Premises zu erreichen. Um die On-Prem-Konnektivität zu zentralisieren, müssen Sie ein Hub-VNet mit einem VPN Gateway oder ExpressRoute-Gateway bereitstellen. Konfigurieren Sie das Hub-Peering mit aktiviertem allowGatewayTransit und das Spoke-Peering mit aktiviertem useRemoteGateways; das VPN Gateway darf nur im Hub existieren. Denken Sie daran, dass Peering nicht überlappende Adressräume erfordert und sowohl regionales als auch globales Peering unterstützt (globales Peering verursacht Datenübertragungskosten und eine etwas höhere Latenz). Die Routenpriorität ist wichtig: Benutzerdefinierte Routen (UDRs) haben Vorrang vor über BGP gelernten und Systemrouten; BGP-Routen haben Vorrang vor Systemrouten. Wenn Sie Forced-Tunneling für die Egress-Inspektion benötigen, erstellen Sie UDRs, die auf eine Virtual Appliance (NVAs) oder Azure Firewall verweisen, und kündigen Sie dann bei Bedarf entsprechende Routen über BGP zurück an On-Prem an. Typische Fehlerquellen sind das Vergessen, allowGatewayTransit am Hub oder useRemoteGateways an den Spokes zu setzen, das Versäumnis, P2S-Client-Konfigurationen nach dem Hinzufügen von Spokes erneut herunterzuladen (P2S-Clients benötigen aktualisierte Routen), und die Annahme, dass Peering transitiv ist. Wählen Sie VPN Gateway-SKUs nach Durchsatz und P2S-Funktionen aus: Ziehen Sie VpnGw1/2/3 für produktives P2S und BGP in Betracht; Basic fehlen viele Funktionen.

VPN Gateway-SKUs: VpnGw1 – moderater Durchsatz, unterstützt OpenVPN/IKEv2/P2S; VpnGw2 – höherer Durchsatz und TLS-Skalierung; VpnGw3 – höchster Durchsatz und größte Skalierung. Basic – eingeschränkte Funktionen und nicht für Hub-Szenarien empfohlen.

Dienstendpunkte vs. private Endpunkte und DNS-Auswirkungen

Dienstendpunkte erweitern Ihre VNet-Identität auf Azure-PaaS-Dienste (Storage, SQL, Cosmos DB), sodass der Datenverkehr den Microsoft-Backbone nutzt, während der öffentliche Endpunkt des Dienstes für ausgewählte Subnetze gesichert ist. Private Endpunkte platzieren eine Netzwerkschnittstelle in Ihrem Subnetz, die auf die private IP-Adresse der PaaS-Ressource verweist und so eine echte private Konnektivität bietet. Wählen Sie Dienstendpunkte, wenn Sie eine einfache Zugriffskontrolle auf Subnetzebene ohne DNS-Änderungen wünschen; wählen Sie private Endpunkte, wenn Sie ressourcenbasierten Zugriff, Isolation auf VNet-Ebene oder die vollständige Deaktivierung des öffentlichen Netzwerkzugriffs benötigen. Private Endpunkte erstellen eine Netzwerkschnittstelle (ENI) und müssen mit einer privaten DNS-Zone (privatelink.<service>.azure.com) verknüpft sein oder erfordern manuelle DNS-A-Einträge – eine häufige Fehlerquelle ist die Vernachlässigung von DNS, was dazu führt, dass Clients die öffentliche IP anstelle des privaten Endpunkts auflösen. Beachten Sie auch, dass private Endpunkte eine IP aus dem Zielsubnetz verbrauchen; planen Sie die IP-Kapazität entsprechend. Dienstendpunkte eliminieren den öffentlichen Endpunkt nicht – um ein Speicherkonto vollständig abzusichern, müssen Sie den öffentlichen Netzwerkzugriff deaktivieren, nachdem Sie einen privaten Endpunkt aktiviert haben. Kosten- und Betriebs-Abwägungen: Private Endpunkte erhöhen den Verwaltungsaufwand (ressourcenbasiertes DNS und Genehmigungen) und die betriebliche Komplexität geringfügig, bieten aber eine stärkere Isolation; Dienstendpunkte sind einfacher und kostengünstiger, aber weniger granular.

NAT-Gateway, Azure Firewall und Kompromisse beim Routen-Design

Für vorhersagbares ausgehendes SNAT und vereinfachtes Egress-Management, stellen Sie Azure Virtual Network NAT (Standard NAT Gateway) auf Subnetzen oder NICs bereit und fügen Sie öffentliche Standard-IPs oder -Präfixe hinzu (nur Standard-SKU). Das NAT Gateway übernimmt die Verwaltung der ephemeren Ports; wenn Sie eine hohe Anzahl ausgehender Verbindungen erwarten, fügen Sie mehrere öffentliche IP-Präfixe hinzu, um die verfügbaren SNAT-Ports zu erhöhen und eine Port-Erschöpfung zu vermeiden – ein häufiges Problem bei vielen VMs oder Container-Hosts. Azure Firewall bietet zentralisierte, vollständig verwaltete zustandsbehaftete Überprüfung (Stateful Inspection), Threat Intelligence und Anwendungs-/FQDN-Filterung; wählen Sie Azure Firewall Standard für grundlegende Filterung und die Premium-SKU für TLS-Inspektion, IDPS und erweiterte Bedrohungsabwehrfunktionen. Virtuelle Netzwerk-Appliances (NVAs von Drittanbietern) bieten einen größeren Funktionsumfang oder Kostenalternativen, erfordern aber Management, HA-Konfiguration und Skalierungsplanung. UDRs, die auf eine VirtualAppliance oder das Internet/NAT verweisen, müssen gegen die Systemrouten von Azure evaluiert werden, da falsche UDRs den Datenverkehr von Plattformdiensten unterbrechen können (z. B. durch Blockieren des Datenverkehrs von Dienstendpunkten oder von der Plattform verwalteten Health Probes). Für hohe Verfügbarkeit und Leistung ziehen Sie zonenredundante SKUs (Application Gateway v2, Firewall in Availability Zones) und Autoscaling-Funktionen im Vergleich zu Appliances mit festen Kosten in Betracht. Häufige Fallstricke: das Anfügen von NAT sowohl an das Subnetz als auch an die NIC führt zu unerwarteter Priorisierung; das Vergessen, dass NAT öffentliche Standard-IP(s) erfordert; die falsche Benennung und Dimensionierung des AzureFirewallSubnet; und die Annahme, dass UDRs ignoriert werden – sie überschreiben die Systemrouten.

Praktisches Problem: Anwendungsfallszenario

Szenario: Contoso Enterprises betreibt ein Hub-and-Spoke-Netzwerk in Azure. Der Hub in der Region „West US“ hostet ein ExpressRoute-Gateway und ein VpnGw2 (im GatewaySubnet). Mehrere Spokes enthalten Anwendungs-Subnetze und private Endpunkte für PaaS-Dienste. Remote-Mitarbeiter verbinden sich über ein Point-to-Site (P2S) VPN mit dem Hub.

Herausforderung: Remote-Benutzer können auf Ressourcen im Hub zugreifen, aber nach dem Hinzufügen neuer Spokes nicht auf VNet-Ressourcen in den Spokes. Einige P2S-Clients zeigen veraltete Routensätze an.

Empfohlener Ansatz:

Stellen Sie im Hub-VNet sicher, dass das VPN-Gateway ein VpnGw2 ist, das in einem korrekt dimensionierten GatewaySubnet (mindestens /27) bereitgestellt wird. Überprüfen Sie, dass es das einzige Gateway in der Peering-Topologie ist und dass ExpressRoute über Routenaustausch koexistiert.
Setzen Sie beim Hub-zu-Spoke-Peering auf der Hub-Seite allowGatewayTransit = true. Setzen Sie bei jedem Spoke-Peering useRemoteGateways = true und stellen Sie sicher, dass sich die Adressräume nicht überschneiden.
Generieren Sie die aktualisierte P2S-VPN-Client-Konfiguration vom Hub-VPN-Gateway neu und verteilen Sie sie (einschließlich IKEv2/OpenVPN). Fordern Sie die Remote-Benutzer auf, den Client neu zu installieren, damit ihre Routing-Tabellen die neuen Spoke-Präfixe enthalten.
Wenn Spokes den ausgehenden Verkehr zur Überprüfung über den Hub leiten müssen, fügen Sie UDRs in den Routing-Tabellen der Spokes hinzu, die 0.0.0.0/0 an die virtuelle Appliance des Hubs oder an die Azure Firewall (bereitgestellt im AzureFirewallSubnet) leiten. Kündigen Sie die erforderlichen Routen über BGP auf ExpressRoute/VPN zurück an.

Begründung: Die Aktivierung von Gateway-Transit mit useRemoteGateways zentralisiert das On-Prem- und P2S-Routing über das Hub-Gateway, ohne zusätzliche Gateways zu erstellen. Gleichzeitig aktualisiert die Neuausgabe der P2S-Client-Konfigurationen die Routing-Tabellen der Clients, sodass neue Spoke-Präfixe erreichbar sind. UDRs und BGP gewährleisten einen kontrollierten ausgehenden Verkehr (Egress) und Sichtbarkeit für die Überprüfung.

← ExpressRoute · Alle Domänen · Hybride Vernetzung →

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