What Azure Load Balancer Does
Azure Load Balancer operates at Layer 4 (transport layer, TCP/UDP), distributing incoming traffic across a pool of backend instances -- VMs or VM Scale Set instances -- based on a 5-tuple hash of source IP, source port, destination IP, destination port, and protocol, which keeps a given client's connection pinned to the same backend for the life of that connection. It comes in two SKUs: Basic (free, limited to 300 backend instances, no availability zone support, being retired) and Standard (paid, zone-redundant, supports up to 1000 backend instances, secure by default meaning no inbound traffic is allowed unless an NSG explicitly permits it). A Load Balancer can be Public (fronted by a public IP, distributing internet traffic to backends) or Internal (fronted by a private IP inside a VNet, distributing traffic for internal tiers like an app tier behind a web tier).
Cricket analogy: It's like a tournament's umpiring panel assigning each match to an available umpire based on a fixed rotation formula, and once assigned, that umpire stays with the match from toss to result rather than switching mid-innings.
Health Probes and Backend Pools
The Load Balancer continuously checks each backend instance's availability using a health probe -- either TCP (attempts a connection to a specified port), HTTP, or HTTPS (expects a 200 OK response from a specified path) -- and automatically stops routing new connections to any instance that fails the probe threshold, resuming once it passes again. This is what makes the load balancer useful for high availability: if a VM crashes, is being patched, or is overloaded and stops responding on the probe path, traffic is silently redirected to the remaining healthy instances within seconds, with no DNS change or client-side awareness required. The backend pool itself is typically a VM Scale Set or a set of availability-zone-spread VMs, and Standard Load Balancer's zone-redundant frontend means the load balancer itself keeps working even if an entire availability zone in the region fails.
Cricket analogy: It's like a team's fitness staff running fitness tests before each match day -- any player who fails the yo-yo test bench-marked threshold is automatically left out of the XI that day, and slotted back in once they pass again, without the selectors needing to publicly announce a change.
Load Balancing Rules and Outbound Rules
A load balancing rule maps a frontend IP and port combination to a backend pool and port, optionally with session persistence settings (None uses the 5-tuple hash per connection; Client IP or Client IP and Protocol pin a given client to the same backend across multiple connections, useful for stateful applications that don't share session state across instances). Separately, Standard Load Balancer requires explicit outbound rules (or a NAT Gateway) for backend instances to reach the internet outbound, since Standard SKU backend instances have no implicit outbound internet access the way Basic SKU instances did -- this is part of its 'secure by default' design and a common gotcha when migrating from Basic to Standard.
Cricket analogy: It's like a franchise's team-composition rule mapping a specific batting position to a designated player for the whole tournament (session persistence), versus a flexible rule that lets the team management rotate who bats there each match (no persistence) based on form.
# Create a Standard public Load Balancer with a health probe and load balancing rule
az network lb create \
--resource-group rg-network-demo \
--name lb-web \
--sku Standard \
--public-ip-address pip-lb-web \
--frontend-ip-name FrontendWeb \
--backend-pool-name BackendWebPool
az network lb probe create \
--resource-group rg-network-demo \
--lb-name lb-web \
--name HealthProbeHttps \
--protocol Https \
--port 443 \
--path /healthz
az network lb rule create \
--resource-group rg-network-demo \
--lb-name lb-web \
--name HttpsRule \
--protocol Tcp \
--frontend-port 443 \
--backend-port 443 \
--frontend-ip-name FrontendWeb \
--backend-pool-name BackendWebPool \
--probe-name HealthProbeHttpsStandard SKU Load Balancer backend instances have no implicit outbound internet access, unlike Basic SKU. If you migrate a workload from Basic to Standard without configuring an explicit outbound rule or attaching a NAT Gateway, backend VMs will silently lose outbound internet connectivity even though inbound load balancing still works fine.
Azure Load Balancer operates purely at Layer 4 and does not inspect HTTP headers, cookies, or URL paths. If you need Layer 7 routing (path-based routing, SSL offload, WAF), you need Azure Application Gateway or Azure Front Door in front of or instead of Load Balancer.
- Azure Load Balancer is a Layer 4 (TCP/UDP) load balancer that distributes traffic using a 5-tuple hash by default.
- Standard SKU is zone-redundant, supports up to 1000 backend instances, and is secure by default (no implicit outbound internet access).
- Health probes (TCP, HTTP, or HTTPS) continuously check backend instance availability and automatically route around failed instances.
- Load balancers can be Public (internet-facing, public IP frontend) or Internal (private IP frontend, for internal tier-to-tier traffic).
- Session persistence settings (None, Client IP, Client IP and Protocol) control whether a client is pinned to the same backend across multiple connections.
- Standard SKU requires explicit outbound rules or a NAT Gateway for backend instances to reach the internet outbound.
- Load Balancer does not do Layer 7 inspection -- use Application Gateway or Front Door for path-based routing, SSL offload, or WAF needs.
Practice what you learned
1. At which OSI layer does Azure Load Balancer operate?
2. What is a key difference in outbound connectivity between Basic and Standard SKU Load Balancers?
3. What happens when a backend instance fails its configured health probe?
4. Which load balancer type would you use to distribute traffic between an internal web tier and app tier, with no internet exposure?
5. What does session persistence set to 'Client IP' accomplish?
Was this page helpful?
You May Also Like
Azure Virtual Networks
Learn how Azure Virtual Networks (VNets) provide isolated, private IP address spaces for your cloud resources, and how peering and hybrid connectivity link them together.
Subnets and NSGs in Azure
Understand how subnets partition an Azure Virtual Network and how Network Security Groups enforce stateful, priority-ordered traffic rules at the subnet and NIC level.
Azure Front Door and CDN
Understand how Azure Front Door provides global Layer 7 routing, failover, and WAF protection at the edge, and how it differs from and complements Azure CDN caching.