6.3 Load Balancing Decision Matrix & Multi-Tier Design

Load Balancing Decision Matrix & Multi-Tier Design

Designing enterprise network architectures in Azure requires selecting the right load balancing technology—or combination of technologies—to satisfy performance, protocol, security, and geographic requirements. Microsoft Azure provides four distinct load balancing services:

1. Azure Front Door (AFD): Global Layer 7 Reverse Proxy & CDN
2. Azure Traffic Manager (ATM): Global DNS-Based Traffic Director
3. Azure Application Gateway (AppGW): Regional Layer 7 Application Load Balancer
4. Azure Load Balancer (ALB): Regional Layer 4 Network Load Balancer

1. The Azure Load Balancing Decision Matrix

The fundamental decision framework categorizes these four services along two core architectural axes: Scope (Global vs. Regional) and OSI Layer (Layer 4 vs. Layer 7).

+-----------------------------------------------------------------------------+
|                   AZURE LOAD BALANCING 2x2 ARCHITECTURAL MATRIX             |
|                                                                             |
|                     GLOBAL SCOPE                  REGIONAL SCOPE            |
|               +---------------------------+---------------------------+     |
|               |                           |                           |     |
|   LAYER 7     |     AZURE FRONT DOOR      | AZURE APPLICATION GATEWAY |     |
|   (HTTP/HTTPS)| - Anycast Edge Reverse    | - Regional Layer 7 Proxy  |     |
|   (App Layer) |   Proxy & CDN             | - URL Path / Host Routing |     |
|               | - Global WAF & Bot Defense| - Regional WAF (CRS 3.2+) |     |
|               | - SSL Offload & Caching   | - Private VNet Deployment |     |
|               |                           |                           |     |
|               +---------------------------+---------------------------+     |
|               |                           |                           |     |
|   LAYER 4     |   AZURE TRAFFIC MANAGER   |    AZURE LOAD BALANCER    |     |
|   (TCP/UDP)   | - Global DNS-Based Router | - Ultra-Low Latency L4    |     |
|   (Transport) | - Protocol-Agnostic       | - Millions of Flows/Sec   |     |
|               | - Direct Client-to-Origin | - Internal & Public SKUs  |     |
|               |   Data Path (No Proxy)    | - Zone-Redundant Data     |     |
|               |                           |                           |     |
|               +---------------------------+---------------------------+     |
+-----------------------------------------------------------------------------+

Comprehensive Service Comparison Matrix

2. Decision Tree: Choosing the Right Solution

When evaluating exam scenarios or enterprise requirements, follow this systematic decision tree:

+-----------------------------------------------------------------------------+
|                     LOAD BALANCER SELECTION DECISION TREE                   |
|                                                                             |
|   [Incoming Application Traffic Requirement]                                |
|                        |                                                    |
|                        v                                                    |
|   Is the traffic HTTP/HTTPS?                                                |
|     |-- NO (e.g., Gaming UDP, SQL TCP, Custom L4)                           |
|     |     |-- Is global multi-region routing required?                      |
|     |     |     |-- YES ==> Use AZURE TRAFFIC MANAGER + AZURE LOAD BALANCER |
|     |     |     +-- NO  ==> Use AZURE LOAD BALANCER (Standard L4)           |
|     |                                                                       |
|     +-- YES (Web, REST API, Microservices)                                  |
|           |-- Is global multi-region acceleration/WAF required?             |
|           |     |-- YES ==> Use AZURE FRONT DOOR (Standard/Premium)         |
|           |     +-- NO  (Single Region / Dedicated VNet Gateway)            |
|           |           |-- Is Layer 7 routing (URL path/cookie affinity/WAF) |
|           |           |   required within the region?                       |
|           |           |     |-- YES ==> Use AZURE APPLICATION GATEWAY (v2)  |
|           |           |     +-- NO  ==> Use AZURE LOAD BALANCER (Standard)  |
+-----------------------------------------------------------------------------+

3. Multi-Tier Enterprise Design Patterns

Enterprise architectures rarely rely on a single load balancer. High-scale, defense-in-depth cloud applications combine multiple services into a coordinated Multi-Tier Load Balancing Architecture.

Pattern 1: Global Edge + Regional Layer 7 + Internal Layer 4 (Edge-to-Core)

This is the premier reference architecture for global enterprise web applications.

• Tier 1 (Global Edge): Azure Front Door Premium terminates client Anycast connections worldwide, applies global WAF rules and Bot Defense, caches static assets, and accelerates dynamic traffic over the Microsoft dark fiber backbone.
• Tier 2 (Regional Ingress): Azure Application Gateway v2 deployed inside a private subnet in each region receives traffic from Front Door, performs microservice URL path routing (e.g., /orders/* -> Order Pods, /users/* -> User Pods), and enforces regional security policies.
• Tier 3 (Internal Microservices & Data Tier): Internal Azure Load Balancer (Standard) load balances internal TCP/UDP traffic across backend database replicas, message brokers, or legacy internal services.

Pattern 2: Global Hybrid Gaming / Non-HTTP Services

• Global Layer: Azure Traffic Manager uses Performance or Multivalue routing to direct players to the closest regional public IP.
• Regional Layer: Standard Public Load Balancers distribute UDP game server packets across virtual machine scale sets with ultra-low latency and zero packet inspection overhead.

4. Origin Security & Header Validation (X-Azure-FDID)

When deploying Azure Front Door in front of regional web servers or Application Gateways, you must prevent attackers from bypassing Front Door and sending malicious traffic directly to the backend origin public IP.

+-----------------------------------------------------------------------------+
|                     FRONT DOOR ORIGIN LOCKDOWN MECHANISMS                   |
|                                                                             |
|   ATTACK VECTOR: Malicious Actor bypasses AFD WAF and attacks Origin direct! |
|   [Attacker] =============== DIRECT ATTACK ATTEMPT ==============> [Origin] |
|                                                                        |    |
|   DEFENSE-IN-DEPTH CONTROLS:                                           |    |
|   1. Network Security Group (NSG): Restrict inbound 443 to             |    |
|      Service Tag: 'AzureFrontDoor.Backend' (Blocks public scans)        |    |
|   2. Header Validation: Inspect HTTP Header:                           |    |
|      'X-Azure-FDID' == '<Unique Front Door Profile GUID>'               |    |
|      (Drops requests from other Azure tenants using Front Door!)       |    |
|   3. Private Link (Premium SKU): Zero public IP address exposure!       |    |
+-----------------------------------------------------------------------------+

The Three Layers of Origin Defense:

1. Azure Private Link (Front Door Premium): The most secure approach. Eliminates public IP addresses entirely from the origin, routing traffic through private endpoints.
2. Network Security Group (NSG) with Service Tags: If using public endpoints, restrict inbound port 80/443 traffic on the backend subnet to the AzureFrontDoor.Backend service tag and Azure platform infrastructure (AzurePlatformLKM).
3. X-Azure-FDID Header Inspection: Because all Front Door profiles in all Azure subscriptions share the AzureFrontDoor.Backend IP range, an NSG alone does not prevent another tenant from configuring their Front Door to point to your origin. Front Door injects a unique header containing your profile's GUID:
   • Header Name: X-Azure-FDID
   • Origin Action: The backend Application Gateway, Nginx, IIS, or web application must inspect this header and reject any request where X-Azure-FDID does not match your specific Front Door resource ID.

Client IP Preservation Headers

Because Layer 7 reverse proxies terminate client TCP connections, the origin sees Front Door's internal IP as the socket source. Front Door injects standard forwarding headers:

• X-Forwarded-For: Contains the original client public IPv4/IPv6 address (e.g., 203.0.113.195).
• X-Forwarded-Host: Contains the original Host header sent by the client browser (e.g., www.contoso.com).
• X-Forwarded-Proto: Indicates the protocol used by the client (http or https).
• X-Azure-ClientIP: Dedicated Microsoft header containing the client IP address as detected by the edge PoP.