Load Balancing & Traffic

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.

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.

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.

Application Gateway with WAF is the right tool when the traffic is regional and internal — 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.

For a public website, the modern default is Front Door. It is the global Layer 7 service: traffic enters at Microsoft's edge locations around the world — hundreds of them — and is routed to the nearest healthy backend region, with a content cache and a web firewall built in at that same edge.

Three things make it the standard choice for web today. It is global, so a visitor in another continent enters at an edge near them rather than crossing the planet to your region. It caches static content at the edge, so images and scripts are served close to the user and never trouble your origin — the CDN behaviour folded in. And it carries a WAF at the edge, so attacks are absorbed far from your application, along with the platform's DDoS protection.¹ A request for a cached product image may be answered entirely at the edge, thousands of kilometres from the storefront, in a few milliseconds.

The distinction from Traffic Manager is the one interviews probe, so hold it precisely. Front Door is in the data path: traffic flows through it, so it can cache, inspect and route on content. Traffic Manager works at DNS: it answers the question "which address should this name resolve to" and then steps out of the way — it never sees the traffic, cannot cache, cannot inspect.² Traffic Manager is the motorway sign; Front Door is the entrance you actually walk through. Choose Traffic Manager when you need DNS-level direction across endpoints of any protocol; choose Front Door when you want a global HTTP front door that does real work on the request.

Every one of these services sends health probes to its backends and stops sending traffic to any that fail. This is the mechanism that turns a pool of machines into something resilient — and it is also the single most commonly misconfigured thing in the whole topic.

Health probe

A periodic request the load balancer makes to each backend to decide whether it is fit to receive traffic. Its worth depends entirely on whether the thing it checks reflects the thing that matters.

A probe that always says healthy is blind.

Here is the classic failure. A probe is pointed at the site's home page, or a bare / that returns a static "200 OK" no matter what — and it dutifully reports every instance healthy even while the application behind it cannot reach its database and is failing every real order. The load balancer, seeing green, keeps routing customers to a broken machine. The probe was answering "is the web server process running?" when the question that mattered was "can this instance actually serve a request?"

The fix is a probe that tells the truth: a dedicated health endpoint that checks the app's real dependencies — its database, its critical downstream services — and returns unhealthy when any of them is down, so the load balancer pulls the instance out before a customer hits it. Configure the probe to reflect readiness, not mere aliveness, and set the thresholds so a blip does not eject a healthy node nor a real failure linger. A load balancer is only as honest as its probe; a probe that cannot fail is a light that is painted green.