Microsoft AZ-104: Azure Load Balancing en Verkeersbeheer — Studiegids

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

Onderdeel van de Microsoft Azure Administrator Associate AZ-104 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Azure biedt een gelaagd portfolio voor het distribueren en beveiligen van verkeer: Azure Load Balancer (Layer 4, TCP/UDP), Application Gateway (Layer 7, HTTP/S), Azure Front Door (global Layer 7 edge), Azure Traffic Manager (op DNS-basis), en Azure CDN (edge caching). Elke service richt zich op een specifiek segment van het request-pad—van wereldwijde DNS-beslissingen en edge POP’s tot regionale HTTP-routing en privaat, east-west verkeer. Beheersing komt voort uit het selecteren van de juiste service voor het protocol en de doelgroep, het correct samenstellen ervan, en het configureren van health probes en regels die zorgen voor een betrouwbare failover.

Azure Load Balancer (L4): SKU’s, bouwstenen, NAT/outbound en floating IP

Standard Load Balancer is de L4 load balancer van productiekwaliteit. Deze is zone-aware/zone-redundant, ondersteunt HA Ports, geavanceerde diagnostiek/metrics, is secure-by-default (geen inkomend verkeer tenzij je regels definieert), heeft configureerbare outbound-regels en een grote backend-schaal. Basic is een verouderde SKU met beperkte schaal/features en zonder zoneredundantie; deze wordt uitgefaseerd en moet niet worden gekozen voor nieuwe workloads.

Kerncomponenten definiëren hoe het verkeer stroomt:

Frontend IP: Het VIP dat wordt blootgesteld aan clients. Externe LB’s gebruiken een Public IP of Public IP Prefix; interne LB’s gebruiken een privaat statisch IP-adres uit een subnet. Standard ondersteunt meerdere frontends en zone-redundante public IP’s.
Backend pool: NIC’s, IP-configuraties op NIC’s, of VM scale set-instances in dezelfde regio/VNet. Eén enkele pool kan vele regels bedienen. Standard ondersteunt cross-zone backends binnen een regio.
Health probes: Bepalen welke backend-instances healthy zijn. TCP-probes voltooien een handshake; HTTP/HTTPS-probes doen een GET-request naar een pad en beschouwen 200–399 als succes. Je beheert het protocol, de poort, het pad (voor HTTP/S), het interval en de unhealthy threshold (aantal opeenvolgende fouten voordat een instance als ‘down’ wordt gemarkeerd).
Load balancing rules: Koppelen een frontend (IP/poort/protocol) aan een backend pool en health probe. Regelinstellingen omvatten de backend-poort, het protocol (TCP/UDP), session persistence, idle timeout en Floating IP (Direct Server Return).

Inbound NAT-regels zijn per-VM vertalingen die een specifieke frontend-poort doorsturen naar één enkele backend NIC/poort (bijvoorbeeld om RDP of SSH voor één VM beschikbaar te maken zonder load balancing). Ze gebruiken de health probe niet en zijn geen mechanisme voor scale-out.

Outbound-regels definiëren het SNAT-gedrag voor backends van een Standard Load Balancer die verbindingen naar het internet initiëren via de public frontends van de LB. Ze stellen je in staat om te bepalen welke frontend(s) SNAT-poorten leveren en hoeveel poorten per backend-instance worden toegewezen, wat helpt om SNAT-poortuitputting bij hoge outbound concurrency te voorkomen. Als een NAT Gateway aan het subnet is gekoppeld, heeft deze voorrang op LB SNAT; geef de voorkeur aan NAT Gateway voor consistente, schaalbare outbound-connectiviteit.

Floating IP (Direct Server Return) is een regeloptie die wordt gebruikt wanneer het bestemmings-IP/poort end-to-end behouden moet blijven. Het is vereist voor geclusterde scenario’s zoals SQL Server Always On availability group listeners. Gebruik voor een SQL AG een interne Standard Load Balancer met een TCP-probe (niet HTTP) naar de probe-poort van het cluster en schakel Floating IP in op de LB-regel; probeer poort 1433 niet met HTTP, aangezien SQL geen HTTP-workload is.

De keuze tussen interne en externe load balancers hangt af van de doelgroep en de security boundary. Gebruik een interne LB bij het blootstellen van een privaat VIP binnen een VNet of via private connectiviteit (VPN/ExpressRoute) voor line-of-business apps, databases en NVA’s. Gebruik een externe LB voor internetgerichte L4-services. Wijs voor interne LB’s een statische private frontend toe in het doelsubnet; voor externe LB’s, koppel een Standard Public IP en gebruik optioneel meerdere frontends.

