Microsoft AZ-900: Netzwerk — Lernleitfaden

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

Hybride und private Konnektivität: VPN Gateway, ExpressRoute, VNet-Peering und Private Link

Azure VPN Gateway erstellt verschlüsselte Tunnel mittels IPsec/IKE für Site-to-Site- (S2S), Point-to-Site- (P2S) und VNet-zu-VNet-Verbindungen. Es ist eine kostengünstige Möglichkeit, Ihr lokales Netzwerk über das öffentliche Internet nach Azure zu erweitern, wobei die Daten während der Übertragung verschlüsselt bleiben. Der Durchsatz und die Anzahl der Tunnel skalieren mit der VpnGw-SKU, und Hochverfügbarkeit wird standardmäßig durch Aktiv/Standby-Instanzen erreicht. Unterstützung für Aktiv/Aktiv und BGP ermöglichen dynamisches Routing und einen höheren aggregierten Durchsatz. ExpressRoute bietet private, SLA-gestützte Layer-3-Konnektivität zu Microsoft über den Edge eines Partners oder direktes Peering. Der Datenverkehr verbleibt außerhalb des öffentlichen Internets und bietet dadurch vorhersagbare Latenz und höhere Bandbreitenoptionen. ExpressRoute-Leitungen (Circuits) unterstützen mehrere Peerings (Azure privat, Microsoft und gegebenenfalls Microsoft 365) und verwenden dual-redundante Verbindungen. Es ist die bevorzugte Option für geschäftskritische Szenarien mit hohem Durchsatz, oft in Kombination mit einer Hub-and-Spoke-Topologie, bei der das Hub-VNet das ExpressRoute- oder VPN-Gateway hostet. VNet-Peering verbindet VNets über das Microsoft-Backbone mit niedriger Latenz und hoher Bandbreite, sodass Ressourcen über private IPs kommunizieren können, als befänden sie sich im selben Netzwerk. Peering ist nicht-transitiv: Der Datenverkehr wird nicht automatisch durch ein VNet, mit dem ein Peering besteht, zu einem dritten VNet weitergeleitet. Gateway-Transit kann aktiviert werden, damit Spoke-VNets das VPN- oder ExpressRoute-Gateway des Hubs nutzen. Für den Zugriff auf PaaS über eine private IP erstellt Private Link einen privaten Endpunkt (eine NIC in Ihrem Subnetz), der einer bestimmten Dienstinstanz wie Azure Storage, SQL Database oder einem von Ihnen veröffentlichten privaten Dienst zugeordnet ist. Der Datenverkehr fließt vollständig über das Azure-Backbone, und DNS ist entscheidend, um sicherzustellen, dass Clients zum privaten Endpunkt auflösen. Die Wahl zwischen diesen Optionen hängt von den Anforderungen ab: VPN Gateway für verschlüsselte Konnektivität über das Internet, ExpressRoute für private Hochleistungsleitungen, VNet-Peering für private Konnektivität innerhalb von Azure und Private Link für den privaten Zugriff auf PaaS- oder Partnerdienste, ohne öffentliche Endpunkte preiszugeben.

• VPN Gateway
  • Konnektivitätsschicht: L3 (IPsec/IKE)
  • Geltungsbereich: On-Prem <-> Azure; VNet <-> VNet
  • Typische Bandbreite: Hunderte von Mbps bis Multi-Gbps (pro SKU)
  • Verschlüsselung: Ja (IPsec)
  • Hauptstärken: Kostengünstig, flexibel, P2S/S2S
  • Primäre Anwendungsfälle: Hybride Erweiterung, Dev/Test, schnelle Inbetriebnahme
• ExpressRoute
  • Konnektivitätsschicht: Private L3-Leitung
  • Geltungsbereich: On-Prem <-> Azure (über Partner)
  • Typische Bandbreite: 50 Mbps–100 Gbps (pro Leitung)
  • Verschlüsselung: Private Leitung (kein IPsec erforderlich)
  • Hauptstärken: Vorhersagbare Latenz, hoher Durchsatz, SLA
  • Primäre Anwendungsfälle: Geschäftskritische Hybrid-Szenarien, Datenreplikation, Compliance
