Load Balancers
Load Balancing Overview
A load balancer distributes incoming traffic across multiple servers to prevent any single server from being overwhelmed. It ensures redundancy and high availability: if one server fails, others can continue to handle traffic. Load balancing is essential for critical workloads (e.g., public websites like microsoft.com) that require high availability and scalability.
In standard load balancing scenarios for a single application, all virtual machines in the backend pool run the exact same web server code and application. The primary goal of a load balancer is to distribute the workload across redundant, interchangeable resources, and that depends on three things working together.
The first is consistency: the user experience should be seamless regardless of which VM serves their request. This means all VMs must have the same application version and access to consistent data — for example, via a shared or replicated database, rather than local static variables. The second is high availability and reliability: if one VM fails, the load balancer's health probes detect it and immediately stop sending new traffic to that machine, so the remaining, identical VMs can continue to handle requests with minimal downtime. The third is scalability: when traffic increases, you can add more identical VM instances to the backend pool to scale capacity cost-effectively, and the load balancer uses a configured algorithm (e.g., round-robin, least connections, source IP hash) to pick the most suitable, healthy VM for each new request or flow.
The frontend IP is the public or private IP address that clients use to access the application through the load balancer. A public IP address prefix is a reserved, contiguous range of public IP addresses in a region, from which you can allocate static public IPs to Azure resources — most commonly frontend IPs for load balancers, Application Gateway, Azure Firewall, or VMs — giving you predictable, easy-to-allowlist IP ranges rather than scattered individual addresses. Zone redundancy means distributing a load balancer's frontend across multiple availability zones within a region, improving resilience against zone failures.
Standard Load Balanceris Azure's feature-rich load balancing SKU, offering capabilities like IP-based backends, zone redundancy, and support for SSL. It's now the only load balancer SKU available: Basic Load Balancer was retired on September 30, 2025.
SSL Offloading
SSL offloading is the process where a load balancer decrypts incoming encrypted HTTPS traffic, relieving backend servers of this compute-intensive task. This allows the servers to focus on running applications instead of handling encryption and decryption, which improves overall performance and scalability. The decrypted traffic is then sent to the backend servers, often over an unencrypted HTTP connection.
High Availability and Service Level Agreements (SLAs)
Utilising availability sets and availability zones can significantly improve application uptime, and Microsoft provides SLAs for virtual machines and load balancing services that guarantee a certain level of availability. For a single VM, Microsoft guarantees 99.9% uptime as long as all disks use Premium SSD or Ultra Disk — fall below that threshold and one is entitled to a 10% service credit, below 99% a 25% credit, and below 95% a full refund. Putting that VM behind a load balancer alongside an availability set raises the guarantee to 99.95%, and using availability zones instead raises it further still, to 99.99%.
The way the load balancer itself sits across zones matters too. A zonal load balancer has its frontend placed in one specific zone, so you need multiple instances to get redundancy. A zone-redundant load balancer has Microsoft distribute the frontend across zones automatically, behind a single frontend IP — no extra instances required on your part.
Load Balancer Types: Layer 4 vs. Layer 7
Azure Load Balancer operates at Layer 4, the transport layer (TCP/UDP): it doesn't understand HTTP or other application-level protocols, and doesn't inspect payload — it distributes flows, not requests. Application Gateway, by contrast, operates at Layer 7, the application layer, and can inspect HTTP headers and URLs to make routing decisions. In practice, this means Azure Load Balancer is the right choice for simple load balancing scenarios where application-level awareness isn't needed, while Application Gateway is the right choice when one needs to route traffic based on content or other application-level information.
Public vs. Internal Load Balancers
A Public Load Balancer is used to distribute internet traffic to virtual machines (VMs) within an Azure virtual network (VNet). It uses a public IP address, which is accessible from the internet, and is designed for internet-facing applications — providing high availability and allowing external clients to reach services hosted in Azure. It can also provide outbound connectivity for VMs in the backend pool by translating their private IP addresses to a public IP address (Source Network Address Translation — SNAT).
An Internal Load Balancer (ILB) is used to balance traffic within a virtual network or a hybrid cloud setup, accessible from on-premises networks via VPN or ExpressRoute. It uses a private IP address from within the VNet and isn't directly exposed to the internet, which makes it ideal for internal, multi-tier applications — application servers, databases, and so on — that need load balancing and high availability without direct internet exposure. Access to the ILB's frontend IP is restricted to resources within the associated VNet or connected on-premises networks.
Summary of Differences
| Feature | Public Load Balancer | Internal Load Balancer |
|---|---|---|
| Traffic Type | Internet-facing (external) | Internal to VNet or hybrid network |
| Frontend IP | Public IP address | Private IP address |
| Internet Access | Accessible from the internet | Not accessible from the internet |
| Outbound SNAT | Provides SNAT for outbound VM connections | Does not provide SNAT for outbound VM connections by default (requires additional configuration for internet access) |
| Security | Requires careful Network Security Group (NSG) configuration | Inherently more secure for internal components |
| Use Cases | Web servers, public APIs, internet-facing applications | Internal application tiers, backend databases, line-of-business applications |
Azure Load Balancing Services
| Feature/Service | Azure Front Door | Application Gateway | Traffic Manager | Load Balancer |
|---|---|---|---|---|
| Type | Global | Regional | Global | Regional/Global |
| Layer | Layer 7 (HTTP/HTTPS) | Layer 7 (HTTP/HTTPS) | DNS-based | Layer 4 (TCP/UDP) |
| Primary Use Case | Web traffic load balancing, application acceleration, and global routing | Web application firewall, TLS/SSL termination, and HTTP load balancing | DNS-based traffic routing for high availability and performance | Internal and external load balancing for non-HTTP(S) traffic |
| Key Features | Path-based routing, TLS/SSL offload, Web Application Firewall (WAF), URL-based routing | Path-based routing, TLS/SSL offload, Web Application Firewall (WAF), URL-based routing | DNS-based routing, geographic routing, priority routing, weighted routing | High availability, low latency, zonal and zone-redundant endpoints |
| Scalability | High | High | High | High |
| Cost | Based on data processed and rules applied | Based on data processed, rules applied, and SKU | Based on DNS queries, health checks, and data points processed | Based on rules and data processed |
Note that
Application Gatewayhere means the V2 SKU: V1 was retired on April 28, 2026, so any deployment still referencing V1 needs to migrate.
Session Persistence
By default, Load Balancer distributes network traffic among backend VM instances using a five-tuple hash (source IP, source port, destination IP, destination port, and protocol). This provides stickiness only within a single transport session — a new session from the same client, even from the same source IP, can land on a different VM once the source port changes. Session persistence changes this behaviour so that successive requests from the same client are handled by the same backend instance; it's also known as session affinity, source IP affinity, or client IP affinity, and — when configured — uses a two-tuple (source IP and destination IP) or three-tuple (source IP, destination IP, and protocol type) hash instead of the default five-tuple hash. Concretely, this gives you three options: None, the default, where any healthy VM can handle each request via the five-tuple hash; Client IP (2-tuple), where the same backend instance handles successive requests from the same client IP address; and Client IP and protocol (3-tuple), where the same backend instance handles successive requests from the same client IP address and protocol combination.
Sources
- SLA for Virtual Machines — Azure
- Azure Load Balancer distribution modes — Microsoft Learn
- Azure Load Balancer components | Microsoft Learn
- Azure Public IP address prefix — Azure Virtual Network | Microsoft Learn
- Frequently asked questions — Azure Load Balancer | Microsoft Learn
- We're Retiring Application Gateway V1 in April 2026 — Microsoft Learn