5.1 Azure Load Balancer Architecture & Rules

Azure Load Balancer Architecture & Rules

Azure Load Balancer is Microsoft's ultra-high-throughput, ultra-low-latency Layer 4 (Transport Layer) load balancing service. It distributes inbound network traffic across healthy backend virtual machines, Virtual Machine Scale Sets (VMSS), and container instances based on configured rules and health probe signals.

Because Azure Load Balancer operates at Layer 4, it acts as a non-terminating (pass-through) network proxy. It inspects TCP and UDP headers at wire speed directly within the Azure Software-Defined Networking (SDN) physical host hypervisors (the Azure Virtual Filtering Platform / VFP). It does not terminate TCP connections, decrypt TLS payloads, or inspect HTTP request paths.

---

1. Load Balancer SKUs & Capabilities

Azure offers distinct SKUs for Load Balancers, with Standard SKU serving as the foundation for modern enterprise networking architectures.

[!IMPORTANT] Basic SKU Retirement: Microsoft officially retired the Basic Load Balancer SKU on September 30, 2025. All modern architectures tested on the AZ-700 exam exclusively require Standard SKU Load Balancer configurations with Standard Public IPs and explicit Network Security Group (NSG) rules.

Gateway Load Balancer (GWLB)

Azure Gateway Load Balancer is a specialized SKU of Azure Load Balancer designed for transparent, bump-in-the-wire high-performance insertion of third-party Network Virtual Appliances (NVAs) (such as Palo Alto, Fortinet, Check Point, or DDoS scrubbers):

• It intercepts network traffic before it reaches the workload frontend without changing IP packet headers.
• Uses VXLAN encapsulation (Data and Tunnel interfaces) to forward raw packets to NVA backend instances and receive inspected packets back.
• Requires no complex User-Defined Route (UDR) management or source NAT at the firewall tier, maintaining source IP transparency.

2. Public vs. Internal Load Balancers

Azure Load Balancer is deployed in one of two operational modes depending on the origin and destination of the traffic.

Public Load Balancer

• Frontend: Configured with one or more Standard Public IP Addresses or Public IP Prefixes.
• Traffic Direction: Maps inbound public Internet traffic to private IP addresses inside your VNet subnets.
• Outbound Connectivity: Can provide outbound Internet translation (Source Network Address Translation / SNAT) for backend virtual machines using dedicated Outbound Rules.

Internal (Private) Load Balancer (ILB)

• Frontend: Configured with a private IP address statically or dynamically allocated from a VNet subnet.
• Traffic Direction: Distributes traffic within private topologies:
  1. Intra-VNet traffic between multi-tier workloads (e.g., Web tier sending SQL traffic to Database tier ILB).
  2. Cross-peered VNet traffic across regional or global VNet peerings.
  3. Hybrid cross-premises traffic arriving across VPN Gateways or ExpressRoute circuits.
• Outbound Connectivity: An Internal Load Balancer never provides outbound Internet SNAT.

---

3. Frontend IP Configurations & Backend Pools

Frontend IP Configurations

A single Standard Load Balancer can host multiple frontend IP configurations:

• Mixing IPv4 and IPv6 dual-stack frontend configurations.
• Binding multiple public IPs to host multiple distinct services on standard ports (e.g., 52.183.40.10:443 for App A and 52.183.40.11:443 for App B).
• Configuring private frontend IPs across multiple subnets within the same virtual network.

Backend Pool Architectures: NIC-Based vs. IP-Based

Standard Load Balancer backend pools can be populated using two distinct approaches:

+-----------------------------------------------------------------------------+
|                   BACKEND POOL ARCHITECTURE COMPARISON                      |
|                                                                             |
|   NIC-BASED BACKEND POOL:                                                   |
|   +---------------------------------------------------------------------+   |
|   | Virtual Network A (10.100.0.0/16)                                   |   |
|   |   Load Balancer Backend Pool ---> [ VM1 NIC ]   [ VM2 NIC ]         |   |
|   |   (Tied directly to Network Interface resources in the same VNet)   |   |
|   +---------------------------------------------------------------------+   |
|                                                                             |
|   IP-BASED BACKEND POOL (CROSS-VNET SUPPORT):                               |
|   +---------------------------------------------------------------------+   |
|   | Virtual Network A (10.100.0.0/16)        Virtual Network B (10.200) |   |
|   |   Load Balancer Frontend                 (Global/Regional Peering)  |   |
|   |      |                                                |             |   |
|   |      +---> Backend Pool: [ 10.100.1.4 ]  --->  [ 10.200.1.4 ]       |   |
|   |            (Explicit Private IPs across peered VNets)               |   |
|   +---------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------+

