Microsoft AZ-104: Azure Load Balancing and Traffic Management — Study Guide

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

Part of the Microsoft Azure Administrator Associate AZ-104 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure offers a layered portfolio for distributing and protecting traffic: Azure Load Balancer (Layer 4, TCP/UDP), Application Gateway (Layer 7, HTTP/S), Azure Front Door (global Layer 7 edge), Azure Traffic Manager (DNS-based), and Azure CDN (edge caching). Each targets a specific segment of the request path—from global DNS decisioning and edge POPs to regional HTTP routing and private, east-west traffic. Mastery comes from selecting the right service for the protocol and audience, composing them properly, and configuring health probes and rules that drive reliable failover.

Azure Load Balancer (L4): SKUs, building blocks, NAT/outbound, and floating IP

Standard Load Balancer is the production-grade L4 load balancer. It is zone-aware/zone-redundant, supports HA Ports, advanced diagnostics/metrics, secure-by-default (no inbound unless you define rules), configurable outbound rules, and large backend scale. Basic is a legacy SKU with limited scale/features and no zone redundancy; it is on retirement path and should not be chosen for new workloads.

Core components define how traffic flows:

Frontend IP: The VIP exposed to clients. External LBs use a Public IP or Public IP Prefix; internal LBs use a private static IP from a subnet. Standard supports multiple frontends and zone-redundant public IPs.
Backend pool: NICs, IP configurations on NICs, or VM scale set instances in the same region/VNet. A single pool can serve many rules. Standard supports cross-zone backends within a region.
Health probes: Determine which backend instances are healthy. TCP probes complete a handshake; HTTP/HTTPS probes make a GET to a path and consider 200–399 as success. You control protocol, port, path (for HTTP/S), interval, and unhealthy threshold (consecutive failures before marking down).
Load balancing rules: Tie a frontend (IP/port/protocol) to a backend pool and health probe. Rule settings include backend port, protocol (TCP/UDP), session persistence, idle timeout, and Floating IP (Direct Server Return).

Inbound NAT rules are per-VM translations that forward a specific frontend port to a single backend NIC/port (for example, expose RDP or SSH to one VM without load balancing). They don’t use the health probe and are not a scale-out mechanism.

Outbound rules define SNAT behavior for Standard Load Balancer backends initiating connections to the internet via the LB’s public frontends. They allow you to control which frontend(s) supply SNAT ports and how many ports per backend instance are allocated, helping avoid SNAT port exhaustion under high outbound concurrency. If a NAT Gateway is attached to the subnet, it supersedes LB SNAT; prefer NAT Gateway for consistent, scalable outbound.

Floating IP (Direct Server Return) is a rule option used when the destination IP/port must be preserved end-to-end. It is required for clustered scenarios such as SQL Server Always On availability group listeners. For SQL AG, use an internal Standard Load Balancer with a TCP probe (not HTTP) to the cluster’s probe port and enable Floating IP on the LB rule; do not probe port 1433 with HTTP, as SQL is not an HTTP workload.

Internal vs external load balancers hinge on the audience and security boundary. Use an internal LB when exposing a private VIP inside a VNet or via private connectivity (VPN/ExpressRoute) for line-of-business apps, databases, and NVAs. Use an external LB for internet-facing L4 services. For internal LBs, assign a static private frontend in the target subnet; for external LBs, bind a Standard Public IP and optionally use multiple frontends.

Cross-region Load Balancer provides global, anycast Layer 4 load balancing across regions. You deploy Standard Public Load Balancers in each region (regional tier) and place their public frontends into the backend of a single global Load Balancer (global tier). The global LB uses health probes to each regional LB and directs clients to the closest healthy region (by latency) with flow symmetry based on 5‑tuple hashing. It’s TCP/UDP only—no TLS termination—and complements regional L7 gateways.

Application Gateway (L7) and Azure Front Door (global L7)

Application Gateway is a regional Layer 7 reverse proxy with WAF. It terminates HTTP/HTTPS, inspects headers and paths, and routes to private or public backends.

Key Application Gateway constructs:

Listeners: Bind a frontend IP/port/hostname and SSL settings to accept traffic. SNI enables multiple TLS sites per IP. Use basic listeners for single-site, multi-site listeners for host-based routing, and wildcard hosts for broad coverage.
Routing rules and HTTP settings: Rules map listeners to backend pools and specify the HTTP settings applied to backends (protocol, port, host header override, cookie-based affinity, connection draining, request timeout). You can redirect, rewrite headers, or route based on URL path segments.
Backend pools: Targets can be NIC IPs, FQDNs, app services, or VM scale sets. Custom health probes check specific paths/hosts and honor success status codes.
WAF: OWASP Core Rule Set–based protection in detection or prevention mode with custom rules, exclusion lists, and per-route association in v2. Autoscaling and zone redundancy are supported in v2.

Advanced L7 patterns:

URL path-based routing: Route /api/* to microservices and /images/* to a static origin or CDN, enabling microservice fanout behind one VIP.
Multi-site hosting: Host contoso.com and fabrikam.com on one gateway using SNI listeners and host header–based rules. Useful for consolidation with strong isolation via WAF policies per site.
SSL termination: Offload TLS on the gateway for central certificate management and WAF inspection. Use end-to-end TLS (re-encryption) when backends require encryption or client-certificate validation.

Azure Front Door provides global HTTP/HTTPS load balancing and acceleration at the edge with anycast, split TCP, and POP-to-origin optimization. It is best for internet-facing apps requiring global routing, edge WAF, and optional edge caching.

Global load balancing: Routes users to the lowest-latency healthy origin using health probes from multiple POPs. Origin groups support priority and latency-based failover, with session affinity if needed.
WAF: Managed rules with bot protections, custom rules, geo/IP filters, rate limiting, and per-route association.
Caching: With Front Door Standard/Premium, edge caching is integrated; define caching behavior by path, control query-string caching and TTLs, and offload static content globally.
Health probes: Per-origin-group probes (HTTP/HTTPS) with configurable path, interval, and protocol from diverse POPs. Routing decisions blend health and latency.

Use Application Gateway for regional L7 needs (private backends, east-west, complex rewrites) and Front Door for global L7, edge security, and acceleration. They are commonly composed: Front Door at the edge, Application Gateways per region, and internal LBs behind gateways for L4 services.

Traffic Manager (DNS-based) and Azure CDN

Traffic Manager is DNS-based global traffic distribution. It does not proxy traffic; instead, it returns an endpoint’s DNS name/IP based on policy and health, leaving clients to connect directly. Health is checked from distributed probes to HTTP/HTTPS/TCP endpoints; low TTLs reduce failover latency but increase DNS query volume.

Priority: Active/passive failover. Put primary first; Traffic Manager serves it unless unhealthy, then fails to next priority.
Weighted: Distribute by weights to support gradual cutovers or A/B tests.
Performance: Choose endpoint with the lowest network latency from the user’s region to the endpoint.
Geographic: Route based on user’s geographic location for data sovereignty or content localization.
Multivalue: Return multiple healthy endpoints for the same service to support simple client-side failover. You can nest profiles for hybrid policies (e.g., geo at the top, then weighted within a geography). Use Traffic Manager for non-HTTP protocols, services that don’t benefit from edge proxying, or when you need DNS-layer control across heterogeneous endpoints (Azure, on-premises, third-party).

Azure CDN offloads static and cacheable content to edge POPs to reduce origin load and latency.

Profiles: Containers for one or more endpoints tied to a provider/tier (for example, Microsoft, Akamai, or Verizon families). Profiles help separate environments or cost centers.
Endpoints: Define origin details (hostname, origin host header, protocol/port) and the edge hostname. You can have multiple endpoints per profile for different apps or content types.
Caching rules: Default and custom rules control TTLs, path-based behavior, query-string handling (forward, ignore, or cache each unique query), and compression. Use rules to force caching of assets with short origin TTLs, or to bypass caching for dynamic APIs.
Custom domains: Map friendly hostnames with CDN-managed TLS. Validate domain ownership via CNAME and enable HTTPS with managed certificates. Combine with geo-filtering or rules engine as needed.

Design choices, cross-region integration, and health probe behavior

Internal vs external load balancers are selected by audience and route exposure. If consumers are only inside private networks, use internal LBs to avoid public exposure and simplify NSG control. For internet users or partners, use public frontends. For outbound connectivity at scale, prefer NAT Gateway over LB SNAT; reserve outbound rules for cases where the LB’s frontend must supply SNAT.

Cross-region Load Balancer integrates with regional Standard Public Load Balancers to achieve active-active, global Layer 4 resiliency for TCP/UDP services. Place the regional LBs’ public frontends in the global LB’s backend pool. Health probes at the global tier reflect regional availability; routing steers to the lowest-latency healthy region and fails over automatically if an entire region (or its regional LB) goes unhealthy. Combine this with Front Door when you need both protocol support (e.g., TCP services via cross-region LB and HTTP/S via Front Door) under separate VIPs.

Health probes are the truth source for failover:

TCP probes: Work for any TCP service. A completed 3-way handshake marks success. Suitable for SQL, SMTP, or custom TCP protocols.
HTTP/HTTPS probes: Validate application-level health by requesting a path and expecting 200–399. They allow host/path customization and can discriminate partial app failures. HTTPS probes verify TLS negotiation but not certificate validity beyond handshake; use correct host headers for virtual-hosted apps.
Unhealthy thresholds: Azure Load Balancer marks a backend down after N consecutive probe failures (configurable; default intervals are short to speed failover). Application Gateway and Front Door probe from multiple vantage points and consider an origin down when enough consecutive failures accumulate across their probe set. Recovery requires consecutive successes. Tune interval and threshold to balance sensitivity and flapping; ensure probes reach a lightweight, dependency-aware endpoint.

Practical Problem Scenario

Adobe needs to globally expose a multi-region SaaS composed of web front ends, microservices, and a SQL Server Always On availability group, with strict security, fast failover, and low latency for users worldwide. They also expose a legacy TCP-based telemetry ingestion service.

Place Azure Front Door Standard at the edge with a WAF policy and routes for www.adobe.com and api.adobe.com. Origins are Application Gateways in East US and West Europe, grouped with latency-based routing and priority failover.

Why: Front Door provides global anycast, edge WAF, and optional caching to accelerate and protect internet HTTP/S traffic; it chooses the closest healthy region automatically.

Deploy Application Gateway v2 with WAF in each region. Configure multi-site listeners with SNI for both hostnames, URL path–based routing to microservices, and custom health probes to /healthz on each service. Enable end-to-end SSL with backend host override to service FQDNs.

Why: Application Gateway offers regional L7 routing, WAF inspection close to the app, path-based fanout, and per-route policies; it securely connects to private backends and handles header rewrites/redirects.

Deploy an internal Standard Load Balancer in each region for the SQL AG listener. Configure a static private frontend, a TCP health probe to the Windows Failover Cluster probe port, and a load-balancing rule with Floating IP enabled to the listener port.

Why: The SQL listener requires L4 with direct server return. Floating IP preserves destination semantics, and a TCP probe accurately reflects AG ownership. This mirrors the known requirement that HTTP probing on port 1433 is invalid.

Back the web static assets with Azure Front Door caching rules for /static/* with a long TTL and revalidation, and also stand up an Azure CDN profile and endpoint for large media downloads at downloads.adobe.com with path-specific caching and query-string variation.

Why: Front Door caching reduces latency for core web static content inline with edge routing, while a dedicated CDN endpoint optimizes large-object delivery and cache policy independence for downloads.

Publish the legacy TCP telemetry ingestion via a regional Standard Public Load Balancer in each region, then front them with a Cross-region Load Balancer as the single public VIP. Configure global probes to each regional LB and use latency routing.

Why: The service is TCP, not HTTP; Cross-region Load Balancer delivers global active-active L4 with automatic failover and low-latency region selection.

Add Azure Traffic Manager with Priority policy only for an external partner SFTP endpoint hosted outside Azure, listing the partner primary and an Azure-hosted backup endpoint.

Why: Traffic Manager is DNS-based and can include external endpoints; it delivers simple active/passive failover for non-HTTP and third-party targets where proxying is not desired.

For outbound connectivity from app subnets, attach NAT Gateway and remove LB outbound SNAT reliance. Monitor probe outcomes and LB/App Gateway/Front Door metrics in Azure Monitor and tune probe intervals/unhealthy thresholds to eliminate flapping.

Why: NAT Gateway scales outbound reliably without SNAT port exhaustion; precise health probe tuning yields faster, stable failover behavior across layers.

← Azure Virtual Networking · All domains · Azure Storage →

Practice these questions → · Timed practice on ExamRoll.io →