Lesson 18 — Load Balancing in Azure

Why Load Balancing Is Always in the Exam

Azure has four distinct load balancing products: Azure Load Balancer, Application Gateway, Azure Front Door, and Traffic Manager. They are not interchangeable — each solves a specific problem at a specific OSI layer, with different geographic scope. The AZ-104 exam consistently tests whether you can pick the right product for a given scenario, and whether you understand how they can be layered together.

Senior engineers in real Azure environments face this decision constantly. A mistake here — using a Basic Load Balancer instead of Standard, or an Application Gateway when Traffic Manager is needed — can mean production downtime, security exposure, or failed availability zone redundancy. This lesson gives you the complete decision model.

1. The Four Load Balancing Services

Each Azure load balancing service addresses a different combination of OSI layer, geographic scope, and protocol support:

2. Azure Load Balancer

Azure Load Balancer operates at Layer 4. It distributes inbound TCP and UDP flows across backend pool members based on a configurable hash algorithm. It does not inspect, decrypt, or modify the packet payload — it only sees IP addresses and ports.

SKUs — Standard vs. Basic

Core components

Session persistence (sticky sessions)

By default, Azure Load Balancer uses a 5-tuple hash (source IP, source port, destination IP, destination port, protocol) to distribute traffic. For stateful applications that need a client to always hit the same backend:

Internal Load Balancer (ILB)

When the frontend IP is a private IP within a VNet, the Load Balancer is an Internal Load Balancer. Use this to distribute traffic between tiers within a VNet — for example, from an application tier to a database tier, or in front of NVAs (Network Virtual Appliances) in a hub-spoke topology.

HA Ports rule

A special load balancing rule that balances all TCP/UDP ports simultaneously. Only available on Internal Load Balancers with Standard SKU. Used when NVAs must inspect traffic on all ports — configure an ILB with an HA Ports rule in front of a cluster of NVA VMs.

3. Application Gateway

Application Gateway is a Layer 7 load balancer that understands HTTP and HTTPS. It can inspect the full HTTP request — URL path, host headers, query strings, cookies — and make routing decisions based on that content. This makes it dramatically more powerful than Azure Load Balancer for web application workloads.

Core components

SSL/TLS handling modes

WAF — Web Application Firewall

Application Gateway WAF_v2 SKU includes an integrated WAF that inspects HTTP/S requests against OWASP Core Rule Sets (CRS). The WAF protects against the OWASP Top 10 vulnerabilities including SQL injection, cross-site scripting (XSS), and remote code execution attacks.

• Detection mode: logs violations but does not block traffic. Use for initial tuning.
• Prevention mode: actively blocks requests that match WAF rules.
• Custom rules: allow or deny based on IP ranges, geo-location, HTTP variables, or rate limits.
• Bot protection: built-in ruleset for known malicious bots.

SKUs

Path-based routing example

Listener: HTTPS on port 443 for "app.contoso.com"
  │
  ├─ /api/*         → backend-pool-api     (API VMs, port 8080)
  ├─ /images/*      → backend-pool-storage (Azure Blob / CDN)
  ├─ /admin/*       → backend-pool-admin   (Admin VMs, with WAF custom rule)
  └─ /* (default)   → backend-pool-web     (Web frontend VMs, port 80)

4. Azure Front Door

Azure Front Door is Microsoft's global Layer 7 load balancing service. It operates on Microsoft's global anycast network — users worldwide are routed to the nearest Microsoft PoP (Point of Presence), which then proxies the request to the origin. This dramatically reduces latency for geographically distributed users.

Key capabilities

• Global anycast routing: users connect to the nearest of Microsoft's 200+ edge PoPs globally
• L7 load balancing: HTTP/S routing to multiple regional backend origins
• SSL offload: TLS termination at the edge PoP, reducing latency
• WAF: OWASP CRS-based protection at global scale (Standard and Premium SKUs)
• Caching (CDN): static content cached at PoPs, reducing origin load
• Health probes to origins: detects unhealthy origins and routes around them
• URL rewrite and redirect: HTTP → HTTPS redirect, path manipulation

SKUs

Front Door vs. Application Gateway

Both are L7 load balancers with WAF. The key difference is scope:

• Application Gateway is regional — deploy one per region, routes traffic within that region.
• Front Door is global — single deployment routes users worldwide to the nearest regional backend (which may itself be behind an Application Gateway).

5. Traffic Manager

Traffic Manager is fundamentally different from the other three services. It does not proxy traffic — it only controls DNS resolution. When a client queries a Traffic Manager profile, Traffic Manager returns the IP of the "best" endpoint based on the configured routing method. The client then connects directly to that endpoint.

Routing methods

Health probes

Traffic Manager continuously probes endpoint health using HTTP, HTTPS, or TCP checks. When an endpoint fails its health probe, Traffic Manager stops returning its IP in DNS responses — clients are routed to a healthy endpoint instead.

6. Decision Guide — Which Service to Use

The AZ-104 exam tests this decision tree repeatedly. Memorise the key differentiators:

Layering services — the enterprise pattern

These services are designed to be combined. A fully resilient global web application might use all four: