Four doors, one decision
A customer needs the correct entrance to the shop. A road sign tells them where to go; the person at the entrance handles the arrival; a receptionist can read the request and send it to the right desk. DNS routing, transport load balancing and HTTP routing make different decisions too. The comparison is a memory aid. Follow an actual lookup, connection and HTTP request to see which service can inspect which information.
Front Door and Traffic Manager solve global entry and DNS selection problems covered in Part II. The four services differ in where they run and what they process; the diagram is a comparison aid, not a rule that every application needs exactly one.
- The grid
- Ask where the service runs and what it handles. Load Balancer handles TCP/UDP connections (Layer 4); Application Gateway and Front Door handle HTTP requests (Layer 7); Traffic Manager answers DNS lookups, not Layer 4 traffic.
Load Balancer is regional and handles connections. Application Gateway is regional and handles HTTP requests. Front Door handles HTTP at a global edge. Traffic Manager returns a DNS answer and does not carry the request. These are starting points. Compare the backend's reachability, availability target, security controls, and cost before choosing.
B. Ask where it works and what it handles. Load Balancer processes connections, Application Gateway and Front Door process HTTP, and Traffic Manager answers DNS. DNS is a third mechanism here, not another form of Layer 4 forwarding.
B. DNS resolution happens before a single packet of the actual request is sent — Traffic Manager answers "which address does this name mean right now" and then steps aside. It never sees the request, so it cannot read HTTP (A), forward packets (C), or cache anything (D); those all require sitting in the path of the traffic, which the motorway sign never does.
Layer 4 and Layer 7, honestly
Before the layer numbers, the three things that happen when someone opens a shop page. First a DNS lookup: the browser asks what address shop.example lives at, and gets a number back. Then a connection: the browser opens a TCP connection to that address on port 443, like dialling a number and hearing it pick up. Only then the request: over that open line it sends an HTTP message such as GET /images/jacket.jpg. Each Azure door makes its decision at one of these three moments.
Layer 4 handles TCP or UDP using network addresses and ports. It does not parse the HTTP path. Layer 7 handles an HTTP request, so it can use a URL path or host name when choosing a backend. Traffic Manager is different again: it answers DNS before the application connection starts.
- 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.
If the requirement mentions URL paths, host names, or a web application firewall, shortlist a Layer 7 service. If you only need to distribute TCP or UDP connections across VMs in one region, shortlist Load Balancer. Check the actual service price and traffic behavior rather than assuming one is always faster or cheaper.
Inside the turnstile: four parts, one path
A Load Balancer needs four pieces. The frontend IP is the address clients call; it can be public or private. A rule maps its protocol and port to a backend pool of VM or scale-set instances. A health probe checks which pool members may receive new connections. A failed member stays configured in the pool but is skipped until it becomes healthy. When traffic fails, check all four pieces and the network rules rather than assuming the probe is at fault.
For a public Standard Load Balancer, backend inbound traffic needs an appropriate network security group (NSG) allow rule on the subnet or NIC. A healthy probe does not prove user traffic can pass the NSG. The default AzureLoadBalancer NSG rule permits probe traffic, while the default deny rule blocks other unsolicited internet traffic. Use the smallest source and port range that meets the application requirement.3
How the turnstile chooses a lane
By default, Load Balancer uses a five-tuple hash: source IP and port, destination IP and port, and protocol. Connections from one client can land on different members when the tuple changes. It does not promise perfectly even traffic, especially when connections have very different durations or sizes.
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.
Source-IP affinity can keep connections from the same visible IP on one backend. It does not identify a person: many users behind one NAT or proxy may share that IP and overload one VM. A failed VM still loses any cart kept only in its memory. For a durable web design, put session data in a shared store; use source-IP affinity only as a tested interim measure for an app you cannot yet change.1
Application Gateway and the firewall that reads
Application Gateway is a regional Layer 7 service deployed in a VNet. It can route HTTP by path or host name to reachable backends, including backends outside that VNet when network connectivity allows. Its WAF capability requires a WAF SKU and an enabled policy; a Standard gateway does not automatically inspect attacks.4
- WAF
- A Web Application Firewall uses rules to inspect HTTP requests for known attack patterns. In Detection mode it records matches; in Prevention mode it can block them. It complements application security and needs tuning.
This differs from an NSG. The NSG allows or denies traffic by network information such as source, destination, protocol, and port. A WAF can evaluate HTTP fields and request content against rules. Neither guarantees that the application is free of vulnerabilities, and a WAF in Detection mode does not block.
What Layer 7 actually buys: TLS termination and real routing
Application Gateway can terminate HTTPS at its listener, then connect to a backend over HTTP or HTTPS. If the backend path must remain encrypted, configure and validate HTTPS to the backend as well. Termination lets the gateway inspect the request; it does not make certificate and backend security work disappear.
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.2
Application Gateway with WAF is a candidate when a regional HTTP entry point needs path routing and request inspection. A public audience can still reach it from elsewhere; the gateway itself remains in one region. For Campux's internal admin app, verify whether those features justify a gateway and whether private-only access is required. Part II examines the global alternatives.
The deploy that stopped meaning downtime
A single instance is pegged at 100% while its twin sits idle, because nothing is spreading the traffic. You put a load balancer in front, health-probe the pool, and watch the graph flatten. Then you add a second instance and the app keeps serving straight through a node reboot — the first time a deploy stops meaning downtime for anyone.
Play it through
Four minutes, one sort and one decision. Match four kinds of traffic to their door — a wrong one bounces back and says why — then decide whether a payments microservice even needs a firewall watching it. It plays on its own and stops when it needs your hands.
Trace lookup, connection and request
Use the fictional evidence below. This is a desk exercise; it does not provision Azure resources or measure a live service.
Lookup: shop.example → an endpoint Connection: TCP 443 Request: GET /images/jacket.jpg
Mark which step a DNS traffic service answers.
Mark where a transport load balancer makes a connection-level decision.
Identify which layer must read /images/ to route by that path.
On your own: the shop adds /api/orders, which must go to a different backend in the same region. Which of the four doors can do that, and which moment does it act on?
Check your reasoning after you finish
DNS returns an answer rather than forwarding the HTTP request. A transport load balancer does not route by /images/. Path routing needs an HTTP-aware service such as Application Gateway or Front Door, chosen for the deployment scope. The same holds for /api/orders: it is a path, so it is decided at the request, and for one region Application Gateway is the usual fit.
Examination
Four drills, then two situations. Write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
A. Azure Load Balancer distributes regional TCP connections. Application Gateway and Front Door process HTTP, which this workload does not send. Traffic Manager returns a DNS answer and never distributes these connections itself. Check the network rules and probe as part of the design.
B. Application Gateway handles regional HTTP path routing and TLS termination. To inspect attacks, choose a WAF-capable SKU and configure the policy. Load Balancer cannot read a URL, Front Door's global edge is not a stated requirement, and Traffic Manager only answers DNS.
Detection mode, the OWASP Core Rule Set, and reading the request's content. Those are the WAF's real job. The two wrong answers describe other services wearing a disguise: answering at DNS before a packet arrives is Traffic Manager, and caching static content at the edge is Front Door's job, not a regional gateway's. A WAF inspects what is already in front of it; it does not resolve names or hold a cache.
Standard Load Balancer — frontend to pool
1. Frontend IP: 20.51.4.20 : 443 (public)
2. Load-balancing rule: 443 → 443, TCP
3. Backend pool: 3 VMs, all passing their probe
4. Health probe: GET /health, 15s interval
C. For this public Standard Load Balancer, an NSG must allow inbound user traffic on the backend port. The default AzureLoadBalancer rule can let the probes pass while the default inbound deny still blocks internet clients. Verify effective NSG rules on both subnet and NIC; a healthy probe alone does not prove the path is open.
Name the mismatch first. The default five-tuple hash spreads connections evenly, including across requests from the same client, because the source port changes with every new connection. A cart kept in one VM's memory needs every request from that shopper to land back on the same VM — the default setting makes no such promise, so carts will vanish mid-checkout the moment a request lands on a different machine than the one holding the state.
For an interim fix, test source-IP affinity. Client IP or Client IP and protocol can keep connections from one visible IP on one member while it stays healthy. It cannot identify a shopper: people behind the same proxy or NAT may share an IP and become pinned together.
Fix the cart design. A failed VM still loses any cart stored only in its memory. Move the cart to a shared store accessible from every app instance, test failover, and then use the default five-tuple unless another measured requirement calls for affinity.
Rule out the shared parts first. The listener catches every request on this gateway regardless of path, and it is plainly healthy — every other route answers. So the fault sits in something wired only to /reports/*, which points straight at the path map entry that was added last week and whatever it points to.
Follow that one path map entry to its own backend pool and HTTP setting — the two things a new rule brings with it that no other path shares. Check first whether the backend pool named for /reports/* actually contains members, and whether those members are passing the gateway's own health probe; a pool with no healthy members answers exactly this way, while paths pointed at a healthy pool keep working.
If the pool is healthy, look at the HTTP setting next — the port and protocol the gateway uses to reach that pool. A setting built for the wrong port, or expecting HTTPS from a backend that only serves HTTP, produces the same silent failure: the gateway forwards the request faithfully and the pool never answers it in a way the gateway can pass back. Whichever part turns up wrong, the diagnosis is finding the one piece a single new rule owns, not touching the listener that was never broken.
Five things worth carrying out of this class
- Ask where a service runs and what it handles: Load Balancer handles connections, Application Gateway and Front Door handle HTTP, and Traffic Manager answers DNS.
- Layer 4 forwards connections blindly and fast; Layer 7 reads the HTTP request and can route, terminate TLS, and inspect it.
- A load balancer's four parts are frontend IP, rule, backend pool, and health probe — and the Standard SKU admits nothing until an NSG says so.
- Application Gateway is regional Layer 7. WAF protection requires a WAF SKU and policy; its backends can be elsewhere if reachable.
- Session persistence trades even load for stickiness. Treat it as a bridge for software you cannot change, not a destination.
- Microsoft's distribution-mode guide defines the five-, two-, and three-tuple options. Source-IP affinity groups users sharing a NAT or proxy and does not preserve a session after its VM fails. ↩
- Start a WAF policy in Detection when evaluating a new ruleset. Review real traffic and false positives, then test Prevention before relying on it. Confirm the configured ruleset version in the current Application Gateway WAF documentation. ↩
- Microsoft documents Standard Load Balancer's default inbound posture and the NSG default probe allowance. ↩
- Microsoft distinguishes Standard_v2 and WAF_v2, and its FAQ allows reachable backends outside the gateway VNet. ↩
Pick the right front door for a workload from four candidates, and say why the others lose.
Play the lesson above to stamp this class.