Azure Load Balancer: Layer 4

Azure Load Balancer distributes traffic at Layer 4 (TCP/UDP). It doesn’t inspect HTTP headers or URLs — it routes packets based on IP address, port, and protocol. Fast, efficient, and the foundation of Azure’s load balancing story.

Simple explanation

A load balancer is a traffic cop at a busy intersection — it directs incoming traffic to different servers so no single server gets overwhelmed. Azure Load Balancer works at Layer 4 (TCP/UDP) — it distributes based on IP addresses and ports, not URLs. It doesn’t inspect content — it just routes packets to healthy backends.

Load Balancer SKUs

Azure Load Balancer SKU Comparison
Feature	Basic (Retiring)	Standard	Gateway
Backend pool size	300 instances	1,000 instances	1,000 instances
Health probes	TCP, HTTP	TCP, HTTP, HTTPS	TCP, HTTP, HTTPS
Availability zones	Not supported	Zone-redundant and zonal	Zone-redundant
HA Ports	No	Yes (all ports on internal LB)	Yes (transparent)
Outbound rules	No (default SNAT only)	Yes (configurable SNAT)	N/A
SLA	No SLA	99.99%	99.99%
Security	Open by default	Secure by default (NSG required)	Secure by default
Status	Retiring 30 Sept 2025	Current — use this	Specialised (NVA chaining)
Cost	Free	Per rule + per GB	Per rule + per GB

Exam Tip: Basic LB is retiring on 30 September 2025 (same date as Basic public IPs — they’re linked). Always choose Standard for new deployments. Standard LB requires Standard SKU public IPs and is secure by default (inbound traffic blocked until an NSG allows it).

Public vs Internal Load Balancer

Type	Frontend IP	Use Case
Public	Public IP address	Internet-facing workloads (web servers, APIs)
Internal	Private IP from your subnet	Internal workloads (app tiers, databases, internal APIs)

You can have both on the same set of backend VMs — a public LB for internet traffic and an internal LB for backend-tier traffic.

The 6 Components

Frontend IP configuration — the IP clients connect to (public or private)
Backend pool — the VMs or instances that receive traffic
Health probes — check if backend instances are healthy
Load balancing rules — map frontend IP:port to backend pool (uses 5-tuple hash: source IP, source port, destination IP, destination port, protocol)
Inbound NAT rules — port forward specific frontend ports to specific backend instances (e.g., frontend port 50001 to VM1 port 3389)
Outbound rules — control SNAT for outbound internet traffic from backend pool members

Distribution modes:

Mode	Hash	Behaviour
Default (5-tuple)	Source IP + port + Dest IP + port + Protocol	Different connections may go to different backends
Source IP affinity (2-tuple)	Source IP + Dest IP	Same client IP always goes to same backend
Source IP affinity (3-tuple)	Source IP + Dest IP + Protocol	Same client and protocol always goes to same backend

SNAT Port Exhaustion — A Common Production Issue

When backend VMs use the load balancer for outbound internet traffic (no public IP, no NAT Gateway), they share SNAT ports from the frontend IP.

The problem: Each frontend IP provides approximately 64,000 SNAT ports. With many VMs making outbound connections (e.g., calling external APIs), ports can be exhausted. Symptoms: intermittent connection failures, timeouts, “cannot allocate port” errors.

Solutions (in order of preference):

NAT Gateway — best practice. Provides 64,000 ports per IP per destination. Scales with multiple IPs.
Outbound rules — explicitly allocate SNAT ports per backend instance. Provides more predictable allocation.
Multiple frontend IPs — more frontends = more SNAT ports (64,000 per IP).
Public IP on VMs — each VM gets its own 64,000 ports. Doesn’t scale well.

Monitoring: Track the “SNAT Connection Count” metric. Alert when approaching limits.

The exam tests that you know NAT Gateway is the recommended solution for SNAT port exhaustion.

Cross-Region Load Balancer

Cross-region LB (global tier) distributes traffic across regional Standard LBs in different Azure regions:

Client (anywhere)
    ↓
Cross-Region LB (Global anycast IP)
    ├──→ Standard LB (Australia East)
    │        └──→ Backend VMs
    └──→ Standard LB (West Europe)
             └──→ Backend VMs

Key features:

Anycast IP — single IP address that routes to the nearest healthy region
Geographic proximity — clients connect to the closest regional LB
Instant failover — if a regional LB becomes unhealthy, traffic shifts to the next closest
Layer 4 only — still TCP/UDP, not HTTP-aware

Use cross-region LB when you need global Layer 4 distribution with automatic regional failover. For HTTP-aware global distribution, use Azure Front Door instead.

Gateway Load Balancer

Gateway LB enables transparent NVA chaining — inserting network virtual appliances (firewalls, packet inspection, DDoS appliances) into the traffic path without changing the application architecture.

How it works:

Gateway LB sits in front of NVAs in a separate VNet
Your Standard LB’s frontend configuration is “chained” to the Gateway LB
Traffic flows: Client → Standard LB → Gateway LB → NVA → Gateway LB → Backend VMs
The application and clients see no change — it’s transparent

Use case: A third-party security vendor provides a firewall appliance. Instead of re-architecting your application, you chain the Gateway LB to inject the NVA into the existing traffic flow.

Key Takeaways

Standard LB is the only production choice (Basic retiring, Gateway is specialised)
Standard LB is secure by default — NSG required for inbound traffic
5-tuple hash distributes connections; source IP affinity provides session persistence
NAT Gateway is the recommended solution for SNAT port exhaustion
Cross-region LB uses anycast for global Layer 4 distribution
Gateway LB transparently chains NVAs into traffic flows

Test Your Knowledge

Question

What is the default distribution mode for Azure Load Balancer?

Click or press Enter to reveal answer

Answer

5-tuple hash: source IP, source port, destination IP, destination port, and protocol. This means different connections from the same client may go to different backends.

Click to flip back

Question

What is the recommended solution for SNAT port exhaustion?

Click or press Enter to reveal answer

Answer

NAT Gateway. It provides 64,000 ports per IP per destination and scales with multiple IPs. It takes precedence over LB outbound rules when associated with the backend subnet.

Click to flip back

Question

What does the 'HA Ports' feature on Standard Internal LB do?

Click or press Enter to reveal answer

Answer

HA Ports creates a load balancing rule for ALL ports and ALL protocols simultaneously. Used with NVAs so all traffic (every port, every protocol) is forwarded to the NVA without creating individual rules.

Click to flip back

Question

How does Gateway Load Balancer differ from Standard?

Click or press Enter to reveal answer

Answer

Gateway LB enables transparent NVA chaining. It's inserted into the traffic path of a Standard LB without changing the application architecture. Traffic passes through the NVA and returns to the Standard LB's backend.

Click to flip back

Knowledge Check

Sam's backend VMs are experiencing intermittent outbound connection failures. Monitoring shows high SNAT port usage. What's the recommended fix?

Knowledge Check

Ravi needs global Layer 4 load balancing with automatic failover between Australia East and West Europe. What should he deploy?

Next up: Traffic Manager: DNS-Based Routing — Route traffic globally using DNS with six different routing methods.