Microsoft Azure Network Engineer Associate
Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der AZ-700-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Ressourcen über VNets in verschiedenen Abonnements oder Regionen privat verbinden.
Konfigurieren Sie VNet-Peering zwischen den virtuellen Netzwerken.
Warum: Hält den Datenverkehr im Microsoft Backbone. VNet-Peering ist nicht transitiv; für die Kommunikation ist ein direktes Peering erforderlich (A->B, B->C != A->C).
VNet-Adressräume für zukünftige Konnektivität entwerfen.
Weisen Sie jedem VNet eindeutige, sich nicht überlappende CIDR-Blöcke zu.
Warum: VNet-Peering erfordert nicht überlappende Adressräume. Planen Sie für Wachstum, um eine Neugestaltung zu vermeiden.
Die erforderliche Subnetzgröße für eine bestimmte Anzahl von Hosts berechnen.
Verwenden Sie die CIDR-Notation, die die erforderlichen Hosts + 5 reservierte IP-Adressen für Azure bereitstellt.
Warum: Azure reserviert die ersten vier und die letzte IP-Adresse in jedem Subnetz. Ein /24 (256 IPs) bietet nur 251 nutzbare IPs.
Dienste wie Azure Firewall, Gateway oder Bastion bereitstellen.
Erstellen Sie dedizierte Subnetze mit spezifischen Namen (z.B. AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet) und Mindestgrößen (/26, /27, /26 respektive).
Warum: Diese Dienste erfordern dedizierte, spezifisch benannte Subnetze, um ihre Ressourcen einzuschleusen. Die Dimensionierung ist entscheidend für Funktionalität und zukünftige Skalierung.
Namensauflösung zwischen lokalen Netzwerken und Azure Private DNS Zonen ermöglichen.
Stellen Sie Azure DNS Private Resolver bereit. Verwenden Sie einen Inbound-Endpunkt für On-Premises-zu-Azure-Abfragen und einen Outbound-Endpunkt mit Weiterleitungsregeln für Azure-zu-On-Premises-Abfragen.
Warum: Bietet eine verwaltete PaaS-Lösung für hybrides DNS, ohne benutzerdefinierte DNS-VMs zu benötigen. Lokales DNS leitet an die IP des Inbound-Endpunkts weiter.
Ein gepeertes VNet kann keine Datensätze in einer Private DNS Zone auflösen.
Erstellen Sie eine virtuelle Netzwerkverbindung von der Private DNS Zone zum gepeerten VNet.
Warum: Der Zugriff auf die Private DNS Zone ist nicht transitiv über Peering. Jedes VNet, das eine Auflösung benötigt, muss eine explizite Verbindung haben.
Eine statische, vorhersehbare öffentliche Outbound-IP für VMs in einem Subnetz zur Zulassungsliste bereitstellen.
Verknüpfen Sie ein Azure NAT Gateway mit einer Public IP oder einem Public IP Prefix mit dem Subnetz.
Warum: NAT Gateway überschreibt alle anderen Outbound-Konnektivitätsmethoden für ein Subnetz und stellt sicher, dass der gesamte Datenverkehr seine statischen öffentlichen IP(s) verwendet.
Sicherstellen, dass eine öffentliche IP für eine Ressource wie einen Load Balancer konstant bleibt.
Verwenden Sie eine Public IP Adresse der Standard SKU mit statischer Zuweisung.
Warum: Statische IPs der Standard SKU sind standardmäßig zonenredundant und bleiben auch dann bestehen, wenn die zugehörige Ressource gestoppt oder gelöscht wird.
Ein Subnetz für einen AKS-Cluster unter Verwendung von Azure CNI-Networking entwerfen.
Berechnen Sie den IP-Bedarf als (Anzahl der Knoten * maximale Pods pro Knoten) + Anzahl der Knoten. Weisen Sie ein Subnetz zu, das diese Anzahl aufnehmen kann.
Warum: Mit Azure CNI erhält jeder Pod eine IP direkt aus dem Subnetz, was eine erhebliche IP-Adresszuweisung erfordert.
Den gesamten Internet-gebundenen Datenverkehr von einem Spoke VNet durch eine Azure Firewall im Hub VNet leiten.
Erstellen Sie eine User Defined Route (UDR) Tabelle mit einer Route für 0.0.0.0/0, dem Next-Hop-Typ "Virtuelle Appliance" und der privaten IP der Azure Firewall.
Warum: Dies überschreibt die standardmäßige Systemroute zum Internet und zwingt den gesamten Datenverkehr zur Überprüfung durch die Firewall.
Datenverkehr zwischen zwei Spoke VNets mit einer Azure Firewall im Hub überprüfen.
Erstellen Sie in jedem Spoke UDRs für andere Spoke-Adressräume, die auf die Firewall zeigen. Erstellen Sie in der Firewall Netzwerkregeln, um den Datenverkehr zuzulassen.
Warum: Das Routing muss auf beiden Spokes konfiguriert werden, um Datenverkehr an die Firewall zu senden, die standardmäßig den Datenverkehr zwischen VNets verweigert.
Einen resilienten NVA-Cluster für die Datenverkehrsprüfung oder das Routing bereitstellen.
Verwenden Sie Azure Route Server. Die NVAs peeren mit Route Server über BGP und kündigen Routen an. Route Server verwendet ECMP zur Lastverteilung.
Warum: Route Server vereinfacht das dynamische Routing mit NVAs, eliminiert komplexe UDR-Verwaltung und bietet automatisiertes Failover.
Eine NVA verwirft Datenverkehr, den sie routen sollte.
Aktivieren Sie "IP-Weiterleitung" auf der Netzwerkschnittstelle (NIC) der NVA.
Warum: Diese Azure-Einstellung ist erforderlich, damit die NIC Datenverkehr empfangen und weiterleiten kann, der nicht für ihre eigene IP-Adresse bestimmt ist.
HTTP/S-Datenverkehr global an das Backend mit der geringsten Latenz mit WAF und SSL-Offloading verteilen.
Verwenden Sie Azure Front Door.
Warum: Front Door verwendet Anycast-Routing für optimale Leistung und integriert WAF, URL-Routing und SSL-Offloading am Edge.
Datenverkehr zu globalen Endpunkten basierend auf DNS mit Health-Probe-gesteuertem Failover verteilen.
Verwenden Sie Azure Traffic Manager.
Warum: Traffic Manager ist ein DNS-basierter Load Balancer. Verwenden Sie "Leistungs"-Routing für die geringste Latenz oder "Prioritäts"-Routing für Active/Passive-Failover.
Regionales HTTP/S-Load Balancing mit WAF, SSL-Terminierung und URL-/Host-basiertem Routing bereitstellen.
Stellen Sie Azure Application Gateway v2 bereit.
Warum: Application Gateway ist ein regionaler L7-Load Balancer. Verwenden Sie pfadbasierte Regeln für URL-Routing und Multi-Site-Listener für Host-basiertes Routing.
Lastverteilung für Nicht-HTTP/S (TCP/UDP)-Datenverkehr innerhalb einer Region.
Verwenden Sie Azure Load Balancer (Standard SKU).
Warum: Azure Load Balancer ist ein regionaler L4-Load Balancer. Er bewahrt die Quell-IP des Clients und ist für alle TCP/UDP-Protokolle geeignet.
SSL am Application Gateway beenden, aber den Datenverkehr zum Backend erneut verschlüsseln.
Konfigurieren Sie einen HTTPS-Listener. In den Backend-HTTP-Einstellungen setzen Sie das Protokoll auf HTTPS und laden das vertrauenswürdige Stammzertifikat der Backend-Server hoch.
Warum: Stellt sicher, dass der Datenverkehr auf dem gesamten Weg zum Backend verschlüsselt ist, auch bei selbstsignierten Zertifikaten auf Backend-Servern.
Lastverteilung des Datenverkehrs an einen SQL Server Always On Availability Group Listener.
Verwenden Sie einen internen Standard Load Balancer mit aktivierter Einstellung "Floating IP (Direct Server Return)" in der Lastverteilungsregel.
Warum: Floating IP ist erforderlich, damit der SQL AG Listener korrekt funktioniert, da sie es dem sekundären Knoten ermöglicht, Clients nach einem Failover direkt zu antworten.
Lastverteilung des Datenverkehrs an einen NVA-Cluster, der alle Protokolle und Ports verarbeiten muss.
Verwenden Sie einen internen Standard Load Balancer mit einer "HA Ports"-Lastverteilungsregel.
Warum: Die HA Ports-Regel leitet den gesamten TCP- und UDP-Datenverkehr auf allen Ports weiter, was die Konfiguration für NVAs vereinfacht, die alle Datenverkehrsflüsse überprüfen müssen.
Automatisches Failover zwischen einem primären und einem sekundären Webanwendungsursprung konfigurieren.
Platzieren Sie beide Ursprünge in derselben Front Door Ursprungsgruppe. Weisen Sie dem primären Ursprung eine Priorität von 1 und dem sekundären eine niedrigere Priorität (z.B. 2) zu.
Warum: Front Door leitet den Datenverkehr immer an den gesunden Ursprung mit der höchsten Priorität. Wenn der primäre Ursprung Health-Probes fehlschlägt, wechselt der Datenverkehr automatisch zur nächsten Priorität.
Sicheren RDP/SSH-Zugriff auf Azure VMs bereitstellen, ohne Management-Ports dem Internet auszusetzen.
Stellen Sie Azure Bastion bereit (Standard SKU für erweiterte Funktionen).
Warum: Bastion fungiert als verwaltete Jump Box und bietet Zugriff über das Azure-Portal über TLS. Es eliminiert die Notwendigkeit öffentlicher IPs auf VMs für die Verwaltung.
Zugriff auf einen Azure PaaS-Dienst (z.B. SQL, Storage) über eine private IP-Adresse innerhalb Ihres VNets.
Erstellen Sie einen Private Endpoint für die PaaS-Ressource. Integrieren Sie ihn mit einer Private DNS Zone für die automatische Namensauflösung.
Warum: Private Endpoint projiziert den PaaS-Dienst mit einer privaten IP in Ihr VNet und ermöglicht so eine wirklich private Konnektivität. Das Deaktivieren des öffentlichen Netzwerkzugriffs auf dem PaaS-Dienst erzwingt dies.
Zugriff auf Azure PaaS-Dienste von einem VNet über den Azure Backbone, ohne öffentliche IPs zu verwenden, aber ohne eine dedizierte private IP zu verwalten.
Aktivieren Sie einen Service Endpoint für den spezifischen Dienst (z.B. Microsoft.Storage) auf dem Quell-Subnetz.
Warum: Service Endpoints bieten eine direkte Route zu PaaS-Diensten von einem VNet, verwenden jedoch keine private IP im VNet. Es ist einfacher, aber weniger flexibel als Private Endpoints.
Einen Dienst, der in Ihrem VNet läuft, für Konsumenten in anderen VNets (potenziell andere Tenants) privat verfügbar machen.
Platzieren Sie den Dienst hinter einem Standard Load Balancer und erstellen Sie einen Private Link Service, der darauf zeigt.
Warum: Private Link Service ist die Anbieterseite. Konsumenten erstellen Private Endpoints in ihren VNets, um sich privat mit Ihrem Dienst zu verbinden.
NSG-Regeln für eine mehrschichtige Anwendung vereinfachen, bei der VMs skaliert werden oder IPs ändern können.
Erstellen Sie Application Security Groups (ASGs) für jede Ebene (z.B. Web, App, DB). Definieren Sie NSG-Regeln unter Verwendung von ASGs als Quelle/Ziel.
Warum: ASGs fungieren als Netzwerkobjekt-Tags für VMs und ermöglichen es Ihnen, Regeln basierend auf der Anwendungsstruktur statt auf brüchigen IP-Adressen zu erstellen.
Datenverkehr wird unerwartet blockiert, wenn NSGs sowohl auf eine NIC als auch auf ihr Subnetz angewendet werden.
Beachten Sie die NSG-Regel-Evaluationsreihenfolge. Eingehend: NIC-Regeln zuerst, dann Subnetz-Regeln. Ausgehend: Subnetz-Regeln zuerst, dann NIC-Regeln.
Warum: Ein Deny auf jeder Ebene blockiert den Datenverkehr. Beide NSGs müssen den Datenverkehrsfluss zulassen, damit er erfolgreich ist.
Datenverkehr zu/von bekannten bösartigen IP-Adressen und Domains automatisch blockieren.
Aktivieren Sie die Azure Firewall Threat Intelligence-basierte Filterung im Modus "Alarmieren und verweigern".
Warum: Dies nutzt den Threat Intelligence Feed von Microsoft, um verwalteten, aktuellen Schutz vor bekannten Bedrohungen ohne Konfiguration zu bieten.
Verschlüsselten HTTPS-Datenverkehr auf Bedrohungen wie Malware überprüfen.
Verwenden Sie Azure Firewall Premium. Aktivieren Sie die TLS-Inspektion in der Richtlinie und stellen Sie ein Zwischen-CA-Zertifikat bereit, dem Clients vertrauen müssen.
Warum: Dies ist eine Premium-Funktion, die eine Man-in-the-Middle-Entschlüsselung zur Überprüfung des Datenverkehrs durchführt, was für eine Zero-Trust-Sicherheitsstrategie entscheidend ist.
Ausgehenden Zugriff auf komplexe Microsoft-Dienste wie Windows Update ohne Pflege von IP-Listen ermöglichen.
Erstellen Sie in Azure Firewall eine Anwendungsregel mit FQDN-Tags (z.B. "WindowsUpdate", "AzureBackup").
Warum: Microsoft verwaltet die mit diesen Tags verknüpften FQDNs und vereinfacht so die Firewall-Regelverwaltung für dynamische Dienste.
Öffentlich zugängliche Anwendungen vor volumetrischen DDoS-Angriffen schützen und Zugang zu schneller Reaktionsunterstützung erhalten.
Aktivieren Sie DDoS Network Protection (ehemals Standard) auf dem VNet.
Warum: Bietet adaptive Abstimmung, Angriffstelemetrie, Schadensbegrenzungsberichte und Zugang zum DDoS Rapid Response Team, was der kostenlosen Basis-Schutz fehlt.
Einen Konnektivitätsfehler diagnostizieren und den genauen Hop identifizieren, an dem Datenverkehr verworfen wird.
Verwenden Sie Network Watcher > Verbindungsproblembehandlung.
Warum: Es führt eine End-to-End-Prüfung durch, zeigt den vollständigen Hop-by-Hop-Pfad und lokalisiert Fehler aufgrund von NSGs, UDRs oder anderen Netzwerkproblemen.
Schnell überprüfen, ob eine NSG-Regel den Datenverkehr zu/von einer VM zulässt oder verweigert.
Verwenden Sie Network Watcher > IP-Fluss überprüfen.
Warum: Dies ist das direkteste Tool, um ein spezifisches 5-Tupel gegen NSG-Regeln zu testen und zu sehen, welche Regel für das Ergebnis verantwortlich ist.
Alle zugelassenen und verweigerten Netzwerkdatenverkehr zur Compliance und Analyse protokollieren.
Aktivieren Sie NSG-Flow-Logs und führen Sie diese in Traffic Analytics (über einen Log Analytics Workspace) ein.
Warum: NSG Flow Logs liefern Rohdaten des Datenverkehrs. Traffic Analytics reichert diese Daten an und visualisiert sie, um Datenverkehrsmuster, Top-Talker und Sicherheitsbedrohungen zu identifizieren.
Ein lokales Netzwerk mit Azure über eine private, dedizierte Verbindung mit vorhersehbarer Latenz und hoher Bandbreite verbinden.
Stellen Sie einen Azure ExpressRoute-Schaltkreis bereit.
Warum: ExpressRoute umgeht das öffentliche Internet vollständig und bietet eine zuverlässigere, schnellere und latenzärmere Verbindung als ein Site-to-Site-VPN.
Wählen Sie das korrekte ExpressRoute-Peering, um auf Azure-Ressourcen zuzugreifen.
Verwenden Sie Azure Private Peering, um sich mit VNets zu verbinden. Verwenden Sie Microsoft Peering, um auf öffentliche PaaS-Dienste und Microsoft 365 zuzugreifen.
Warum: Die beiden Peering-Typen bieten Zugriff auf unterschiedliche Ressourcensätze. Microsoft Peering erfordert öffentliche IPs, NAT und Routenfilter.
Spoke VNets den Zugriff auf lokale Netzwerke über ein zentrales VPN- oder ExpressRoute-Gateway im Hub VNet ermöglichen.
Aktivieren Sie beim Hub-zu-Spoke-Peering "Gateway-Transit zulassen". Aktivieren Sie beim Spoke-zu-Hub-Peering "Remote-Gateways verwenden".
Warum: Diese zweiteilige Konfiguration ermöglicht es Spokes, das Gateway des Hubs zu verwenden, wodurch die hybride Konnektivität zentralisiert wird.
Ein Site-to-Site VPN als Backup für eine ExpressRoute-Verbindung konfigurieren.
Stellen Sie sowohl ein ExpressRoute- als auch ein VPN-Gateway bereit. Standardmäßig werden ExpressRoute-Pfade gegenüber VPN-Pfaden für dieselben Präfixe bevorzugt.
Warum: Azure bevorzugt ExpressRoute aufgrund eines höheren Standard-Routengewichts automatisch. Wenn der ExpressRoute-Schaltkreis ausfällt, zieht BGP die Routen zurück, und der Datenverkehr wird auf das VPN umgeleitet.
Den Datenverkehr beeinflussen, um einen ExpressRoute-Schaltkreis gegenüber einem anderen für aktive/passive Redundanz zu bevorzugen.
Verwenden Sie BGP AS Path Prepending. Fügen Sie Ihre eigene ASN mehrmals zu den Routenankündigungen auf dem Backup-Schaltkreis hinzu, um dessen Pfad länger erscheinen zu lassen.
Warum: BGP bevorzugt den kürzesten AS Path. Dies macht den primären Schaltkreis zum bevorzugten Pfad, mit automatischem Failover zum Backup, wenn der primäre Pfad zurückgezogen wird.
Zwei lokale Standorte über das Microsoft Backbone-Netzwerk unter Verwendung ihrer bestehenden ExpressRoute-Schaltkreise verbinden.
Aktivieren Sie ExpressRoute Global Reach.
Warum: Global Reach verbindet zwei ExpressRoute-Schaltkreise miteinander und ermöglicht ein privates WAN über das Microsoft-Netzwerk, ohne dass der Datenverkehr in einem Azure VNet eine Schleife bilden muss.
Die Verwaltung eines globalen Netzwerks, das viele Zweigstellen und VNets verbindet, vereinfachen.
Stellen Sie Azure Virtual WAN bereit.
Warum: Virtual WAN bietet einen verwalteten Hub-and-Spoke-Dienst mit automatisierter Any-to-Any-transitive Konnektivität, Routing und Integration mit Sicherheitsdiensten (gesicherter Hub).
In Virtual WAN den gesamten Inter-VNet-, Inter-Branch- und Internet-gebundenen Datenverkehr zentral überprüfen.
Stellen Sie einen gesicherten virtuellen Hub (mit Azure Firewall) bereit. Konfigurieren Sie die Routing-Intention, um privaten und Internet-Datenverkehr durch die Firewall zu senden.
Warum: Die Routing-Intention vereinfacht das Traffic Engineering in vWAN, indem Routen automatisch programmiert werden, um den Datenverkehr ohne manuelle UDRs durch den Sicherheitsanbieter zu zwingen.
Eine resiliente VPN-Verbindung zu Azure bereitstellen.
Stellen Sie ein VPN Gateway in einer Aktiv-Aktiv-Konfiguration bereit. Dies erfordert zwei öffentliche IPs und ein On-Premises-Gerät, das zwei Tunnel aufbauen kann.
Warum: Bietet Redundanz auf Instanzebene innerhalb der Azure-Region. Für Zonenredundanz verwenden Sie zonenredundante (AZ) SKUs.
Ein Point-to-Site VPN-Protokoll für breite Client-Kompatibilität ohne zusätzliche Software wählen.
Verwenden Sie IKEv2. Für maximale Kompatibilität, einschließlich älterer Geräte, verwenden Sie OpenVPN.
Warum: IKEv2 wird nativ auf modernen Windows-, macOS- und iOS-Systemen unterstützt. SSTP ist nur für Windows. OpenVPN erfordert einen Client, wird aber weitgehend unterstützt.
Den gesamten Internet-gebundenen Datenverkehr von Azure VMs zu einer lokalen Sicherheitsappliance umleiten.
Bewerben Sie von On-Premises aus eine Standardroute (0.0.0.0/0) über BGP über die ExpressRoute- oder VPN-Verbindung.
Warum: Diese BGP-Ankündigung überschreibt die Standard-Internetroute von Azure und zwingt den Datenverkehr zur Überprüfung zurück ins lokale Netzwerk.