• VNet Peering
  • Konnektivitätsschicht: Azure-Backbone
  • Geltungsbereich: VNet <-> VNet (gleiche oder globale Region)
  • Typische Bandbreite: Durch VM-NIC/Host begrenzt; niedrige Latenz
  • Verschlüsselung: Nein (privates Backbone)
  • Hauptstärken: Einfach, schnell, mandantenübergreifende Unterstützung
  • Primäre Anwendungsfälle: Hub-Spoke, regionales/globales VNet-Mesh
• Private Link
  • Konnektivitätsschicht: L7-Endpunkt über private NIC
  • Geltungsbereich: Client-VNet <-> PaaS/Privater Dienst
  • Typische Bandbreite: App-abhängig; NIC-begrenzt
  • Verschlüsselung: Backbone-Isolierung
  • Hauptstärken: Eliminiert öffentliche Erreichbarkeit, granular
  • Primäre Anwendungsfälle: Privater Zugriff auf Storage, SQL, Key Vault, Partner-Apps

Verkehrsverteilung und -beschleunigung: Load Balancer, Application Gateway, Front Door, Traffic Manager und CDN

Azure Load Balancer arbeitet auf Layer 4 für TCP/UDP und bietet hochleistungsfähiges Load Balancing mit geringer Latenz innerhalb einer Region. Er unterstützt eingehende und ausgehende Szenarien, eingehende NAT-Regeln und Integritätstests (Health Probes). Der Standard Load Balancer ist zonenbewusst (zone-aware) und kann zur Erhöhung der Resilienz Zonen innerhalb einer Region umspannen. Er ist die richtige Wahl für Nicht-HTTP-Protokolle, Gaming-Backends und Szenarien, die HA-Ports oder SNAT für ausgehende Konnektivität in großem Umfang über ausgehende Regeln oder ein NAT Gateway erfordern. Application Gateway bietet Layer-7-Routing für HTTP/HTTPS mit Funktionen wie URL-pfad- und hostbasiertem Routing, Cookie-Affinität und SSL-Offloading. Wenn es mit der Web Application Firewall (WAF) SKU aktiviert wird, bietet es verwaltete OWASP-Regelsätze zum Schutz vor gängigen Exploits und Bots. Application Gateway ist regional und wird oft vor VM Scale Sets, Containern oder App Services in privaten Netzwerkkonfigurationen eingesetzt, insbesondere wenn umfangreiches HTTP-Routing und eine WAF-Inspektion erforderlich sind. Azure Front Door ist ein globaler Anycast-Eingangspunkt auf Layer 7, der für das Internet zugängliche Webanwendungen beschleunigt und schützt. Der Dienst bietet globales Load Balancing mit sofortigem Failover, intelligentes Pfad-Routing (Smart Pathing) und eine integrierte WAF. Front Door Standard/Premium integriert CDN-Funktionen zur Beschleunigung von statischen und dynamischen Inhalten am Edge und kann als Ursprung (Origin) auf Application Gateways, App Services oder Storage verweisen. Traffic Manager ergänzt diese Dienste durch eine DNS-basierte globale Verteilung auf beliebige Endpunkte (HTTP oder Nicht-HTTP) und verwendet dabei Methoden wie Priorität, Leistung, gewichtet, geografisch, Subnetz und Mehrwert-Routing. Für das Offloading statischer Inhalte speichert Azure CDN (einschließlich Front Door Standard/Premium oder Azure CDN von Microsoft/Verizon/Akamai) Inhalte näher bei den Benutzern zwischen (Caching), reduziert die Last auf dem Ursprungsserver und verbessert die Leistung. Die Kombination von Diensten ist üblich. Ein typisches Design mit Internetzugang verwendet Azure Front Door mit WAF für den globalen Eingang (Ingress), das auf regionale Application Gateways (mit oder ohne WAF) verweist, die den Verkehr an interne Workloads weiterleiten. Für andere Protokolle als HTTP/HTTPS kombinieren Sie Traffic Manager für DNS-Failover mit regionalen Load Balancern. Platzieren Sie öffentliche IPs nur an diesen verwalteten Edges und halten Sie die Anwendungs-VMs privat.