Cross-region Load Balancer biedt wereldwijde, anycast Layer 4 load balancing over meerdere regio’s. Je implementeert Standard Public Load Balancers in elke regio (regionale tier) en plaatst hun public frontends in de backend van één enkele globale Load Balancer (globale tier). De globale LB gebruikt health probes naar elke regionale LB en stuurt clients naar de dichtstbijzijnde gezonde regio (op basis van latency) met flow-symmetrie gebaseerd op 5-tuple hashing. Het is alleen TCP/UDP—geen TLS-termination—en vormt een aanvulling op regionale L7-gateways.

Application Gateway (L7) en Azure Front Door (globale L7)

Application Gateway is een regionale Layer 7 reverse proxy met WAF. Het beëindigt HTTP/HTTPS, inspecteert headers en paden, en routeert verkeer naar private of publieke backends.

Belangrijkste constructies van Application Gateway:

Listeners: Koppelen een frontend IP/poort/hostnaam en SSL-instellingen om verkeer te accepteren. SNI maakt meerdere TLS-sites per IP mogelijk. Gebruik ‘basic listeners’ voor een enkele site, ‘multi-site listeners’ voor host-gebaseerde routing, en wildcard-hosts voor een brede dekking.
Routingregels en HTTP-instellingen: Regels koppelen listeners aan backend-pools en specificeren de HTTP-instellingen die op backends worden toegepast (protocol, poort, host-header-override, cookie-gebaseerde affiniteit, ‘connection draining’, request-timeout). U kunt verkeer omleiden, headers herschrijven of routeren op basis van URL-padsegmenten.
Backend-pools: Doelen kunnen NIC IP’s, FQDN’s, app services of VM scale sets zijn. Aangepaste ‘health probes’ controleren specifieke paden/hosts en respecteren succesvolle statuscodes.
WAF: Bescherming gebaseerd op de OWASP Core Rule Set in detectie- of preventiemodus met aangepaste regels, uitsluitingslijsten en per-route-associatie in v2. Autoscaling en zoneredundantie worden ondersteund in v2.

Geavanceerde L7-patronen:

URL path-based routing: Routeer /api/* naar microservices en /images/* naar een statische origin of CDN, wat een ‘microservice fanout’ achter één VIP mogelijk maakt.
Multi-site hosting: Host contoso.com en fabrikam.com op één gateway met behulp van SNI-listeners en op host-headers gebaseerde regels. Nuttig voor consolidatie met sterke isolatie via WAF-beleidsregels per site.
SSL-termination: Offload TLS op de gateway voor centraal certificaatbeheer en WAF-inspectie. Gebruik end-to-end TLS (herversleuteling) wanneer backends versleuteling of validatie van clientcertificaten vereisen.

Azure Front Door biedt wereldwijde HTTP/HTTPS load balancing en acceleratie aan de ’edge’ met anycast, split TCP en POP-naar-origin-optimalisatie. Het is het meest geschikt voor internetgerichte apps die globale routing, edge WAF en optionele edge caching vereisen.

Wereldwijde load balancing: Routeert gebruikers naar de gezonde origin met de laagste latentie met behulp van ‘health probes’ vanaf meerdere POP’s. ‘Origin groups’ ondersteunen failover op basis van prioriteit en latentie, met sessieaffiniteit indien nodig.
WAF: Beheerde regels met botbescherming, aangepaste regels, geo/IP-filters, ‘rate limiting’ en per-route-associatie.
Caching: Met Front Door Standard/Premium is edge caching geïntegreerd; definieer cachinggedrag per pad, beheer de caching van query-strings en TTL’s, en offload statische content wereldwijd.
Health probes: Probes per ‘origin group’ (HTTP/HTTPS) met configureerbaar pad, interval en protocol vanaf diverse POP’s. Routeringsbeslissingen combineren gezondheid en latentie.

Gebruik Application Gateway voor regionale L7-behoeften (private backends, oost-west-verkeer, complexe ‘rewrites’) en Front Door voor globale L7, edge-beveiliging en acceleratie. Ze worden vaak gecombineerd: Front Door aan de ’edge’, Application Gateways per regio, en interne LB’s achter de gateways voor L4-services.

Traffic Manager (DNS-gebaseerd) en Azure CDN

Traffic Manager is een DNS-gebaseerde wereldwijde verkeersdistributie. Het fungeert niet als proxy voor het verkeer; in plaats daarvan retourneert het de DNS-naam/IP van een endpoint op basis van beleid en gezondheid, waarna clients rechtstreeks verbinding maken. De gezondheid wordt gecontroleerd vanaf gedistribueerde probes naar HTTP/HTTPS/TCP-endpoints; lage TTL’s verminderen de failover-latentie maar verhogen het volume van DNS-query’s.

Priority: Actief/passief failover. Plaats de primaire als eerste; Traffic Manager bedient deze tenzij deze ongezond is, en schakelt dan over naar de volgende prioriteit.
Weighted: Verdeel op basis van gewichten om geleidelijke overgangen of A/B-tests te ondersteunen.
Performance: Kies het endpoint met de laagste netwerklatentie van de regio van de gebruiker naar het endpoint.
Geographic: Routeer op basis van de geografische locatie van de gebruiker voor datasoevereiniteit of lokalisatie van content.
Multivalue: Retourneer meerdere gezonde endpoints voor dezelfde service om eenvoudige client-side failover te ondersteunen. U kunt profielen nesten voor hybride beleidsregels (bijv. geo bovenaan, vervolgens ‘weighted’ binnen een geografisch gebied). Gebruik Traffic Manager voor niet-HTTP-protocollen, services die geen voordeel halen uit edge-proxying, of wanneer u controle op DNS-niveau nodig heeft over heterogene endpoints (Azure, on-premises, derde partijen).

Azure CDN offloadt statische en cachebare content naar edge POP’s om de belasting op de origin en de latentie te verminderen.

Profiles: Containers voor een of meer endpoints die gekoppeld zijn aan een provider/tier (bijvoorbeeld de Microsoft-, Akamai- of Verizon-families). Profielen helpen bij het scheiden van omgevingen of kostenplaatsen.
Endpoints: Definieer origin-details (hostnaam, ‘origin host header’, protocol/poort) en de edge-hostnaam. U kunt meerdere endpoints per profiel hebben voor verschillende apps of contenttypes.
Cachingregels: Standaard en aangepaste regels beheren TTL’s, pad-gebaseerd gedrag, afhandeling van query-strings (doorsturen, negeren of elke unieke query cachen) en compressie. Gebruik regels om het cachen van assets met korte origin-TTL’s af te dwingen, of om caching voor dynamische API’s te omzeilen.
Custom domains: Koppel gebruiksvriendelijke hostnamen met door CDN beheerde TLS. Valideer het domeineigendom via CNAME en schakel HTTPS in met beheerde certificaten. Combineer indien nodig met geo-filtering of de ‘rules engine’.

Ontwerpkeuzes, cross-regionale integratie en het gedrag van health probes

Interne of externe load balancers worden geselecteerd op basis van de doelgroep en de route-exposure. Als de consumenten zich uitsluitend in privénetwerken bevinden, gebruik dan interne LB’s om publieke blootstelling te vermijden en het beheer van NSG’s te vereenvoudigen. Voor internetgebruikers of partners, gebruik publieke frontends. Voor uitgaande connectiviteit op schaal, geef de voorkeur aan NAT Gateway boven LB SNAT; reserveer uitgaande regels voor gevallen waarin de frontend van de LB SNAT moet leveren.

Cross-region Load Balancer integreert met regionale Standard Public Load Balancers om actieve-actieve, wereldwijde Layer 4-resilience te bereiken voor TCP/UDP-services. Plaats de publieke frontends van de regionale LB’s in de backend pool van de globale LB. Health probes op het globale niveau weerspiegelen de regionale beschikbaarheid; de routering stuurt het verkeer naar de gezonde regio met de laagste latentie en voert automatisch een failover uit als een volledige regio (of de regionale LB) ongezond wordt. Combineer dit met Front Door wanneer u ondersteuning voor beide protocollen nodig heeft (bijv. TCP-services via cross-region LB en HTTP/S via Front Door) onder afzonderlijke VIP’s.

Health probes zijn de bron van waarheid voor failover:

TCP-probes: Werken voor elke TCP-service. Een voltooide 3-way handshake wordt als succes gemarkeerd. Geschikt voor SQL, SMTP of aangepaste TCP-protocollen.
HTTP/HTTPS-probes: Valideren de gezondheid op applicatieniveau door een pad op te vragen en een statuscode 200–399 te verwachten. Ze maken aanpassing van host/pad mogelijk en kunnen onderscheid maken tussen gedeeltelijke app-storingen. HTTPS-probes verifiëren de TLS-onderhandeling, maar niet de geldigheid van het certificaat na de handshake; gebruik de juiste host-headers voor virtueel gehoste apps.
Drempels voor ongezonde status: Azure Load Balancer markeert een backend als ‘down’ na N opeenvolgende mislukte probes (configureerbaar; de standaardintervallen zijn kort om failover te versnellen). Application Gateway en Front Door voeren probes uit vanaf meerdere locaties en beschouwen een ‘origin’ als ‘down’ wanneer er voldoende opeenvolgende fouten zijn verzameld over hun set van probes. Herstel vereist opeenvolgende successen. Stem het interval en de drempelwaarde af om een balans te vinden tussen gevoeligheid en ‘flapping’; zorg ervoor dat probes een lichtgewicht, afhankelijkheidsbewust eindpunt bereiken.

Praktisch probleemscenario

Adobe moet een multi-region SaaS, bestaande uit web-frontends, microservices en een SQL Server Always On availability group, wereldwijd beschikbaar maken met strikte beveiliging, snelle failover en lage latentie voor gebruikers wereldwijd. Ze bieden ook een legacy TCP-gebaseerde telemetrie-ingestieservice aan.

Plaats Azure Front Door Standard aan de ’edge’ met een WAF-policy en routes voor www.adobe.com en api.adobe.com. De ‘origins’ zijn Application Gateways in East US en West Europe, gegroepeerd met op latentie gebaseerde routering en failover op basis van prioriteit.

Waarom: Front Door biedt wereldwijde anycast, edge WAF en optionele caching om internetverkeer via HTTP/S te versnellen en te beveiligen; het kiest automatisch de dichtstbijzijnde gezonde regio.

Implementeer Application Gateway v2 met WAF in elke regio. Configureer multi-site listeners met SNI voor beide hostnamen, URL path-based routing naar microservices en aangepaste health probes naar /healthz op elke service. Schakel end-to-end SSL in met een backend host override naar de FQDN’s van de services.

Waarom: Application Gateway biedt regionale L7-routering, WAF-inspectie dicht bij de app, path-based fanout en per-route policies; het maakt veilig verbinding met private backends en handelt header-herschrijvingen/redirects af.

Implementeer een interne Standard Load Balancer in elke regio voor de SQL AG-listener. Configureer een statische private frontend, een TCP-health probe naar de probe-poort van de Windows Failover Cluster en een load-balancing-regel met Floating IP ingeschakeld naar de listener-poort.

Waarom: De SQL-listener vereist L4 met ‘direct server return’. Floating IP behoudt de semantiek van de bestemming, en een TCP-probe weerspiegelt nauwkeurig het eigendom van de AG. Dit weerspiegelt de bekende vereiste dat HTTP-probing op poort 1433 ongeldig is.

Gebruik Azure Front Door cachingregels voor de statische webassets op /static/* met een lange TTL en revalidatie. Zet daarnaast een Azure CDN-profiel en -eindpunt op voor grote mediadownloads op downloads.adobe.com, met pad-specifieke caching en variatie op basis van query-strings.

Waarom: Caching met Front Door vermindert de latentie voor essentiële statische webcontent, in lijn met de edge-routering, terwijl een toegewijd CDN-eindpunt de levering van grote objecten en de onafhankelijkheid van het cachebeleid voor downloads optimaliseert.

Publiceer de legacy TCP-telemetrie-ingestie via een regionale Standard Public Load Balancer in elke regio, en plaats er een Cross-region Load Balancer voor als de enige publieke VIP. Configureer globale probes naar elke regionale LB en gebruik routering op basis van latentie.

Waarom: De service is TCP, niet HTTP; Cross-region Load Balancer levert wereldwijde actieve-actieve L4 met automatische failover en selectie van de regio met de laagste latentie.

Voeg Azure Traffic Manager met Priority-policy toe, uitsluitend voor een extern SFTP-eindpunt van een partner dat buiten Azure wordt gehost, met vermelding van het primaire eindpunt van de partner en een in Azure gehost back-upeindpunt.

Waarom: Traffic Manager is op DNS gebaseerd en kan externe eindpunten omvatten; het levert eenvoudige actieve/passieve failover voor niet-HTTP- en externe doelen waar proxying niet wenselijk is.

Koppel voor uitgaande connectiviteit vanuit app-subnets een NAT Gateway en verwijder de afhankelijkheid van LB outbound SNAT. Monitor de resultaten van de probes en de statistieken van LB/App Gateway/Front Door in Azure Monitor en stem de probe-intervallen/drempels voor ongezonde status af om ‘flapping’ te elimineren.

Waarom: NAT Gateway schaalt uitgaand verkeer betrouwbaar zonder uitputting van SNAT-poorten; nauwkeurige afstemming van health probes leidt tot sneller en stabieler failover-gedrag over de verschillende lagen heen.

← Azure Virtual Networking · Alle domeinen · Azure Storage →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →