Azure Load Balancer

About Azure Load Balancer

Azure Load Balancer is Microsoft's Layer 4 load-balancing service for distributing TCP and UDP traffic across backend virtual machines and virtual machine scale sets. It can be deployed as a public or internal load balancer, and Microsoft currently offers Standard and Gateway SKUs after retiring Basic Load Balancer on September 30, 2025. It is designed for low-latency network traffic distribution rather than application-layer routing, TLS termination, or web application firewall functions.

What is Azure Load Balancer used for?

Azure Load Balancer is used when an application needs to distribute TCP or UDP flows across multiple backend instances while keeping network latency low. Typical scenarios include internet-facing services behind a public frontend, private services behind an internal frontend, highly available virtual machine applications, and outbound connectivity for backend instances.

The service works at Layer 4 of the OSI model. It does not inspect URLs, cookies, or application content. Azure Load Balancer sends flows to healthy backend instances according to configured load-balancing rules and health probes. This makes it a better fit for raw network traffic than products such as Azure Application Gateway or Azure Front Door, which operate at the HTTP and HTTPS application layer.

How does Azure Load Balancer distribute traffic?

Microsoft documents a tuple-based hashing algorithm for distributing inbound flows. By default, the service uses a five-tuple hash built from source IP, source port, destination IP, destination port, and protocol. Health probes determine which backend instances are eligible for new flows.

The main building blocks are frontend IP configurations, backend pools, health probes, load-balancing rules, inbound NAT rules, outbound rules, and high-availability ports. A public load balancer can expose internet-facing services, while an internal load balancer keeps the frontend inside a virtual network for private or hybrid access.

What Azure Load Balancer SKUs are available now?

Microsoft currently documents Standard Load Balancer and Gateway Load Balancer as the active SKUs. Basic Load Balancer was retired on September 30, 2025, so buyers should not design new deployments around Basic.

Standard Load Balancer is the general-purpose option for regional and global Layer 4 traffic distribution. Gateway Load Balancer is intended for chaining third-party network virtual appliances such as firewalls, packet-inspection systems, intrusion-detection systems, or other transparent network functions. Gateway Load Balancer is not a replacement for Standard Load Balancer in ordinary application load-balancing scenarios.

How does pricing work?

Pricing was checked against Microsoft's current Azure pricing page on August 26, 2026. Microsoft does not present one universal flat price because cost depends on SKU, rules, processed data, gateway usage, and bandwidth. Standard Load Balancer pricing is based on configured load-balancing and outbound rules plus data processed. The first group of rules is billed at an hourly rate, additional rules are billed separately, and inbound NAT rules do not count toward the priced rule total.

Microsoft also notes that data-processing charges are separate from Azure bandwidth charges. Standard Load Balancer has no hourly charge when no load-balancing or outbound rules are configured. Gateway Load Balancer uses gateway-hour, chain-hour, and data-processed meters. Actual currency values vary by region and agreement, so buyers should use the Azure pricing page and calculator for their deployment.

How does Azure Load Balancer handle availability and health?

Standard Load Balancer can distribute traffic across availability zones and is designed for highly available TCP and UDP services. Health probes test backend availability and prevent new flows from being sent to endpoints that fail the configured probe.

Designers still need to deploy enough healthy backend instances and decide how those instances span zones or regions. The load balancer itself does not make an application resilient if every backend depends on the same failing component. Global and cross-region patterns should also be evaluated alongside Azure Front Door and other global traffic services depending on protocol and application requirements.

Azure Load Balancer vs Application Gateway vs Front Door

Azure Load Balancer is the right starting point for Layer 4 TCP or UDP distribution, especially for virtual machines and scale sets inside a region. Azure Application Gateway is a regional Layer 7 option for HTTP and HTTPS workloads that need features such as host-based routing, URL-path routing, TLS termination, or Web Application Firewall. Azure Front Door is a global edge service for HTTP and HTTPS routing, acceleration, caching, failover, and web application firewall scenarios.

These services can be complementary rather than mutually exclusive. A large architecture may use Front Door globally, Application Gateway regionally, and Load Balancer for lower-level TCP or UDP traffic behind the application layer.

What are the main limitations?

The biggest limitation is that Azure Load Balancer is intentionally a Layer 4 service. It does not provide URL routing, cookie affinity at the application layer, built-in web application firewall functions, or HTTP-specific optimization. Those needs point toward Application Gateway or Front Door.

Another consideration is outbound connectivity. Outbound rules, public IP design, NAT Gateway, and platform changes can affect how backend virtual machines reach the internet. Network teams should design inbound and outbound paths explicitly rather than assuming a load balancer solves both automatically. Pricing also includes data-processing and bandwidth considerations, so high-volume traffic can create meaningful cost even when the load-balancing configuration itself is simple.

Who should choose something else?

Choose Azure Application Gateway instead when the main requirement is HTTP or HTTPS routing based on hosts or URL paths, TLS offload, or regional web application firewall protection. Choose Azure Front Door when traffic must be accelerated and routed globally at Microsoft's edge, especially for multi-region web applications and CDN scenarios.

Choose Azure NAT Gateway when the requirement is primarily scalable outbound connectivity for private resources rather than inbound load balancing. Teams running Kubernetes or Azure Container Apps should also evaluate the native ingress and service constructs of those platforms before adding an external Load Balancer layer. Azure Load Balancer is strongest when the requirement is clear, high-performance Layer 4 distribution for TCP or UDP workloads.