Azure Load Balancer: Layer 4 Traffic Distribution for Internal and Public Workloads

Azure Load Balancer operates at the transport layer (layer 4) of the network stack. It distributes inbound TCP and UDP flows across backend pool members — virtual machines, scale set instances, or IP addresses — based on a 5-tuple hash: source IP, source port, destination IP, destination port, and protocol. It does not inspect HTTP headers, paths, or cookies; for that, use Application Gateway.

Load Balancer is a foundational networking service: every time you deploy a public-facing VM fleet or an internal multi-tier application, it is likely in the picture.

Real-World Scenario

A media company streams live video. The ingest tier receives RTMP streams from thousands of encoders using a single public IP. An internal (private) load balancer distributes these RTMP connections across twenty ingest VMs on port 1935. Health probes check port 1935 every 5 seconds. When an ingest VM crashes, the load balancer detects the probe failure within 15 seconds and stops sending new connections to it. Existing connections on other VMs are unaffected.

Standard vs. Basic SKU

Feature                    | Basic                | Standard
---------------------------|----------------------|----------------------------
SLA                        | No SLA               | 99.99%
Backend pool size          | Up to 300 instances  | Up to 1000 instances
Backend pool members       | Availability Set / VM| Any VM in VNet
Health probe types         | HTTP, TCP            | HTTP, HTTPS, TCP
Availability Zone support  | No                   | Yes (zone-redundant, zonal)
Outbound SNAT rules        | Auto (limited)       | Explicit outbound rules
HA ports                   | No                   | Yes
Secure by default          | No (open)            | Yes (requires NSG or rule)
Price                      | Free                 | Paid per rule and data

Basic Load Balancer has been retired for new deployments. All production workloads should use Standard. The most important behavioural difference: Standard Load Balancer blocks all inbound traffic by default unless an NSG or LB rule explicitly allows it. This is a breaking change for teams migrating from Basic.

Components

Standard Load Balancer Architecture
-------------------------------------
[Internet / VNet]
       |
  Frontend IP Configuration
  (Public IP or Private IP)
       |
  Load Balancing Rules
  (port 80 -> backend port 80, probe: HTTP/80/healthz)
       |
  Backend Pool
  [VM1] [VM2] [VM3] [VM4]  (in availability zones 1, 2, 3)
       |
  Health Probe
  (TCP port 80 every 5 seconds; 2 failures = unhealthy)
       |
  Inbound NAT Rules
  (SSH to VM1: public port 50001 -> VM1:22)
  (SSH to VM2: public port 50002 -> VM2:22)

The frontend IP is the single stable address clients use. Rules map frontend port to backend port. The health probe monitors each backend member independently.

Health Probes

Health probes determine which backend members receive traffic. The load balancer sends probe requests every intervalInSeconds (default: 15 seconds) and marks a member unhealthy after numberOfProbes consecutive failures (default: 2):

Probe Types:
  TCP probe:  opens a TCP connection; success = connection accepted
  HTTP probe: HTTP GET to a path; success = 200-399 response code
  HTTPS probe: same as HTTP but with TLS; Standard SKU only

Example: TCP probe on port 8080, interval 5 sec, threshold 2
  Second 0:  probe success
  Second 5:  probe success
  Second 10: VM crashes - probe fails (1st failure)
  Second 15: probe fails (2nd failure) -> VM marked unhealthy
  Second 15: LB stops sending new connections to this VM
  Time to detection: 5-15 seconds depending on timing

HTTP probes are preferred for application-layer health checks — they verify the application is serving, not just that the TCP stack is accepting connections.

HA Ports for Network Virtual Appliances

HA ports enable a single load balancing rule to forward all TCP and UDP flows on all ports to a backend pool. This is specifically designed for Network Virtual Appliances (NVAs) like firewalls and routers that must inspect all traffic:

NVA High Availability With HA Ports
-------------------------------------
VNet traffic destined for any port
           |
  Internal Load Balancer
  Rule: 0.0.0.0:0 (all flows)
  HA ports enabled
           |
  +--------+--------+
  |                 |
[NVA Primary]  [NVA Secondary]
  (active)       (standby)
           |
  Traffic inspected and forwarded

Without HA ports, you would need a separate rule for each port range — impractical for a firewall that handles arbitrary traffic. HA ports are only available on the internal (private) load balancer in the Standard SKU.

Outbound SNAT

When VMs in a backend pool need to initiate outbound connections to the internet and do not have public IPs themselves, Load Balancer provides Source Network Address Translation (SNAT) — translating the VM’s private IP to the load balancer’s public IP.

Standard Load Balancer requires explicit outbound rules (Basic auto-allocated them). Explicit rules give you control over the number of SNAT ports allocated per instance:

# Create outbound rule: 2048 SNAT ports per instance
az network lb outbound-rule create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name OutboundRule \
  --frontend-ip-configs frontend-ip \
  --backend-pool-name backend-pool \
  --protocol All \
  --outbound-ports 2048

SNAT port exhaustion (running out of the allocated 2048 ports per instance during high connection volume) causes outbound connection failures. Monitor SNAT connection state in Azure Monitor and increase allocated ports or add public IPs if exhaustion occurs.

Deploying a Zone-Redundant Load Balancer

# Create a zone-redundant public IP
az network public-ip create \
  --resource-group prod-rg \
  --name lb-public-ip \
  --sku Standard \
  --zone 1 2 3    # zone-redundant

# Create Standard Load Balancer
az network lb create \
  --resource-group prod-rg \
  --name prod-lb \
  --sku Standard \
  --public-ip-address lb-public-ip \
  --frontend-ip-name frontend-ip \
  --backend-pool-name backend-pool

# Add health probe
az network lb probe create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name http-probe \
  --protocol Http \
  --port 80 \
  --path /healthz \
  --interval 5 \
  --threshold 2

# Add load balancing rule
az network lb rule create \
  --resource-group prod-rg \
  --lb-name prod-lb \
  --name http-rule \
  --protocol Tcp \
  --frontend-port 80 \
  --backend-port 80 \
  --frontend-ip-name frontend-ip \
  --backend-pool-name backend-pool \
  --probe-name http-probe

Key Interview Points

• Layer 4 only: Load Balancer distributes based on IP:port without any HTTP awareness. For path-based routing, host-based routing, or SSL offloading, use Application Gateway.
• 5-tuple hash: The default distribution algorithm uses a 5-tuple hash, meaning flows from the same source IP and port always reach the same backend VM (session persistence by hash, not cookie). Changing the hash to 2-tuple (source/dest IP only) improves session stickiness at the cost of less even distribution.
• Standard SKU secure by default: New Standard Load Balancer deployments reject all inbound traffic until you create a rule or NSG allow statement. This is intentional — no surprise open ports.
• Cross-region Load Balancer: A separate tier-1 product that sits in front of multiple regional Standard Load Balancers, providing global anycast for TCP/UDP workloads (unlike Traffic Manager which is DNS-based).
• Backend pool membership: Standard Load Balancer supports any VM in the same VNet in the backend pool — not just those in an availability set. This enables flexible topologies including AKS node pools.

Best Practices

• Always use Standard SKU; create NSG rules to explicitly allow required traffic rather than relying on open defaults from Basic.
• Configure health probes to a dedicated health endpoint (/healthz) that verifies application readiness, not just TCP connectivity.
• Monitor SNAT connection counts and allocated ports; set an alert at 80% usage to catch exhaustion before it causes connection failures.
• Deploy backend VMs across availability zones and use a zone-redundant load balancer frontend to survive zone failures.
• Combine Load Balancer (layer 4) with Application Gateway (layer 7) in multi-tier architectures: internet traffic hits Application Gateway for WAF and SSL offload, internal traffic between tiers goes through an internal Load Balancer.