Load Balancer Frontend, Backend, and Health Probe Rules

Azure Load Balancer operates at Layer 4 (Transport layer) of the OSI model, distributing incoming TCP and UDP traffic across healthy backend instances. It is designed to provide high availability and scalability by spreading traffic across multiple virtual machines or instances within a virtual network. The service supports both inbound and outbound scenarios, though this chapter focuses on inbound traffic distribution.

The frontend IP configuration is the public or private IP address that clients connect to. It acts as the entry point for all incoming traffic. You can configure: - Public frontend: A public IP address (standard or basic SKU) that is reachable from the internet. The load balancer translates the destination IP to the backend instance's private IP. - Private frontend: A private IP address within a virtual network subnet. Used for internal load balancing between VMs.

Each load balancer can have multiple frontend IP configurations, each with its own set of rules. For example, you could have one public frontend for web traffic and one private frontend for API traffic.

The backend pool is a collection of resources that will handle the incoming traffic. Backend pool members can be:

When using NIC-based association, the load balancer automatically detects the VM's health status via health probes. For IP-based association, you must manually manage health probes.

A load balancing rule defines how traffic arriving at the frontend is distributed to the backend pool. Key parameters: - Protocol: TCP or UDP - Frontend port: The port on the frontend IP (e.g., 80) - Backend port: The port on the backend instances (e.g., 80) - Health probe: Associates a health probe to determine backend health - Session persistence: None, Client IP, or Client IP and Protocol - Idle timeout: Range 4-30 minutes, default 4 minutes - Floating IP: Direct Server Return (DSR) mode

Health probes determine which backend instances are healthy and can receive traffic. Three types: 1. TCP probe: Attempts a TCP connection to the backend port. If the connection succeeds, the instance is healthy. 2. HTTP probe: Sends an HTTP GET request to a specified path (e.g., /health). A 200 OK response indicates health. 3. HTTPS probe: Same as HTTP but with TLS encryption.

Probe configuration: - Interval: Time between probes (5-300 seconds, default 5 seconds for standard SKU) - Unhealthy threshold: Number of consecutive failures before marking instance unhealthy (2-100, default 2) - Healthy threshold: Number of consecutive successes after being unhealthy to mark as healthy (2-100, default 2 for TCP, 1 for HTTP/HTTPS)

When a client sends a packet to the frontend IP: 1. The load balancer uses a 5-tuple hash (source IP, source port, destination IP, destination port, protocol) to determine which backend instance receives the packet. This hash is consistent for the duration of the flow, ensuring all packets of the same flow go to the same backend. 2. If session persistence is enabled (Client IP or Client IP and Protocol), the hash includes the source IP to ensure all connections from the same client go to the same backend. 3. The load balancer forwards the packet to the backend instance, preserving the original source IP address (unless using NAT). The backend sees the client's source IP, not the load balancer's IP. 4. The backend sends response packets directly to the client (in non-floating IP mode) or back through the load balancer (in floating IP mode).

Create a load balancer with Azure CLI:

# Create a public IP
az network public-ip create --resource-group MyRG --name MyPublicIP --sku Standard

# Create a load balancer
az network lb create --resource-group MyRG --name MyLB --sku Standard --public-ip-address MyPublicIP --frontend-ip-name MyFrontend --backend-pool-name MyBackendPool

# Create a health probe
az network lb probe create --resource-group MyRG --lb-name MyLB --name MyProbe --protocol tcp --port 80 --interval 5 --threshold 2

# Create a load balancing rule
az network lb rule create --resource-group MyRG --lb-name MyLB --name MyRule --protocol tcp --frontend-port 80 --backend-port 80 --frontend-ip-name MyFrontend --backend-pool-name MyBackendPool --probe-name MyProbe

Standard Load Balancer supports HA Ports, which is a rule that matches all ports (0-65535) for both TCP and UDP. This is used with Network Virtual Appliances (NVAs) to load balance all traffic to a set of VMs.

When enabled, the backend VM has the frontend IP configured on its loopback interface. The backend responds directly to the client, bypassing the load balancer. This is used for SQL AlwaysOn Availability Groups and other scenarios where the backend must see the original destination IP.

A SaaS company deploys a three-tier application with web, API, and database layers. For the web tier, they use a Standard Load Balancer with a public frontend. The backend pool contains 10 VMs in an availability set. They configure a TCP health probe on port 80 with a 5-second interval and 2 unhealthy threshold. This ensures that if a VM crashes or the web server process stops, traffic is redirected within 10 seconds. In production, they monitor the load balancer metrics (e.g., Data path availability, Health probe status) to alert on backend pool degradation. Common misconfiguration: setting the probe interval too high (e.g., 30 seconds) leads to slower failover, causing user-visible errors during a failure.

A financial services company uses an internal Standard Load Balancer to distribute traffic between microservices running on VMs in a virtual network. Each microservice has its own backend pool and health probe. They use HTTP probes with a custom path like /health to check application-level health, not just TCP connectivity. This allows them to detect when the application is running but returning errors. They also enable session persistence (Client IP) for stateful services like shopping carts. In production, they must ensure the backend VMs are in the same region and virtual network as the load balancer. A common mistake is using a basic SKU load balancer for production, which lacks SLA and has lower backend limits.

An enterprise deploys third-party firewalls as NVAs in a hub-and-spoke topology. They use a Standard Load Balancer with HA Ports to distribute all traffic across two NVAs. The frontend is a private IP in the hub subnet, and the backend pool contains the NVA VMs. Health probes are TCP probes on the management port. They enable floating IP (DSR) so that the NVAs see the original client IP. In this scenario, misconfiguring the health probe path (e.g., using HTTP probe on a non-HTTP port) causes all NVAs to be marked unhealthy, dropping all traffic. They also must configure the NVA's loopback interface with the frontend IP for DSR to work.