Recommend a Load-Balancing and Routing Solution — Lesson

A large global retailer's checkout API runs across three Azure regions. The team's first deployment uses one regional Application Gateway per region fronted by Azure Traffic Manager (DNS-based) for global routing across the three regions. A regional outage takes roughly 4 minutes for traffic to fail over — long enough for thousands of users to retry, abandon, and complain on social media. The architect replaces Traffic Manager with Azure Front Door Premium using AnyCast at the global edge: the same regional App Gateways remain behind it, but global edge routing decisions now happen at the network layer rather than via DNS TTL caching. Regional failover now completes within seconds rather than minutes, and the customer complaints subside immediately. This lesson is about choosing the right load-balancing layer for each scope — L4 regional, L7 regional, L7 global, DNS global — and combining them in a layered stack so traffic always finds a healthy endpoint quickly, without operator intervention.

We will work through Azure's load-balancing story the way the AZ-305 exam expects you to: distinguish Azure Load Balancer (L4 regional, TCP/UDP) from Application Gateway (L7 regional with WAF) from Front Door (global L7 AnyCast) from Traffic Manager (DNS-level global routing), and pick the right combination for each workload. Reference: the AZ-305 exam study guide, particularly Chapter 4 Skill $4.4 on load-balancing, plus Microsoft Learn's load-balancing decision tree.

Why This Matters

Load balancing is where availability becomes user-experience and the difference between an invisible regional failover and a customer-visible outage. A correctly chosen load balancer survives backend failures invisibly to end users; a wrongly chosen one converts a one-instance failure into a customer-visible outage on social media within minutes. The AZ-305 exam tests this LO heavily because the four Azure load balancers serve overlapping but distinct purposes — and architects routinely mix them up, choosing Traffic Manager when Front Door would deliver $10\times$ faster failover, or App Gateway when a simple Standard LB would suffice.

The career payoff is concrete: every "how do we route global traffic?" workshop, every "this single VM is a bottleneck" review, every multi-region failover design, every WAF placement debate touches this LO at the architectural level.

Prerequisites

• L4 vs L7. Can you describe the difference? — Self-check: which can route by URL path?
• DNS vs IP-level routing. Are you familiar with the trade-off? — Self-check: which has a TTL that delays failover?
• Health probes. Do you know how each LB checks backend health? — Self-check: what's the typical interval?
• TLS termination. Can you describe where TLS terminates in each LB? — Self-check: which one passes TLS through end-to-end?
• Session affinity. Have you used it? — Self-check: what cookie does App Gateway add?

If any of these feels shaky, pause and review LO-26 (HA for compute), LO-45 (internet connectivity), and LO-47 (network performance) before continuing this lesson.

Learning Objectives

1. Analyse a load-balancing requirement (scope, layer, latency, routing rules, failover budget) and translate it to the right Azure service.
2. Evaluate trade-offs between Azure Load Balancer, Application Gateway, Front Door, and Traffic Manager, including cost and failover speed.
3. Recommend a global routing strategy choosing between AnyCast (Front Door) and DNS-level (Traffic Manager) based on failover-speed requirements.
4. Design a layered load-balancing stack (global $\to$ regional L7 $\to$ L4 $\to$ backend instances) that survives any single-region or single-zone failure.
5. Configure session affinity, health probes, TLS termination, and WAF policies correctly per service tier.
6. Recognise anti-patterns — Traffic Manager for fast failover on HTTP workloads, Basic LB still in production after retirement, missing or unhealthy health probes — and rewrite each one.

Building Blocks

Azure Load Balancer — L4 regional traffic distribution. Formally, Microsoft.Network/loadBalancers Basic / Standard SKU; Standard offers 99.99% SLA, zone-redundant or zonal frontends, HA Ports. Pure TCP/UDP. It matters as the foundation for VMSS and AKS internal load balancing.

Application Gateway — L7 regional load balancer with WAF, URL-based routing, TLS termination, session affinity. Formally, Microsoft.Network/applicationGateways v2 (Standard or WAF). 99.95% SLA zone-redundant. It matters for path-based routing inside a region, e.g., /api $\to$ APIs, /web $\to$ web app.

Azure Front Door — Global L7 AnyCast edge. Tiers: Standard / Premium / classic (retiring). 99.99% SLA. Includes WAF, caching, DDoS Protection. It matters because Front Door is the modern global-routing default — fast failover, AnyCast at edge.

Azure Traffic Manager — DNS-based global routing. Returns different DNS responses based on policy (performance, priority, weighted, geographic). 99.99% SLA on DNS resolution. It matters for non-HTTP workloads or where DNS-based routing is preferred (e.g., for services not behind HTTP).

Health probe — A periodic check the LB uses to determine backend health. Each LB has its own probe model. It matters because health probes drive failover timing and correctness.

Session affinity (sticky sessions) — A way to bind a user's session to one backend. L4 LB: source-IP affinity. L7 App Gateway: cookie-based. Front Door: cookie-based. It matters for stateful apps that store session data on the backend.

Backend pool — The set of targets behind the LB. Can be VMs (LB, App Gateway), App Services (App Gateway, Front Door), or IP addresses (App Gateway, Front Door). It matters because pool composition determines what the LB can route to.

TLS passthrough vs termination — Whether the LB terminates TLS or passes it through encrypted. App Gateway / Front Door terminate (decrypt, optionally re-encrypt to backend). Standard LB passes through unchanged. It matters for end-to-end encryption requirements.

HA Ports — A Standard LB feature that load-balances all ports / protocols to a single rule. Useful for NVAs and firewalls. It matters when balancing a single appliance fleet handling many protocols.

Deep Dive

1. The four load balancers — scope and layer

[!TIP] Default rule of thumb: HTTP traffic, default to Front Door (global) or Application Gateway (regional). Non-HTTP traffic, default to Load Balancer (L4). Traffic Manager fills the gap when DNS-level routing for non-HTTP is needed.

2. Standard LB vs Basic — Basic retiring

Production must use Standard. Migration tools exist; plan ahead of the retirement date.

3. Application Gateway features — L7 inside the region

4. Front Door — global AnyCast L7

Front Door routes via AnyCast at network layer — failover is near-instant on health probe failure. Compare to Traffic Manager (DNS), where failover waits for client cache to expire.

5. Traffic Manager — DNS routing

[!WARNING] Traffic Manager failover is bounded by DNS TTL + client DNS cache. Default TTL is 60 s; some clients ignore short TTLs entirely. For fast failover, use Front Door instead.

6. Combining services — layered architecture

Most enterprise stacks layer multiple LBs:

Each layer adds value: Front Door global edge; AppGW regional WAF + path routing; Standard LB cheap L4 distribution to compute. Smaller stacks collapse layers (e.g., Front Door directly to App Service).

7. Health probes — the silent reliability layer

Each LB probes backends differently:

Failover speed = probe interval × failure threshold + time-to-evict. Front Door's distributed probes from each POP give the fastest realistic failover.

8. Cost considerations

Approximate cost shape:

9. Cross-region active-active vs active-passive

Multi-region designs come in two flavours:

Front Door supports both via priority + weighted routing. For tier-1 services where every customer's traffic should land in the nearest region, active-active wins; for compliance-driven workloads with strict data residency, active-passive may be required.

[!TIP] Active-active works well for stateless tiers and Cosmos DB / GZRS / Azure SQL Failover Group backends. Active-passive is the right starting point for SQL workloads that aren't yet multi-write-ready.

10. Combining Front Door and Application Gateway

Front Door at the edge can route directly to backend pools (App Service, Storage, custom origins), but the most-defensible pattern for VNet-bound backends is to route to a regional Application Gateway via Private Link. This gives:

The split-of-responsibilities matters: Front Door's WAF filters known attack patterns at the edge before they consume regional capacity; App Gateway's WAF can apply custom rules tailored to the regional workload's semantics. WAF rules at both layers are not redundant — they cover different threat classes.

11. Routing methods in detail

Each LB supports specific routing methods. Memorise the matrix:

The exam tests "which LB supports method X?" — keep this matrix in mind.

12. Diagnosing load-balancer issues

Common failure modes and where to look:

[!WARNING] When migrating from Traffic Manager to Front Door, plan the cutover carefully: TM is DNS-resolved; clients cache results. Run both in parallel for 24 hours so cached TM responses expire naturally before retiring TM.

[!NOTE] The free Traffic Manager Real-User-Measurement (RUM) telemetry from end-user browsers can inform routing decisions in Performance routing mode — a useful addition for global services.

Worked Examples

Easy — internal L4 for VMSS

Problem. A VMSS of 20 VMs handles internal API traffic. Recommend.

Solution. Internal Standard Load Balancer. Place in the VNet; configure backend pool $=$ VMSS; health probe on the API port. No public exposure.

Medium — global API with regional backends

Problem. A public API hosted in 3 regions needs global low-latency routing with near-instant failover. Recommend.

Solution. Front Door Premium at global edge $\to$ regional Application Gateway WAF v$2$ $\to$ backend pool. Health probes from each Front Door POP detect regional failures within $\sim 30$ s; AnyCast routes around failures immediately.

Hard — multi-region with path-based routing and WAF

Problem. A SaaS has api/, web/, and admin/ paths, served globally. Admin should be geo-restricted. WAF required at edge and regional. Recommend.

Solution. Front Door Premium with WAF policy: geo-filter admin/ to allowlisted regions; OWASP managed ruleset on all paths. Front Door routes to one of two regional App Gateways (active-active across 2 regions), each with internal path-based routing for api/, web/, admin/. Internal traffic to App Services via Private Link. App Service has Standard LB inside its plan for instance-level distribution (managed by App Service).

13. App Service built-in load balancing

App Service plans have their own built-in instance-level load balancing — when you scale a plan to $N$ instances, App Service distributes traffic across them automatically without an external LB. This is sometimes overlooked: for many web workloads, an App Service plan plus deployment slots replaces App Gateway entirely.

For simple web workloads, the cheapest sensible stack is: App Service Premium v3 (zone-redundant) plus Front Door Premium. No additional App Gateway layer needed.

14. AKS load-balancer choices

Kubernetes workloads on AKS expose services via several Azure LB patterns:

Most production AKS workloads layer Front Door $\to$ Application Gateway Ingress Controller (AGIC) $\to$ AKS Service to combine global edge with Kubernetes-native Ingress declarations. AGIC keeps the Ingress rules in Kubernetes manifests while delegating the actual L7 traffic processing to a managed App Gateway, which Microsoft operates.

[!TIP] Use the Application Gateway Ingress Controller (AGIC) for AKS workloads where you want declarative Ingress in Kubernetes manifests while keeping App Gateway as the actual L7 implementation. This combines GitOps-friendly config with managed L7 features.

15. TLS configuration patterns

End-to-end TLS in a layered stack has several options:

For regulated workloads with explicit end-to-end encryption requirements, use end-to-end TLS. For most workloads, TLS termination at the edge with backend HTTP over private networks is acceptable and simpler.

16. Long-running connections — WebSockets and gRPC

WebSocket and gRPC connections are long-lived and require specific LB support to work end-to-end:

[!IMPORTANT] Long-lived connection workloads benefit from session affinity to avoid frequent reconnects. Configure Cookie-Based Affinity on App Gateway or session affinity on Front Door for WebSocket workloads.

Visual Explanations

Figure 1 — Decision flow

Figure 2 — Failover speed comparison

Figure 3 — Quick chooser

Common Mistakes