• Azure Load Balancer
  • Ebene: L4
  • Geltungsbereich: Regional
  • Protokolle: TCP/UDP
  • WAF-Unterstützung: Nein
  • Sitzungsaffinität: Nein (auf L7)
  • Gängige Anwendungsfälle: Nicht-HTTP-Workloads, internes Load Balancing, ausgehendes SNAT
• Application Gateway
  • Ebene: L7
  • Geltungsbereich: Regional
  • Protokolle: HTTP/HTTPS
  • WAF-Unterstützung: Ja (WAF v2)
  • Sitzungsaffinität: Ja (Cookie-basiert)
  • Gängige Anwendungsfälle: Web-Apps in VNets, SSL-Offloading, Pfad-/Host-Routing
• Azure Front Door
  • Ebene: L7
  • Geltungsbereich: Global
  • Protokolle: HTTP/HTTPS
  • WAF-Unterstützung: Ja (WAF)
  • Sitzungsaffinität: Ja (Affinitäts-Cookie)
  • Gängige Anwendungsfälle: Globaler Eingangspunkt, Edge-Beschleunigung, sofortiges Failover
• Traffic Manager
  • Ebene: DNS
  • Geltungsbereich: Global
  • Protokolle: Beliebig (DNS-basiert)
  • WAF-Unterstützung: Nein
  • Sitzungsaffinität: Nein
  • Gängige Anwendungsfälle: Regionsübergreifendes Failover/Lastverteilung für beliebige Endpunkte
• Azure CDN
  • Ebene: L7-Cache
  • Geltungsbereich: Global
  • Protokolle: HTTP/HTTPS
  • WAF-Unterstützung: Nein (Front Door WAF verwenden)
  • Sitzungsaffinität: N/A
  • Gängige Anwendungsfälle: Caching statischer Inhalte, Origin-Offload, Performance

Netzwerksicherheit und sicherer Zugriff: NSGs, Azure Firewall, DDoS Protection, Bastion und Just-in-Time

Network Security Groups (NSGs) wenden zustandsbehaftete Layer-3/4-Filterung auf Subnetze und NICs an. Regeln erlauben oder verweigern Datenverkehr basierend auf 5-Tupel-Parametern, mit Unterstützung für Service-Tags und Anwendungssicherheitsgruppen zur Vereinfachung der Verwaltung. NSGs sind ideal für die Segmentierung von Tiers, die Einschränkung von Verwaltungsports und die Durchsetzung des Prinzips der geringsten Rechte (Least Privilege) zwischen Subnetzen. Sie sind schnell und verteilt, bieten jedoch keine Filterung auf Anwendungsebene, keine Intrusion Prevention oder zentralisiertes DNAT/SNAT. Azure Firewall ist ein verwalteter, zustandsbehafteter Firewall- und Netzwerksicherheitsdienst, der sowohl Netzwerkregeln als auch Anwendungsregeln (FQDN-Filterung) bereitstellt. Die Premium-SKU fügt TLS-Inspektion, IDPS und URL-Filterung hinzu. Sie unterstützt DNAT/SNAT, auf Threat Intelligence basierende Filterung und lässt sich in Routingtabellen integrieren, um einen zentralen Kontrollpunkt für ausgehenden Datenverkehr (Egress) in Hub-and-Spoke-Topologien zu schaffen. Azure Firewall ergänzt NSGs: NSGs setzen lokale Ost-West-Mikrosegmentierung durch, während die Firewall zentralisierte Nord-Süd- und Internet-Egress-Richtlinien durchsetzt. Azure DDoS Protection wird in den Varianten Basic und Standard angeboten. Basic ist ein Schutz auf Plattformebene, der automatisch auf Azure-Dienste ohne Konfiguration durch den Kunden angewendet wird. Standard fügt adaptive Abstimmung, Telemetrie, Benachrichtigungen und schnelle Abwehrmaßnahmen für Ressourcen mit öffentlichen IPs innerhalb eines geschützten VNets hinzu, plus Kostenschutz-Gutschriften während dokumentierter Angriffe. Für den administrativen Zugriff ohne öffentliche IPs bietet Azure Bastion RDP/SSH über TLS direkt aus dem Azure-Portal (und unterstützte native Clients in Bastion Standard), wodurch die Gefährdung durch eingehenden Datenverkehr eliminiert wird. Der Just-in-Time (JIT) VM-Zugriff, der über Microsoft Defender for Cloud aktiviert wird, hält Verwaltungsports in NSGs geschlossen und öffnet zeitlich begrenzten Zugriff nur für genehmigte Benutzer und Quell-IPs. Dies minimiert die Angriffsfläche, während der operative Zugriff erhalten bleibt.

