Load Balancing — Choosing the Door

Picture a large venue on a busy night. Out on the motorway, long before you arrive, a road sign points you toward the nearest open site — it never sees your car, it only tells you where to go. At the site, a global entrance greets everyone, caches the cloakroom tickets so repeat visitors breeze through, and waves you to the nearest gate. Inside, an usher reads your ticket and sends you to the right section by what is printed on it. And at each section, a simple turnstile just counts bodies through whichever lane is free. Four different helpers, four different jobs — and Azure's traffic services map onto them almost exactly.

The four are Azure Load Balancer, Application Gateway, Front Door, and Traffic Manager. Newcomers memorise four separate product pages and stay confused. Professionals hold a single small grid, because every one of these answers the same two questions differently.

The grid

Two axes decide almost everything: scope — does it work globally, across regions, or only within one region — and layer — does it move packets blindly at Layer 4, or read the HTTP request at Layer 7.

Place the four on that grid and the confusion evaporates. Load Balancer is regional and Layer 4 — the turnstile. Application Gateway is regional and Layer 7 — the usher. Front Door is global and Layer 7 — the global entrance with the cloakroom cache. Traffic Manager is global but works at DNS, before any packet arrives — the motorway sign. Learn the grid, not the brochures, and picking the right one becomes a two-question decision rather than a memory test. This half of the class works the two regional cells; Part II opens the global two.

The layer axis is the one people fudge, so state it plainly. Layer 4 works at the level of TCP and UDP: it sees an incoming connection as an address and a port, and forwards it — fast, cheap, and utterly indifferent to what the traffic contains. Layer 7 works at the level of the HTTP request itself: it can read the URL path, the host header, the cookies, and decide where to send the request based on what it actually is.

Layer 4 — the turnstile

Distributes by connection, on IP and port. It cannot tell a request for /images from one for /checkout because it never looks. Blazingly fast, protocol-agnostic, no HTTP smarts.

Layer 7 — the usher

Reads the request. It can route /api to one pool and /images to another, terminate TLS, rewrite headers, and inspect content for attacks — at the cost of doing more work per request.

The consequence for design: if you need to route or protect traffic by what the request says — path-based routing, host-based routing, a web firewall — you need Layer 7, which means Application Gateway or Front Door. If you only need to spread raw connections across a set of machines and the content is irrelevant or not even HTTP, Layer 4 Load Balancer is the leaner tool. Reaching for Layer 7 when Layer 4 would do adds cost and latency for smarts you never use; reaching for Layer 4 when you needed to route by URL leaves you unable to do the one thing the job required.

Inside the turnstile: four parts, one path

Choosing Load Balancer is one decision; wiring one is four named parts, and the portal blades present them in exactly this order. A frontend IP configuration is the address the world dials — public for internet traffic, private for tier-to-tier work inside the VNet. A load-balancing rule ties that frontend, on a port, to a backend pool: the set of VM network interfaces the connections spread across. And a health probe decides, interval by interval, which pool members are actually eligible — an instance that fails the probe is not removed from the pool, merely skipped until it answers again. Frontend to rule to pool, with the probe as gatekeeper: every load balancer you will ever debug is these four parts, and the fault is usually in the last of them, which is why Part II's own health-probe section matters as much as it does.

One reality check before you build one. The Standard SKU — the only choice now that Basic retired in September 2025 — is secure by default: a VM behind a Standard load balancer receives nothing, probe traffic aside, until an NSG on its subnet or NIC explicitly allows the port. Wire the frontend, fill the pool, forget the NSG, and you have hung a door on a wall — the turnstile spins while the Class Ten fence behind it stays shut. A healthy fraction of "the load balancer isn't working" tickets are exactly this, and the fix is a rule, not a rebuild.

How the turnstile chooses a lane

Once the pool is healthy, one decision remains: how the load balancer maps an arriving connection to a specific member. By default it hashes a five-tuple — source IP, source port, destination IP, destination port, and protocol — and sends the connection to whichever member the hash lands on. Because the source port changes with every new connection, successive requests from the same client scatter across the pool. That is exactly what you want when the backends hold no per-user state: the load spreads as evenly as the arithmetic allows.

Some workloads cannot tolerate that scatter. A legacy app that keeps a shopping cart in local memory needs every request from one client to return to the same machine, or the cart vanishes mid-checkout. For those, you narrow the hash — session persistence, which Load Balancer offers in three settings.

None — five-tuple

The default. Each connection is placed independently, spreading load most evenly. Right for stateless backends, which is the design you should be aiming for anyway.

Client IP — two-tuple

Hashes on source and destination IP only, so every connection from one client address returns to the same member. The crutch for backends that keep session state locally.

Client IP and protocol — three-tuple

Adds the protocol to the two-tuple. A middle setting: sticky per client and protocol, still coarser than the default's even spread.

Persistence is a compromise, not a feature to reach for. The moment you pin a client to a member you trade even distribution for stickiness: one heavy client now loads a single node, and that node's failure drops that client's session outright rather than merely rebalancing it. The durable fix is the Class Eleven advice — push session state out to a shared store, keep the default five-tuple, and turn on affinity only when an application you cannot change forces your hand.¹

Application Gateway is the regional Layer 7 option: it lives inside your VNet, in one region, and distributes HTTP traffic to backends there by path or host. Its most valuable feature is the one worth a section of its own — the Web Application Firewall.

WAF

A Web Application Firewall — rules that inspect the content of each HTTP request and block common web attacks, such as SQL injection and cross-site scripting, before they ever reach your application.

This is a different kind of fence from the NSG of Class Ten. An NSG decides whether a connection is allowed by address and port; it cannot see that an allowed request carries a malicious payload in its body. A WAF reads the request and recognises the attack itself — the injection string, the script tag — and refuses it. The two layer together: the NSG controls who may knock, the WAF inspects what they are carrying. Neither replaces the other.

What Layer 7 actually buys: TLS termination and real routing

Reading the request is not one feature but a handful, and each earns the gateway its keep. Because Application Gateway terminates the connection, it can perform SSL/TLS termination — decrypting HTTPS at the gateway so the certificate lives in one managed place instead of on every backend, and the backends are spared the CPU cost of the handshake. Where a rule forbids plaintext on the wire even inside the VNet, the gateway can re-encrypt on the way to the pool — end-to-end TLS — and still inspect the request in the clear in between.

Routing itself is assembled from named parts, and their order is the model to hold. A listener catches traffic on a frontend IP, port, and protocol; a multi-site listener keys on the host header, which is how one gateway fronts several domains at once. A routing rule ties that listener to a backend, and a URL path map lets it split by path — /api/* to one pool, /images/* to another. An HTTP setting then governs how the gateway talks to that pool: port, protocol, cookie-based affinity, timeouts.

Listener

Where traffic is caught — frontend IP, port, protocol. A multi-site listener matches on the host header, so one gateway can serve many sites.

Routing rule + path map

Sends a listener's traffic to a backend pool, optionally splitting by URL path — the path-based routing Layer 4 cannot do, because it never reads the path.

Backend pool

The targets: VMs, scale sets, App Services, or bare IPs. Membership is judged by the gateway's own health probe, exactly as the turnstile judges its pool.

HTTP setting

How the gateway reaches the pool — port, protocol, session affinity, and whether traffic is re-encrypted for end-to-end TLS.

The firewall has two moods

The WAF does not have to block to be useful. In Detection mode it logs what its rules would have caught but lets everything through — the setting you run first, so you learn which legitimate requests the rules would wrongly reject before a false positive costs you a customer. In Prevention mode it actually blocks. The rules come from the OWASP Core Rule Set — a managed, versioned ruleset Microsoft maintains — plus any custom rules you add for your own patterns. Switching straight to Prevention without a spell in Detection is how a firewall becomes the outage it was meant to prevent: one false positive on the checkout path blocks real orders, and the graph looks exactly like the attack you were guarding against.²

Application Gateway with WAF is the right tool when the traffic is regional — and that includes being the public front door of an app serving a single geography, just as much as the internal cases: a line-of-business app served to staff, an admin console that never needs a global edge. It sits in the VNet, close to its backends, applying its rules in-region. For Campux that describes the internal admin application exactly, which is why the Gateway stays in the design even after the storefront moves to something bigger — the subject Part II opens with.