❌ Myth: "Traffic Manager gives the fastest global failover." ✅ Reality: Traffic Manager failover is bounded by DNS TTL. Front Door's AnyCast at the network layer gives much faster failover (seconds vs minutes).

❌ Myth: "Basic LB is fine for non-production." ✅ Reality: Basic is retiring. Use Standard everywhere; the cost gap is small.

❌ Myth: "App Gateway and Front Door are interchangeable." ✅ Reality: App Gateway is regional (within a VNet); Front Door is global edge. They serve different scopes and combine.

❌ Myth: "Health probes are an implementation detail." ✅ Reality: Probe configuration drives failover correctness and speed. Pick a probe path that genuinely reflects backend health (not just a 200 on /).

Practice Exercises

🟢 Exercise 1. An internal API hosted on 10 VMs needs L4 distribution. Recommend.

▶✅ Solution

Internal Standard Load Balancer.

🟡 Exercise 2. A public API with $/api$ and $/admin$ paths needs WAF and regional routing. Recommend.

▶✅ Solution

Application Gateway WAF v$2$ with URL path-based routing. Front Door optional for global edge.

🟡 Exercise 3. A non-HTTP SMTP service has 3 regional endpoints. Global failover needed. Recommend.

▶✅ Solution

Traffic Manager with Priority routing. Front Door is HTTP-only; Standard LB is regional only.

🔴 Exercise 4. A team uses Traffic Manager for HTTP traffic; failover during region outages takes $\sim 4$ minutes. Recommend.

▶✅ Solution

Replace with Front Door. AnyCast routes around failures at the network layer without waiting on client DNS cache.

🔴 Exercise 5. An NVA fleet (5 Palo Alto VMs) needs HA across all ports / protocols. Recommend.

▶✅ Solution

Standard LB with HA Ports rule. Single rule distributes all ports / protocols to the NVA pool.

🟢 Exercise 6. True or false: Front Door supports non-HTTP traffic.

▶✅ Solution

False. Front Door is HTTP/HTTPS only. Non-HTTP global routing requires Traffic Manager.

🟡 Exercise 7. Sketch Bicep for a zone-redundant Standard LB.

▶✅ Solution

bicepCopy

resource lb 'Microsoft.Network/loadBalancers@2024-03-01' = { name: 'lb-prod' location: location sku: { name: 'Standard' } properties: { frontendIPConfigurations: [ { name: 'fe', properties: { subnet: { id: subnetId }, privateIPAllocationMethod: 'Dynamic' }, zones: ['1','2','3'] } ] backendAddressPools: [ { name: 'be' } ] probes: [ { name: 'http', properties: { protocol: 'Http', port: 80, requestPath: '/health', intervalInSeconds: 5, numberOfProbes: 2 } } ] loadBalancingRules: [ /* rules */ ] } }

Figure 4 — Multi-region active-active topology

A canonical multi-region active-active for HTTP:

Front Door's health probes detect regional issues within roughly 30 seconds; AnyCast routes around them; users in each geography see the nearest healthy region without any visible delay.

Figure 5 — Hub-spoke with internal load balancing

For private-only internal workloads:

No Front Door, no Traffic Manager — entirely internal. This is the common pattern for B2B intranet workloads in regulated industries.

Figure 6 — Cost-vs-features comparison

A rough cost ranking at moderate traffic:

The right answer is consistently the cheapest service that genuinely fits the workload's requirements — not the most-featured one or the most-fashionable one in the marketing materials.

Summary & Concept Map

• Four LBs, four scopes. Standard LB (L4 regional), App Gateway (L7 regional), Front Door (L7 global AnyCast), Traffic Manager (DNS global).
• Front Door beats Traffic Manager for fast failover on HTTP workloads.
• App Gateway WAF v2 inside a region; Front Door Premium at the edge — combine for layered defence + routing.
• Basic LB retiring. Standard everywhere in production.
• Health probes drive failover correctness. Configure probe paths and intervals deliberately.
• HA Ports for NVA fleets.