• OSI-Fokus
  • NSG: L3/L4 (zustandsbehaftet)
  • Azure Firewall: L3–L7 (zustandsbehaftet)
  • DDoS Protection Standard: Volumetrische/L3/L4-Abwehr
  • Azure Bastion: Sicherer RDP/SSH-Zugriff
  • JIT VM Access: Zeitsteuerung des Zugriffs
• Zentrales Richtlinien-Mgmt
  • NSG: Begrenzt (pro Subnetz/NIC)
  • Azure Firewall: Ja (Richtlinie, Regeln, IDPS)
  • DDoS Protection Standard: Ja (pro geschütztem VNet)
  • Azure Bastion: Nicht zutreffend
  • JIT VM Access: Richtlinie über Defender for Cloud
• DNAT/SNAT
  • NSG: Nein
  • Azure Firewall: Ja
  • DDoS Protection Standard: Nein
  • Azure Bastion: Nein
  • JIT VM Access: Nein
• WAF/IDPS
  • NSG: Nein
  • Azure Firewall: Premium: IDPS
  • DDoS Protection Standard: N/A
  • Azure Bastion: Nein
  • JIT VM Access: Nein
• Primärer Nutzen
  • NSG: Mikrosegmentierung
  • Azure Firewall: Zentralisierte Steuerung und Überprüfung
  • DDoS Protection Standard: Angriffsabwehr für öffentliche IPs
  • Azure Bastion: Keine öffentlichen IPs für Admin-Zugriff
  • JIT VM Access: Schließt Mgmt-Ports, außer bei Bedarf

Praktisches Problem: Globaler Rollout im Einzelhandel für Contoso Outdoors: sicheres, privates und hochverfügbares Netzwerk

Szenario: Contoso Outdoors führt eine neue E-Commerce-Plattform ein, die auf Microservices basiert, die auf Azure in den Regionen East US und West Europe ausgeführt werden. Das Unternehmen muss alle Anwendungs-VMs privat halten, einen sicheren administrativen Zugriff bereitstellen und Partnern ermöglichen, Bestandsdateien in Azure Storage hochzuladen, ohne das öffentliche Internet zu nutzen. Das lokale ERP-System in Chicago benötigt eine private Konnektivität mit geringer Latenz zu den Diensten in East US. Das Web-Frontend muss gegen den Ausfall einer einzelnen Region resilient sein und vor gängigen Web-Exploits und volumetrischen Angriffen schützen.

Herausforderung: Entwerfen Sie ein Netzwerk, das private Adressräume, hybride Konnektivität, globale HTTP-Verteilung, privaten Zugriff auf PaaS und mehrschichtige Sicherheit kombiniert, ohne die öffentlichen IPs von VMs preiszugeben.

Empfohlener Ansatz:

1. Erstellen Sie eine Hub-and-Spoke-Architektur in jeder Region. Stellen Sie ein Hub-VNet mit dem Adressraum 10.0.0.0/16 und Spokes für Web-, App- und Daten-Tiers mit nicht überlappenden /24-Subnetzen bereit. Weisen Sie jedem Subnetz NSGs zu, um das Least-Privilege-Prinzip zwischen den Tiers durchzusetzen.
2. Stellen Sie Azure Firewall Premium in jedem Hub bereit. Konfigurieren Sie UDRs in den Spokes, um den gesamten ausgehenden Internetverkehr zur Firewall für die Egress-Kontrolle, TLS-Inspektion und das Filtern von Bedrohungsdaten (Threat Intelligence) zu leiten.
3. Stellen Sie eine hybride Konnektivität vom Rechenzentrum in Chicago zum Hub in East US mit ExpressRoute (Private Peering) her. Aktivieren Sie duale Verbindungen für Redundanz und BGP für dynamisches Routing. Verwenden Sie bei Bedarf vorübergehend ein Site-to-Site-VPN als Failover.
4. Peeren Sie regionale Spokes mit ihren lokalen Hub-VNets mittels VNet-Peering. Aktivieren Sie Gateway-Transit, damit die Spokes das ExpressRoute/VPN-Gateway des Hubs nutzen können. Verwenden Sie globales VNet-Peering, um die Hubs in East US und West Europe für den Control-Plane- und Replikationsverkehr zu verbinden.
5. Veröffentlichen Sie die E-Commerce-Website mit Azure Front Door Premium und WAF. Konfigurieren Sie zwei Ursprünge (Origins): die Application Gateways in East US und West Europe. Aktivieren Sie die von Front Door verwalteten WAF-Richtlinien und den Bot-Schutz. Aktivieren Sie das Caching von Front Door für statische Inhalte (Assets).
6. Stellen Sie in jeder Region ein Application Gateway WAF v2 im Web-Spoke bereit, das TLS terminiert und pfad- sowie hostbasiertes Routing zu Backend-Pools (VM Scale Sets oder App Services) in privaten Subnetzen durchführt. Verwenden Sie intern Standard Load Balancer für Nicht-HTTP-Microservices.
7. Erstellen Sie für den privaten Zugriff von Partnern und zwischen Diensten Private Endpoints zu Azure Storage und Azure SQL Database in den Daten-Spokes. Verknüpfen Sie die entsprechenden Azure Private DNS-Zonen mit allen Spokes und Hubs und konfigurieren Sie das lokale DNS so, dass es privatelink-Zonen zur konsistenten Namensauflösung an Azure weiterleitet.
8. Schützen Sie öffentlich zugängliche Oberflächen mit Azure DDoS Protection Standard, indem Sie es auf den Hub-VNets aktivieren, die öffentliche IP-Ressourcen für die Application Gateway- und Front Door-Ursprünge enthalten. Überwachen Sie Angriffsmetriken und konfigurieren Sie Warnmeldungen.
9. Stellen Sie eine sichere Administration durch die Bereitstellung von Azure Bastion Standard in jedem Hub-VNet bereit. Entfernen Sie alle öffentlichen IPs von den VMs. Aktivieren Sie den Just-in-Time (JIT) VM-Zugriff in Defender for Cloud, damit der RDP/SSH-Zugriff zeitlich und quellbezogen eingeschränkt ist, wenn er durch Bastion getunnelt wird.
10. Instrumentieren Sie das Netzwerk mit NSG-Flow-Protokollen, Azure Firewall-Protokollen und den Zugriffsprotokollen von Front Door/Application Gateway in Log Analytics. Konfigurieren Sie Health Probes und synthetische Tests, um die End-to-End-Verfügbarkeit und das Failover-Verhalten zu validieren.

Azure-Begründung: Dieses Design hält die Anwendungsebenen privat und kontrolliert, während es gleichzeitig einen gehärteten globalen Edge bereitstellt. ExpressRoute liefert eine private, vorhersagbare Konnektivität für das ERP-System, wobei VNet-Peering und Gateway-Transit den Zugriff auf alle Spokes erweitern. Azure Front Door mit WAF bietet globale HTTP-Verteilung, sofortiges Failover und Edge-Sicherheit, während regionale Application Gateways das L7-Routing und die WAF in der Nähe der Workloads übernehmen. Private Link eliminiert die öffentliche Erreichbarkeit von Storage und SQL und wird durch privates DNS für eine nahtlose Auflösung von Azure und aus der lokalen Umgebung unterstützt. NSGs setzen die Mikrosegmentierung durch; Azure Firewall zentralisiert Egress, DNAT/SNAT und erweiterte Inspektion; Azure DDoS Protection Standard mindert volumetrische Angriffe auf öffentliche Endpunkte. Azure Bastion und JIT ermöglichen einen sicheren, auditierbaren administrativen Zugriff, ohne Verwaltungsports zu öffnen oder VMs öffentliche IPs zuzuweisen. Dies erfüllt Sicherheits- und Compliance-Ziele, ohne die Bedienbarkeit zu beeinträchtigen.

← Compute- · Alle Domänen · Speicher →

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

Microsoft durchsuchen →