Microsoft AZ-104: Azure-Lastenausgleich und Traffic-Management — Lernleitfaden

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

Überblick

Azure bietet ein mehrschichtiges Portfolio zur Verteilung und zum Schutz von Datenverkehr: Azure Load Balancer (Layer 4, TCP/UDP), Application Gateway (Layer 7, HTTP/S), Azure Front Door (globaler Layer-7-Edge), Azure Traffic Manager (DNS-basiert) und Azure CDN (Edge-Caching). Jedes zielt auf ein bestimmtes Segment des Anfragepfads ab – von globalen DNS-Entscheidungen und Edge-POPs bis hin zu regionalem HTTP-Routing und privatem Ost-West-Datenverkehr. Entscheidend ist die Auswahl des richtigen Dienstes für das Protokoll und die Zielgruppe, deren korrekte Zusammensetzung sowie die Konfiguration von Integritätstests und Regeln, die ein zuverlässiges Failover steuern.

Azure Load Balancer (L4): SKUs, Bausteine, NAT/Outbound und Floating IP

Der Standard Load Balancer ist der für Produktionsumgebungen geeignete L4-Load-Balancer. Er ist zonenbewusst/zonenredundant, unterstützt HA-Ports, erweiterte Diagnose/Metriken, ist standardmäßig sicher (kein eingehender Datenverkehr, es sei denn, Sie definieren Regeln), hat konfigurierbare ausgehende Regeln und eine große Backend-Skalierung. Basic ist eine Legacy-SKU mit begrenzter Skalierung/Funktionen und ohne Zonenredundanz; sie wird außer Betrieb genommen und sollte nicht für neue Workloads gewählt werden.

Die Kernkomponenten definieren, wie der Datenverkehr fließt:

Frontend-IP: Die für Clients zugängliche VIP. Externe LBs verwenden eine öffentliche IP oder ein öffentliches IP-Präfix; interne LBs verwenden eine private statische IP aus einem Subnetz. Der Standard-Typ unterstützt mehrere Frontends und zonenredundante öffentliche IPs.
Backend-Pool: NICs, IP-Konfigurationen auf NICs oder Instanzen von VM-Skalierungsgruppen in derselben Region/demselben VNet. Ein einzelner Pool kann viele Regeln bedienen. Der Standard-Typ unterstützt zonenübergreifende Backends innerhalb einer Region.
Integritätstests: Bestimmen, welche Backend-Instanzen fehlerfrei sind. TCP-Tests führen einen Handshake durch; HTTP/HTTPS-Tests führen einen GET-Request an einen Pfad aus und werten 200–399 als Erfolg. Sie steuern Protokoll, Port, Pfad (für HTTP/S), Intervall und den Fehlerschwellenwert (aufeinanderfolgende Fehler, bevor eine Instanz als fehlerhaft markiert wird).
Lastenausgleichsregeln: Verknüpfen ein Frontend (IP/Port/Protokoll) mit einem Backend-Pool und einem Integritätstest. Die Regeleinstellungen umfassen Backend-Port, Protokoll (TCP/UDP), Sitzungspersistenz, Leerlauftimeout und Floating IP (Direct Server Return).

Regeln für eingehendes NAT sind pro-VM-Übersetzungen, die einen bestimmten Frontend-Port an eine einzelne Backend-NIC/einen einzelnen Port weiterleiten (z. B. um RDP oder SSH für eine VM ohne Lastenausgleich verfügbar zu machen). Sie verwenden nicht den Integritätstest und sind kein Mechanismus zur horizontalen Skalierung.

Ausgehende Regeln definieren das SNAT-Verhalten für Backends des Standard Load Balancers, die Verbindungen zum Internet über die öffentlichen Frontends des LBs initiieren. Sie ermöglichen es Ihnen zu steuern, welches Frontend (welche Frontends) SNAT-Ports bereitstellt und wie viele Ports pro Backend-Instanz zugewiesen werden, was hilft, eine Erschöpfung der SNAT-Ports bei hoher gleichzeitiger ausgehender Last zu vermeiden. Wenn ein NAT Gateway mit dem Subnetz verbunden ist, hat es Vorrang vor dem LB-SNAT; bevorzugen Sie NAT Gateway für konsistenten, skalierbaren ausgehenden Datenverkehr.

