Azure Load Balancer
Azure Load Balancer is a managed, regional Layer 4 service that distributes TCP and UDP traffic across a set of backend resources—typically virtual machines or instances in a Virtual Machine Scale Set. It provides a stable frontend IP address that clients connect to, transparently forwarding packets to healthy backend instances based on a flow‑hash algorithm. Because it operates at the transport layer, it does not inspect HTTP request paths, headers, or application payloads, and it does not terminate TLS connections. That simplicity makes it a foundational building block for highly available, horizontally scalable services where low‑latency, high‑throughput traffic distribution is the primary requirement.
This page orients you within the Azure Load Balancer topic area. It explains the service's role, core concepts, and common use cases, and it distinguishes Azure Load Balancer from other Azure traffic services. For architectural depth, production best practices, and troubleshooting procedures, follow the links in the topic‑cluster navigation at the end.
Layer 4 load balancing in a nutshell
Azure Load Balancer acts as a transparent traffic director. Clients send packets to a frontend IP configuration—either a public IP address reachable from the internet or a private IP address inside a virtual network. A load‑balancing rule binds that frontend endpoint to a backend pool of eligible instances. Health probes continuously verify that each backend is ready to accept new connections; instances that fail the probe are temporarily removed from the eligible pool.
When a new TCP or UDP flow arrives, the service hashes key packet fields (source IP, source port, destination IP, destination port, protocol) to select a backend. The packet's destination address is rewritten to the private IP of the chosen instance, and the packet is forwarded. Return traffic follows the same path back to the client. The flow‑based hash ensures that all packets belonging to the same transport‑layer conversation reach the same backend for the life of the connection.
The diagram shows the separation between the data path (solid lines) and the health‑probe path (dashed lines). Probes do not carry application traffic; they are a separate control signal that determines which backends are eligible.
Core components
| Component | Role |
|---|---|
| Frontend IP configuration | The IP address and port that clients target. Can be public (internet‑facing) or internal (private VNet address). |
| Backend pool | The collection of VMs, scale set instances, or IP addresses that can receive traffic. Membership alone does not guarantee traffic—instances must also pass health probes. |
| Health probe | A periodic TCP or HTTP(S) check that determines whether a backend is eligible for new flows. |
| Load‑balancing rule | The mapping between a frontend IP:port, a protocol, and a backend pool, along with the health probe to use. |
| Inbound NAT rule | Static port forwarding from a frontend port to a specific backend instance and port. Typically used for administrative access, not load balancing. |
| Outbound rule | Configures Source Network Address Translation (SNAT) for outbound connections from backends through the load balancer's public frontend (optional; often replaced by NAT Gateway). |
Public versus internal load balancers
| Public Load Balancer | Internal Load Balancer | |
|---|---|---|
| Frontend IP | Public IP address | Private IP from a VNet subnet |
| Traffic source | Internet | Same VNet, peered VNets, VPN/ExpressRoute‑connected networks |
| Typical use | Internet‑facing TCP/UDP services, public APIs, game servers | Internal application tiers, private APIs, database proxies, middle‑tier services |
| Security surface | Requires NSG rules and DDoS protection; backend instances typically remain in private subnets | Traffic is isolated to your private network; NSGs and host firewalls still required |
Public load balancers expose a service to the internet but do not make backend instances public by themselves. Internal load balancers are the standard way to provide a stable private endpoint for multi‑tier architectures, keeping middle‑tier and data‑tier services off the internet entirely.
When Azure Load Balancer fits
Azure Load Balancer is a strong choice for workloads that:
- Use TCP or UDP and do not require HTTP‑level routing, host‑based routing, or request inspection.
- Need a stable regional frontend with transparent, high‑throughput traffic distribution.
- Terminate TLS on the backend instances themselves (or rely on a separate Layer 7 gateway).
- Include virtual machines, Virtual Machine Scale Sets, or network virtual appliances as backends.
- Require internal service‑to‑service load balancing in a multi‑tier architecture.
It is not the right tool when you need URL‑based routing, host‑based routing, cookie‑based session affinity, TLS termination at the load balancer, or a web application firewall (WAF). In those cases, Azure Application Gateway or Azure Front Door should replace or complement the load balancer.
How it compares to other Azure traffic services
| Service | Primary role | Layer | Scope | HTTP‑aware routing | TLS termination | WAF | Inbound/Outbound |
|---|---|---|---|---|---|---|---|
| Azure Load Balancer | Layer 4 TCP/UDP distribution | 4 | Regional | No | No | No | Inbound (LB rules), optional outbound SNAT |
| Azure Application Gateway | Regional HTTP/HTTPS reverse proxy | 7 | Regional | Yes (URL, host, headers) | Yes | Yes | Inbound |
| Azure Front Door | Global HTTP/HTTPS entry and acceleration | 7 | Global | Yes (URL, host, headers) | Yes | Yes | Inbound |
| Azure Traffic Manager | DNS‑based traffic steering | DNS | Global | No | No | No | Inbound (DNS level) |
| Azure NAT Gateway | Managed outbound internet connectivity | 3/4 | Regional (subnet) | No | No | No | Outbound |
These services are often combined. For example, you can place Azure Front Door (global, Layer 7) in front of a regional internal load balancer, or pair an internal load balancer with NAT Gateway for outbound access.
SKU considerations
Azure Load Balancer offers two SKUs. Standard Load Balancer is the current production‑grade offering, with zone‑redundant frontends, secure defaults (explicit NSG rules required), and an SLA of 99.99% when you have at least two healthy backend instances. Basic Load Balancer was a legacy SKU with limited features, no availability‑zone support, and no SLA; it has been retired and is no longer available for new deployments. All new designs should use the Standard SKU. Exact capabilities, limits, and lifecycle status should always be verified against the latest official Azure documentation.
Security and production concerns at a glance
Several critical architectural decisions affect the security and reliability of a load‑balanced service:
- Health‑probe design – A probe that only checks a TCP port might not detect a hung application; a probe that chains through many downstream dependencies can trigger cascading failures.
- Backend readiness – An instance in the backend pool is not automatically ready. The health probe is the gate.
- Network Security Groups (NSGs) – With the Standard SKU, you must explicitly allow traffic (including health probes from the
AzureLoadBalancerservice tag). - Outbound connectivity – Backend VMs do not have internet access by default. Plan explicit egress through outbound rules or, preferably, Azure NAT Gateway.
- Availability Zones – Distributing backends across zones and using a zone‑redundant frontend improves resilience against zone‑level failures.
- Stateless design – Layer 4 distribution pins connections to backends. Store session state externally so any instance can handle requests after a failover.
- Administrative access – Avoid exposing SSH or RDP through broad inbound NAT rules. Prefer Azure Bastion or just‑in‑time access.
The deep‑dive pages in this topic cluster provide detailed guidance on each of these areas.
Topic cluster: where to go next
These pages build a complete understanding of Azure Load Balancer, from concept to production:
- What Is Azure Load Balancer? Overview, Components, and Real-World Use Cases – A structured overview of the service, its architecture, and the workloads it serves. Start here if you are new to Azure Load Balancer.
- Azure Load Balancer Architecture Guide – A detailed look at traffic flow, configuration decisions, high availability, security, and design trade‑offs. Read this when you are designing a load‑balanced architecture.
- Azure Load Balancer Best Practices for Production Workloads – Practical recommendations for health probes, backend readiness, NSGs, outbound connectivity, zone redundancy, and operational procedures.
- Azure Load Balancer Troubleshooting Guide – Symptom‑driven diagnostics covering unreachable frontends, unhealthy backends, SNAT exhaustion, asymmetric routing, and common configuration errors.
Decision summary
Choose Azure Load Balancer when you need a simple, high‑performance Layer 4 distributor for TCP or UDP services running on Azure VMs or scale sets. It provides a stable endpoint, transparent pass‑through, and tight integration with Azure networking. Pair it with Application Gateway or Front Door when Layer 7 routing, TLS offload, or WAF is required. For outbound internet access from backend instances, design explicit egress with NAT Gateway rather than relying on incidental SNAT through the load balancer.