The 4 Azure Load Balancers

Azure offers four distinct load-balancing services. Each operates at a different layer and scope — understanding their boundaries is the single most important decision for AZ-305.

Service Layer Scope Key Features Cost Tier Best For
Azure Load Balancer L4 (TCP/UDP) Regional HA ports, health probes, SNAT, zone-redundant Low (per-rule + data) Non-HTTP workloads, internal tier routing
Application Gateway L7 (HTTP/S) Regional Path/host routing, WAF v2, SSL offload, autoscale, private Medium (capacity units) Web apps needing WAF, path-based routing within a region
Azure Front Door L7 (HTTP/S) Global Anycast, WAF, caching, SSL offload, instant failover, Rules Engine Higher (per request + data transfer) Global web/API with low latency, DDoS + WAF at edge
Traffic Manager DNS Global Priority, weighted, geographic, performance, subnet routing Low (per million queries) Non-HTTP global routing, DR failover, DNS-level distribution

🔑 Core Distinction

  • L4 sees only IP + port. Fastest, but no URL awareness.
  • L7 inspects HTTP headers, URL paths, cookies. Can route /api/* differently from /static/*.
  • DNS-based (Traffic Manager) never touches data traffic — it resolves a name to an endpoint IP. TTL governs failover speed (30s–300s).
  • Anycast (Front Door) routes the TCP connection itself to the nearest POP — sub-second failover, no DNS TTL wait.

Decision Tree: Choosing the Right Load Balancer

Use this flowchart on exam day and in real designs:

AZ-305 Exam Tip: This decision tree appears frequently. The exam gives a scenario and asks which service to recommend. Key discriminators: HTTP vs non-HTTP, global vs regional, and whether WAF/caching is needed.

🔑 Quick Decision Rules

  • Non-HTTP traffic? → Load Balancer (regional) or Traffic Manager (global DNS failover).
  • HTTP + single region? → Application Gateway (especially if WAF or path routing needed).
  • HTTP + multi-region + performance? → Front Door (anycast, instant failover, edge caching).
  • Multi-region + non-HTTP or legacy? → Traffic Manager (DNS-based, protocol agnostic).

Azure Front Door Deep Dive

Front Door is Azure's premium global L7 load balancer. It uses anycast — every Front Door POP advertises the same IP, so clients connect to the nearest POP automatically via BGP routing.

🔑 Front Door Capabilities

  • Anycast routing: User connects to nearest of 180+ edge POPs. No DNS wait for failover — TCP itself is re-routed.
  • Instant failover: If a backend region fails health probes, traffic shifts to next-best backend in <30 seconds — no TTL delay.
  • WAF at the edge: Block attacks at the POP before traffic reaches your origin. Managed rule sets (OWASP 3.2, bot protection).
  • Caching: Static content cached at edge POPs — reduces origin load and latency.
  • SSL offload: Front Door terminates TLS, forwarding HTTP or re-encrypted HTTPS to backends.
  • Rules Engine: URL rewrite, redirect, header manipulation, rate limiting — all at the edge.
  • Private Link origins: Front Door Premium can connect to private backends (no public IP on origin).
⚠️ When NOT to use Front Door: Non-HTTP workloads (use Traffic Manager). Single-region with no global presence (App Gateway is simpler/cheaper). Regulatory requirements forbidding edge termination of TLS in specific countries.

Front Door Tiers

  • Standard: CDN + basic routing + managed WAF rules. Good for content delivery.
  • Premium: Everything in Standard + Private Link origins + enhanced WAF (bot protection, geo-filtering) + Microsoft Threat Intelligence rules.

Traffic Manager: DNS-Based Global Routing

Traffic Manager works at the DNS layer. It never proxies traffic — it simply resolves your FQDN to the best endpoint IP based on the routing method you configure.

🔑 Routing Methods

  • Priority: Active/passive failover. All traffic to endpoint #1 unless it fails health check → endpoint #2.
  • Weighted: Distribute traffic by percentage (e.g., 80/20 for canary deployments).
  • Performance: Route to the lowest-latency endpoint based on the user's DNS resolver location.
  • Geographic: Route based on the geographic origin of the DNS query (e.g., EU users → EU endpoint). Useful for data sovereignty.
  • Subnet: Map specific client IP ranges to specific endpoints.
  • MultiValue: Return multiple healthy endpoints in DNS response (client picks one).

When Traffic Manager is Sufficient

  • Non-HTTP protocols (SQL, RDP, custom TCP)
  • You don't need edge WAF or caching
  • You can tolerate DNS TTL-based failover (30–300 seconds)
  • You need geographic routing for compliance (e.g., "German users must only resolve to the Frankfurt endpoint")
  • Budget-conscious global routing — Traffic Manager is the cheapest global option
⚠️ Limitation: DNS TTL means clients may cache stale endpoints for the TTL duration during failover. Set TTL low (30s) for fast failover, but this increases DNS query volume and cost.

Application Gateway: Regional L7 Powerhouse

App Gateway is your in-region HTTP load balancer with deep L7 features. From AZ-104 you know the basics — here's the architect's view.

🔑 Architect-Level Decisions

  • Path-based routing: /api/* → API backend pool, /images/* → storage, /app/* → App Service.
  • Multi-site hosting: Route by Host header — consolidate multiple apps behind one gateway.
  • WAF v2: OWASP Core Rule Set 3.2, custom rules, exclusions. Required for PCI-DSS workloads in-region.
  • Autoscaling (v2): Scales from 0 to 125 capacity units based on traffic. No pre-provisioning needed.
  • Private-only: Deploy in a private subnet with no public IP — for internal apps or behind Front Door.
  • Mutual TLS (mTLS): Client certificate authentication at the gateway.
  • Connection draining: Gracefully remove backend instances during deployments.

v1 vs v2 SKU

Always use v2 for new deployments. v1 is legacy — no autoscale, no zone redundancy, no key vault integration. The exam assumes v2.

Combining Load Balancers

Enterprise architectures often layer multiple load-balancing services. Common patterns:

Pattern 1: Front Door + Application Gateway

  • Front Door handles global routing, edge WAF, caching, SSL offload.
  • App Gateway (private) in each region handles path-based routing, additional WAF rules, and routes to backend compute (AKS, VMs, App Service).
  • Lock down App Gateway to only accept traffic from Front Door (check X-Azure-FDID header or use Private Link with Front Door Premium).

Pattern 2: Traffic Manager + Load Balancer

  • Traffic Manager resolves DNS to the healthiest region.
  • Load Balancer (L4) in each region distributes TCP/UDP across backend VMs.
  • Use case: Non-HTTP workloads needing global failover (gaming servers, IoT ingestion, database replicas).

Pattern 3: Front Door + Load Balancer (internal)

  • Front Door terminates HTTP at edge, sends to App Service or VMs.
  • Internal Load Balancer distributes traffic between application tier and data tier within a VNet.

Cross-Region HA Patterns

🔑 Active-Active vs Active-Passive

  • Active-Active: Both regions serve traffic simultaneously. Front Door (performance routing) or Traffic Manager (weighted/performance). Requires data replication strategy.
  • Active-Passive: Secondary region is standby. Traffic Manager (priority) or Front Door with failover routing. Simpler data consistency but higher RTO.

Design Considerations

  • Health probes: All services probe backends — configure probe paths that actually validate app health (not just TCP port open).
  • Data replication: The load balancer handles traffic routing, but you must separately ensure data is available in the failover region (Cosmos DB multi-region, SQL Geo-Replication, Storage GRS).
  • Failback strategy: After primary recovers, how do you shift traffic back? Automatic (risky) or manual (slower but safer)?
  • Cost: Active-active doubles compute cost. Use consumption-based services (Functions, App Service auto-scale to 0) to reduce standby costs in passive regions.

Real-World: Global SaaS with Regional Compliance

📋 Scenario

A SaaS company serves customers in US, EU, and APAC. Requirements:

  • EU customer data must stay in EU (GDPR)
  • Sub-100ms latency for all regions
  • Survive a full region failure with <1 min failover
  • WAF protection at the edge
  • Path-based routing: /api/* to microservices, /app/* to frontend

Solution Architecture

  1. Azure Front Door Premium — global entry point with anycast, edge WAF, Private Link to origins.
  2. Geographic routing rules in Front Door — EU users pinned to EU backend group (GDPR compliance); US/APAC routed by latency.
  3. Application Gateway (private, WAF v2) in each region — path-based routing to AKS clusters.
  4. Internal Load Balancer within each region's VNet for service-to-service traffic between microservices.
  5. Cosmos DB with multi-region writes — EU region as primary write for EU data, with geo-fencing.

Why Not Alternatives?

  • Traffic Manager alone? — DNS TTL delay fails the <1 min failover SLA. No edge WAF.
  • Front Door without App Gateway? — Works for simple backends, but the team needs private-only backends with in-region WAF layering and mTLS to services.
  • Load Balancer for global? — L4 only, regional only. Can't meet global latency or L7 routing needs.

Knowledge Check