1. NIC-Based Backend Pools:

   • Instances are associated by referencing their Virtual Machine Network Interface Card (NIC).
   • Scoped strictly to virtual machines and VMSS located within the same Virtual Network as the Load Balancer.
   • Supports up to 1,000 backend instances.

2. IP-Based Backend Pools:

   • Instances are added by specifying explicit IPv4/IPv6 private IP addresses directly.
   • Cross-VNet Backend Pool Support: Allows a single Standard Load Balancer in VNet A to balance traffic across virtual machines located in VNet B, VNet C, and VNet D, provided the virtual networks are connected via VNet Peering within the same region.
   • Enables agile containerized architectures (e.g., Azure CNI AKS pods added directly into backend pools).
   • Constraint: IP-based backend pools cannot be used with Private Link Services if proxy protocol is required without specific routing constraints.

---

4. Health Probes: Mechanics & The 168.63.129.16 WireServer

Health probes dynamically monitor backend instance availability. If a backend instance fails its health probe, the Load Balancer stops routing new flows to that specific instance.

Probe Protocols & Evaluation Criteria

• TCP Probe: Initiates a standard TCP three-way handshake (SYN, SYN-ACK, ACK) on the designated backend port. If the TCP connection completes successfully, the instance is marked Healthy. The Load Balancer immediately tears down the socket with a TCP RST.
• HTTP Probe: Establishes a TCP connection and issues an HTTP GET request to a designated path (e.g., /healthz or /status). The backend must return an HTTP 200 OK response within the timeout period. Any other response (such as 201 Created, 301/302 Redirect, 401 Unauthorized, 404 Not Found, or 500 Server Error) causes the probe to fail.
• HTTPS Probe: Establishes a TLS session followed by an HTTP GET request. Validates that the endpoint returns HTTP 200 OK. Note that the probe does not validate SSL certificate trust or expiration, only that the TLS handshake completes and returns 200.

Probe Configuration Parameters

• Probe Interval: Frequency of probe checks (Default: 5 seconds; minimum: 5 seconds).
• Unhealthy Threshold: Number of consecutive failed probe attempts required before an instance is marked unhealthy (Default: 2 consecutive failures; minimum: 1).
• Probe Timeout: Maximum time Azure waits for a probe response before registering a failure (Default: 5 seconds).
• Probe Down Behavior: When marked unhealthy, existing TCP connections may persist until idle timeout, but all new connection requests are diverted to remaining healthy backends. For UDP, all traffic to the unhealthy backend is immediately dropped.

[!CAUTION] The 168.63.129.16 Infrastructure VIP & NSGs: All health probes originate from the physical host virtualization platform using the immutable virtual IP address 168.63.129.16. You must never block this IP address in your OS firewall or Network Security Groups. In NSGs, inbound probe communication must be allowed using the AzureLoadBalancer service tag (which resolves to 168.63.129.16). Blocking this IP will cause all backend instances to fail health probes, resulting in a total service outage.

5. Load Balancing Rules & Session Persistence

A Load Balancing Rule maps a specific frontend IP and port combination to a backend pool, port, and health probe.

Distribution Hash Algorithms (Session Persistence)

Azure Load Balancer uses a 5-tuple hash by default to map network flows to backend instances. You can configure session persistence (affinity) using the following modes:

+-----------------------------------------------------------------------------+
|                     SESSION PERSISTENCE HASH COMPARISON                     |
|                                                                             |
|   1. DEFAULT (None - 5-Tuple Hash):                                         |
|      [ Src IP: 198.51.100.1 ] [ Src Port: 51234 ] [ Dst IP ] [ Dst Port: 443 ] [ TCP ]
|      --> Flow 1 maps to Backend VM 1                                        |
|      [ Src IP: 198.51.100.1 ] [ Src Port: 51235 ] [ Dst IP ] [ Dst Port: 443 ] [ TCP ]
|      --> Flow 2 (New port) maps to Backend VM 2 (Distributed across nodes)  |
|                                                                             |
|   2. CLIENT IP PERSISTENCE (2-Tuple Hash):                                  |
|      [ Src IP: 198.51.100.1 ] [ Dst IP: 52.183.40.10 ]                      |
|      --> ALL connections from 198.51.100.1 ALWAYS map to Backend VM 1       |
|                                                                             |
|   3. CLIENT IP AND PROTOCOL (3-Tuple Hash):                                 |
|      [ Src IP: 198.51.100.1 ] [ Dst IP: 52.183.40.10 ] [ Protocol: TCP ]   |
|      --> ALL TCP connections from 198.51.100.1 map to Backend VM 1          |
+-----------------------------------------------------------------------------+

Floating IP (Direct Server Return / DSR)

In standard load balancing, Azure replaces the destination IP address of the incoming packet with the backend VM's private IP address (Destination NAT / DNAT).

When Floating IP (Direct Server Return) is Enabled:

• Azure retains the Frontend IP address as the destination IP in the packet header when delivering the packet to the backend VM network interface.
• The backend VM must have a local loopback adapter or network alias configured with the Load Balancer's Frontend IP address.
• When the backend VM responds, it sends traffic directly back to the client using the Frontend IP as its source IP, bypassing the Load Balancer on egress.
• Mandatory Use Case: SQL Server AlwaysOn Availability Group Listeners and Windows Server Failover Clustering (WSFC). Without Floating IP, SQL AlwaysOn listeners cannot function across clustered cluster nodes.

Idle Timeout & TCP Reset

• TCP Idle Timeout: Configurable between 4 minutes and 30 minutes (Default: 4 minutes). If no keep-alive or data packet is sent across the socket within this window, the flow state is silently dropped from the Azure SDN translation table.
• TCP Reset on Idle (enableTcpReset): When enabled on Standard Load Balancers, Azure automatically sends a bidirectional TCP Reset (TCP RST) packet to both the client and backend server when the idle timeout expires. This immediately notifies both endpoints that the connection is closed, preventing silent connection hangs and half-open socket leaks.

6. High Availability (HA) Ports Rules for Internal NVAs

When deploying a cluster of active-active or active-passive Network Virtual Appliances (NVAs) (such as firewalls, routing appliances, or IDS/IPS inspection systems), managing hundreds of individual port rules becomes unmanageable.

HA Ports is a specialized capability of Internal Standard Load Balancers:

• Configuration: Set Protocol: All, Frontend Port: 0, and Backend Port: 0.
• Functionality: Load balances all TCP and UDP flows simultaneously on all ports arriving at the internal frontend IP across the backend NVA cluster.
• Health Probe: Monitors the NVAs using a single dedicated health probe port (e.g., HTTP 8080 /health or TCP 22).
• Symmetric Routing Requirement: In enterprise hub-and-spoke designs, traffic passing through an NVA cluster must remain symmetric (inbound and outbound packets of the same flow must traverse the same NVA instance). HA Ports must be combined with session persistence or dual-ILB sandwich architectures to prevent asymmetric TCP teardowns.

+-----------------------------------------------------------------------------+
|                     HA PORTS RULE ARCHITECTURE FOR NVAS                     |
|                                                                             |
|   Spoke VNet Subnet (UDR: 0.0.0.0/0 -> Next Hop: 10.0.0.100)               |
|         |                                                                   |
|         v (All TCP/UDP Ports: 80, 443, 8080, 53, 3389...)                   |
|   +---------------------------------------------------------------------+   |
|   | Internal Standard Load Balancer                                     |   |
|   | Frontend Private IP: 10.0.0.100                                     |   |
|   | HA Ports Rule: Protocol=All, FrontendPort=0, BackendPort=0          |   |
|   | Health Probe: TCP 8080 (Probes NVA Health Daemon)                  |   |
|   +---------------------------------------------------------------------+   |
|         |                                                                   |
|         +-----------------------+-----------------------+                   |
|         |                       |                       |                   |
|         v                       v                       v                   |
|   [ NVA Firewall 1 ]      [ NVA Firewall 2 ]      [ NVA Firewall 3 ]        |
|   (Inspects & Routes)     (Inspects & Routes)     (Inspects & Routes)       |
+-----------------------------------------------------------------------------+

---

7. Outbound Rules & SNAT Port Allocation

When virtual machines in a backend pool need to initiate outbound connections to the Internet without individual Public IPs or an Azure NAT Gateway, Standard Load Balancer provides Outbound Rules.

Source Network Address Translation (SNAT) Mechanics

• In an outbound rule, backend private IP addresses are translated to one or more Public Frontend IPs.
• Azure allocates SNAT ports to each backend VM to track individual outbound flows (Source IP, Source Port, Destination IP, Destination Port).
• Default SNAT Allocation: Azure assigns a fixed number of SNAT ports per VM based on backend pool size (e.g., 1,024 pre-allocated ports per VM for pools up to 50 instances).
• Manual / Dynamic Port Allocation: You can explicitly configure the number of SNAT ports per instance (from 32 up to 64,000) or allocate a dynamic sliding scale based on the number of attached public frontend IPs.

[!WARNING] SNAT Port Exhaustion: If a backend VM initiates more concurrent outbound connections than its allocated SNAT port quota, new outbound connection attempts are dropped, causing intermittent network timeouts. For high-volume outbound architectures, the recommended Microsoft best practice is deploying an Azure NAT Gateway on the subnet rather than relying on Load Balancer outbound SNAT.