Floating IP (Direct Server Return) ist eine Regeloption, die verwendet wird, wenn die Ziel-IP/der Ziel-Port durchgängig erhalten bleiben muss. Sie ist für Cluster-Szenarien wie Listener für SQL Server Always On-Verfügbarkeitsgruppen erforderlich. Verwenden Sie für eine SQL AG einen internen Standard Load Balancer mit einem TCP-Test (nicht HTTP) auf den Testport des Clusters und aktivieren Sie Floating IP in der LB-Regel; testen Sie Port 1433 nicht mit HTTP, da SQL kein HTTP-Workload ist.

Die Entscheidung zwischen internen und externen Load Balancern hängt von der Zielgruppe und der Sicherheitsgrenze ab. Verwenden Sie einen internen LB, wenn Sie eine private VIP innerhalb eines VNets oder über private Konnektivität (VPN/ExpressRoute) für Branchenanwendungen, Datenbanken und NVAs bereitstellen. Verwenden Sie einen externen LB für L4-Dienste mit Internetzugang. Weisen Sie für interne LBs ein statisches privates Frontend im Ziel-Subnetz zu; binden Sie für externe LBs eine Standard Public IP an und verwenden Sie optional mehrere Frontends.

Der regionsübergreifende Load Balancer bietet globalen Anycast-Lastenausgleich auf Layer 4 über Regionen hinweg. Sie stellen Standard Public Load Balancer in jeder Region bereit (regionale Ebene) und platzieren deren öffentliche Frontends in das Backend eines einzigen globalen Load Balancers (globale Ebene). Der globale LB verwendet Integritätstests für jeden regionalen LB und leitet Clients zur nächstgelegenen fehlerfreien Region (nach Latenz) mit Flusssymmetrie basierend auf 5-Tupel-Hashing. Er ist nur für TCP/UDP – keine TLS-Terminierung – und ergänzt regionale L7-Gateways.

Application Gateway (L7) und Azure Front Door (globales L7)

Application Gateway ist ein regionaler Layer-7-Reverse-Proxy mit WAF. Es terminiert HTTP/HTTPS, inspiziert Header und Pfade und leitet den Verkehr an private oder öffentliche Backends weiter.

Wichtige Konstrukte von Application Gateway:

Listener: Binden eine Frontend-IP/Port/Hostname und SSL-Einstellungen, um Traffic anzunehmen. SNI ermöglicht mehrere TLS-Sites pro IP. Verwenden Sie Basic-Listener für einzelne Sites, Multi-Site-Listener für hostbasiertes Routing und Wildcard-Hosts für eine breite Abdeckung.
Routingregeln und HTTP-Einstellungen: Regeln ordnen Listener Backend-Pools zu und legen die HTTP-Einstellungen fest, die auf Backends angewendet werden (Protokoll, Port, Überschreiben des Host-Headers, cookie-basierte Affinität, Connection Draining, Request-Timeout). Sie können umleiten, Header umschreiben oder basierend auf URL-Pfadsegmenten routen.
Backend-Pools: Ziele können NIC-IPs, FQDNs, App Services oder VM Scale Sets sein. Benutzerdefinierte Health Probes (Systemdiagnose-Tests) überprüfen bestimmte Pfade/Hosts und berücksichtigen Erfolgs-Statuscodes.
WAF: Schutz basierend auf dem OWASP Core Rule Set im Erkennungs- oder Präventionsmodus mit benutzerdefinierten Regeln, Ausschlusslisten und routenweiser Zuordnung in v2. Autoskalierung und Zonenredundanz werden in v2 unterstützt.

Fortgeschrittene L7-Muster:

URL-pfadbasiertes Routing: Leiten Sie /api/* an Microservices und /images/* an einen statischen Ursprung oder ein CDN weiter, was ein Microservice-Fanout hinter einer einzigen VIP ermöglicht.
Multi-Site-Hosting: Hosten Sie contoso.com und fabrikam.com auf einem Gateway mithilfe von SNI-Listenern und auf Host-Headern basierenden Regeln. Nützlich für die Konsolidierung mit starker Isolation durch WAF-Richtlinien pro Site.
SSL-Terminierung: Lagern Sie TLS auf dem Gateway aus, um eine zentrale Zertifikatsverwaltung und WAF-Inspektion zu ermöglichen. Verwenden Sie End-to-End-TLS (erneute Verschlüsselung), wenn Backends eine Verschlüsselung oder die Validierung von Client-Zertifikaten erfordern.

Azure Front Door bietet globalen HTTP/HTTPS-Lastenausgleich und -Beschleunigung am Edge mit Anycast, Split-TCP und POP-zu-Ursprung-Optimierung. Es eignet sich am besten für Anwendungen mit Internetzugriff, die globales Routing, Edge-WAF und optionales Edge-Caching erfordern.

Globaler Lastenausgleich: Leitet Benutzer zum fehlerfreien Ursprung mit der niedrigsten Latenz, indem Health Probes von mehreren POPs verwendet werden. Ursprungsgruppen unterstützen prioritäts- und latenzbasiertes Failover, bei Bedarf mit Sitzungsaffinität.
WAF: Verwaltete Regeln mit Bot-Schutz, benutzerdefinierten Regeln, Geo-/IP-Filtern, Ratenbegrenzung und routenweiser Zuordnung.
Caching: Bei Front Door Standard/Premium ist Edge-Caching integriert; definieren Sie das Caching-Verhalten nach Pfad, steuern Sie das Caching von Abfragezeichenfolgen (Query-Strings) und TTLs und lagern Sie statische Inhalte global aus.
Health Probes: Pro Ursprungsgruppe gibt es Tests (HTTP/HTTPS) mit konfigurierbarem Pfad, Intervall und Protokoll von verschiedenen POPs. Routing-Entscheidungen kombinieren Systemzustand und Latenz.

Verwenden Sie Application Gateway für regionale L7-Anforderungen (private Backends, Ost-West-Verkehr, komplexe Umschreibungen) und Front Door für globales L7, Edge-Sicherheit und Beschleunigung. Sie werden häufig kombiniert: Front Door am Edge, Application Gateways pro Region und interne LBs hinter den Gateways für L4-Dienste.

Traffic Manager (DNS-basiert) und Azure CDN

Traffic Manager ist eine DNS-basierte globale Traffic-Verteilung. Er fungiert nicht als Proxy für den Verkehr; stattdessen gibt er den DNS-Namen/die IP eines Endpunkts basierend auf Richtlinien und Systemzustand zurück, sodass sich Clients direkt verbinden können. Der Systemzustand wird von verteilten Probes zu HTTP/HTTPS/TCP-Endpunkten überprüft; niedrige TTLs reduzieren die Failover-Latenz, erhöhen aber das Volumen der DNS-Abfragen.

Priorität: Aktiv/Passiv-Failover. Setzen Sie den primären Endpunkt an die erste Stelle; Traffic Manager bedient diesen, es sei denn, er ist fehlerhaft, und schaltet dann auf die nächste Priorität um.
Gewichtet: Verteilen Sie nach Gewichtungen, um schrittweise Umstellungen oder A/B-Tests zu unterstützen.
Leistung: Wählen Sie den Endpunkt mit der niedrigsten Netzwerklatenz von der Region des Benutzers zum Endpunkt.
Geografisch: Routen Sie basierend auf dem geografischen Standort des Benutzers für Datenhoheit oder Inhaltslokalisierung.
Mehrwertig (Multivalue): Geben Sie mehrere fehlerfreie Endpunkte für denselben Dienst zurück, um ein einfaches clientseitiges Failover zu unterstützen. Sie können Profile für hybride Richtlinien verschachteln (z. B. geografisch an oberster Stelle, dann gewichtet innerhalb einer geografischen Region). Verwenden Sie Traffic Manager für Nicht-HTTP-Protokolle, Dienste, die nicht von Edge-Proxying profitieren, oder wenn Sie Kontrolle auf DNS-Ebene über heterogene Endpunkte (Azure, On-Premises, Drittanbieter) benötigen.

Azure CDN lagert statische und zwischenspeicherbare Inhalte auf Edge-POPs aus, um die Last des Ursprungsservers und die Latenz zu reduzieren.

Profile: Container für einen oder mehrere Endpunkte, die an einen Anbieter/eine Ebene (z. B. Microsoft-, Akamai- oder Verizon-Familien) gebunden sind. Profile helfen bei der Trennung von Umgebungen oder Kostenstellen.
Endpunkte: Definieren Sie Ursprungsdetails (Hostname, Ursprungs-Host-Header, Protokoll/Port) und den Edge-Hostnamen. Sie können mehrere Endpunkte pro Profil für verschiedene Apps oder Inhaltstypen haben.
Caching-Regeln: Standard- und benutzerdefinierte Regeln steuern TTLs, pfadbasiertes Verhalten, die Handhabung von Abfragezeichenfolgen (Query-Strings) (weiterleiten, ignorieren oder jede eindeutige Abfrage cachen) und die Komprimierung. Verwenden Sie Regeln, um das Caching von Assets mit kurzen Ursprungs-TTLs zu erzwingen oder um das Caching für dynamische APIs zu umgehen.
Benutzerdefinierte Domänen: Ordnen Sie benutzerfreundliche Hostnamen mit von CDN verwaltetem TLS zu. Validieren Sie den Domänenbesitz über CNAME und aktivieren Sie HTTPS mit verwalteten Zertifikaten. Kombinieren Sie dies bei Bedarf mit Geo-Filterung oder der Rules Engine.

Designentscheidungen, regionsübergreifende Integration und Verhalten von Integritätstests

Interne und externe Load Balancer werden je nach Zielgruppe und Sichtbarkeit der Route ausgewählt. Wenn sich die Consumer nur in privaten Netzwerken befinden, verwenden Sie interne LBs, um eine öffentliche Exposition zu vermeiden und die NSG-Steuerung zu vereinfachen. Für Internetnutzer oder Partner verwenden Sie öffentliche Frontends. Für ausgehende Konnektivität im großen Maßstab ist NAT Gateway dem LB-SNAT vorzuziehen; reservieren Sie Regeln für ausgehenden Datenverkehr für Fälle, in denen das Frontend des LBs SNAT bereitstellen muss.

Der Cross-region Load Balancer lässt sich mit regionalen Standard Public Load Balancern integrieren, um eine aktiv-aktive, globale Layer-4-Ausfallsicherheit für TCP/UDP-Dienste zu erreichen. Platzieren Sie die öffentlichen Frontends der regionalen LBs im Backend-Pool des globalen LBs. Integritätstests auf der globalen Ebene spiegeln die regionale Verfügbarkeit wider; das Routing leitet den Verkehr in die fehlerfreie Region mit der niedrigsten Latenz und führt automatisch ein Failover durch, wenn eine ganze Region (oder ihr regionaler LB) fehlerhaft wird. Kombinieren Sie dies mit Front Door, wenn Sie Unterstützung für beide Protokolle (z. B. TCP-Dienste über den Cross-region LB und HTTP/S über Front Door) unter separaten VIPs benötigen.

Integritätstests sind die maßgebliche Quelle für das Failover:

TCP-Tests: Funktionieren für jeden TCP-Dienst. Ein abgeschlossener 3-Wege-Handshake signalisiert Erfolg. Geeignet für SQL, SMTP oder benutzerdefinierte TCP-Protokolle.
HTTP/HTTPS-Tests: Validieren die Integrität auf Anwendungsebene, indem sie einen Pfad anfordern und einen Statuscode von 200–399 erwarten. Sie ermöglichen Host/Pfad-Anpassungen und können partielle Anwendungsfehler unterscheiden. HTTPS-Tests überprüfen die TLS-Aushandlung, aber nicht die Gültigkeit des Zertifikats über den Handshake hinaus; verwenden Sie korrekte Host-Header für virtuell gehostete Anwendungen.
Schwellenwerte für fehlerhaften Zustand: Azure Load Balancer markiert ein Backend nach N aufeinanderfolgenden fehlgeschlagenen Tests als ausgefallen (konfigurierbar; die Standardintervalle sind kurz, um das Failover zu beschleunigen). Application Gateway und Front Door testen von mehreren Beobachtungspunkten aus und betrachten einen Ursprung als ausgefallen, wenn sich genügend aufeinanderfolgende Fehler über ihr Test-Set ansammeln. Die Wiederherstellung erfordert aufeinanderfolgende erfolgreiche Tests. Passen Sie Intervall und Schwellenwert an, um Empfindlichkeit und Flapping auszugleichen; stellen Sie sicher, dass die Tests einen schlanken, abhängigkeitsbewussten Endpunkt erreichen.

Praktisches Problemszenario

Adobe muss eine mandantenfähige SaaS-Lösung, die aus Web-Frontends, Microservices und einer SQL Server Always On-Verfügbarkeitsgruppe besteht, global bereitstellen. Dabei sind strenge Sicherheit, schnelles Failover und niedrige Latenz für Benutzer weltweit erforderlich. Sie stellen außerdem einen älteren TCP-basierten Dienst zur Erfassung von Telemetriedaten bereit.

Platzieren Sie Azure Front Door Standard am Edge mit einer WAF-Richtlinie und Routen für www.adobe.com und api.adobe.com. Die Ursprünge sind Application Gateways in East US und West Europe, gruppiert mit latenzbasiertem Routing und prioritätsgesteuertem Failover.

Warum: Front Door bietet globales Anycast, eine Edge-WAF und optionales Caching, um den HTTP/S-Internetverkehr zu beschleunigen und zu schützen; es wählt automatisch die nächstgelegene fehlerfreie Region aus.

Stellen Sie in jeder Region ein Application Gateway v2 mit WAF bereit. Konfigurieren Sie Multi-Site-Listener mit SNI für beide Hostnamen, URL-pfadbasiertes Routing zu den Microservices und benutzerdefinierte Integritätstests zu /healthz auf jedem Dienst. Aktivieren Sie End-to-End-SSL mit Überschreibung des Backend-Hosts auf die FQDNs der Dienste.

Warum: Application Gateway bietet regionales L7-Routing, WAF-Inspektion in der Nähe der Anwendung, pfadbasiertes Fan-Out und richtlinien pro Route; es verbindet sich sicher mit privaten Backends und handhabt das Umschreiben/Umleiten von Headern.

Stellen Sie in jeder Region einen internen Standard Load Balancer für den SQL AG-Listener bereit. Konfigurieren Sie ein statisches privates Frontend, einen TCP-Integritätstest zum Testport des Windows Failover Clusters und eine Lastenausgleichsregel mit aktivierter Floating IP zum Listener-Port.

Warum: Der SQL-Listener erfordert L4 mit Direct Server Return. Floating IP bewahrt die Zielsemantik, und ein TCP-Test spiegelt die Zuständigkeit der AG genau wider. Dies entspricht der bekannten Anforderung, dass HTTP-Tests auf Port 1433 ungültig sind.

Sichern Sie die statischen Web-Assets mit Azure Front Door-Caching-Regeln für /static/* mit einer langen TTL und Revalidierung ab. Richten Sie außerdem ein Azure CDN-Profil und einen Endpunkt für große Mediendownloads unter downloads.adobe.com mit pfadspezifischem Caching und Variationen der Abfragezeichenfolge ein.

Warum: Das Caching von Front Door reduziert die Latenz für statische Kerninhalte der Webseite im Einklang mit dem Edge-Routing, während ein dedizierter CDN-Endpunkt die Bereitstellung großer Objekte und die Unabhängigkeit der Cache-Richtlinie für Downloads optimiert.

Veröffentlichen Sie die ältere TCP-Telemetrieerfassung über einen regionalen Standard Public Load Balancer in jeder Region und schalten Sie diesen einen Cross-region Load Balancer als einzige öffentliche VIP vor. Konfigurieren Sie globale Tests für jeden regionalen LB und verwenden Sie latenzbasiertes Routing.

Warum: Der Dienst ist TCP, nicht HTTP; der Cross-region Load Balancer bietet globales aktiv-aktives L4 mit automatischem Failover und Auswahl der Region mit der niedrigsten Latenz.

Fügen Sie Azure Traffic Manager mit einer Prioritätsrichtlinie nur für einen externen Partner-SFTP-Endpunkt hinzu, der außerhalb von Azure gehostet wird, und listen Sie den primären Partnerendpunkt sowie einen in Azure gehosteten Backup-Endpunkt auf.

Warum: Traffic Manager ist DNS-basiert und kann externe Endpunkte einbeziehen; er bietet ein einfaches aktiv/passiv-Failover für Nicht-HTTP- und Drittanbieter-Ziele, bei denen kein Proxying erwünscht ist.

Für ausgehende Konnektivität von Anwendungs-Subnetzen, binden Sie ein NAT Gateway an und entfernen Sie die Abhängigkeit von LB-ausgehendem SNAT. Überwachen Sie die Testergebnisse und die Metriken von LB/App Gateway/Front Door in Azure Monitor und passen Sie die Testintervalle/Schwellenwerte für fehlerhaften Zustand an, um Flapping zu eliminieren.

Warum: NAT Gateway skaliert ausgehenden Verkehr zuverlässig ohne SNAT-Port-Erschöpfung; eine präzise Abstimmung der Integritätstests führt zu einem schnelleren, stabilen Failover-Verhalten über alle Schichten hinweg.

← Azure Virtuelle Vernetzung · Alle Domänen · Azure-Speicher →

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