What Is Azure Load Balancer? Overview, Components, and Real-World Use Cases

When a service runs on a single virtual machine, its availability and capacity are bound to that one instance. The moment that VM fails, gets rebooted, or becomes overloaded, clients lose access. A direct improvement is to run multiple identical instances and place a load balancer in front of them. The load balancer provides a stable, well‑known IP address that clients connect to, while it distributes inbound connections among the instances that are currently healthy.

This pattern—decoupling the client‑facing endpoint from the backend instances—unlocks horizontal scaling, rolling deployments, and failure isolation. It is so fundamental that virtually every production cloud service uses some form of load balancing.

Azure Load Balancer is the managed service that performs this role at Layer 4 of the OSI model for TCP and UDP workloads. It does not inspect HTTP request paths, host headers, or cookies. Instead, it works with network and transport layer information—IP addresses, ports, and protocols—to forward packets with high throughput and low latency. This article explains the architecture, core components, and use cases of Azure Load Balancer so that you can determine when it is the right tool for your design.

What Azure Load Balancer is (and is not)

Azure Load Balancer is a regional, highly available service that distributes TCP and UDP traffic among a set of backend resources—typically virtual machines or instances in a Virtual Machine Scale Set. It operates at Layer 4, meaning it uses a 5‑tuple hash of source IP, source port, destination IP, destination port, and protocol to decide where to send each new transport‑layer connection. Existing connections are pinned to the same backend for their lifetime.

Because Azure Load Balancer does not inspect application payloads, it cannot route requests based on URL paths, host headers, or cookies. It does not terminate TLS connections, provide a web application firewall, or authenticate users. Those responsibilities belong to Layer 7 services like Azure Application Gateway, Azure Front Door, or the application itself. In return, Azure Load Balancer offers simplicity, transparency, and very high performance—qualities that are ideal for non‑HTTP protocols, internal service tiers, and workloads that already handle their own TLS and application‑layer routing.

How traffic flows through Azure Load Balancer

Consider a public load balancer with a frontend IP address 203.0.113.10 listening on TCP port 443. The backend pool contains three virtual machines, each running a web server on port 8080. A health probe checks an HTTP endpoint /health on port 80 every few seconds.

1. A client sends a TCP SYN packet to 203.0.113.10:443.
2. The load‑balancing rule matches the packet based on frontend IP, port, and protocol (TCP). It identifies the backend pool and the associated health probe.
3. The health probe has previously marked two of the three instances as healthy. The third failed its last three probes and is temporarily ineligible for new connections.
4. The load balancer computes a 5‑tuple hash (source IP, source port, destination IP, destination port, protocol) and selects one of the two healthy instances.
5. The packet’s destination IP is rewritten to the private IP of the chosen backend. The source IP is preserved (the client’s IP), so the backend sees the original client address. The packet is forwarded to the backend’s network interface.
6. The backend receives the SYN, completes the three‑way handshake, and serves the request. Return traffic flows back through the same load balancer path; Azure networking ensures symmetry.
7. Meanwhile, the health probe continues to test all backends. When the unhealthy instance recovers and responds to probes again, it will automatically become eligible for new flows.

The diagram separates the data path (solid lines) from the health‑probe path (dashed). Probes are a continuous, parallel verification—they do not carry client traffic.

This flow‑based distribution has several implications:

• All packets of a single TCP connection stay on the same backend. HTTP/2 multiplexing or gRPC streaming over a single connection does not distribute requests individually.
• Adding a new, healthy instance does not rebalance existing connections. Only new flows can be routed to it.
• Traffic distribution by request count is not guaranteed. A client that opens many short‑lived connections may, by hash coincidence, send more traffic to one backend than to another. This is normal behaviour for Layer 4 load balancers.

Core components

Frontend IP configuration

The frontend IP is the address that clients target. It can be a public IP address (reachable from the internet) or an internal IP address (a private address from a virtual network subnet). A single load balancer can have multiple frontend configurations, allowing it to expose several services or tenants through distinct IPs.

Backend pool

The backend pool defines the set of resources that are candidates for receiving traffic. Members can be virtual machine NICs, Virtual Machine Scale Sets, or—with the Standard SKU—individual IP addresses. A resource in the pool is not automatically ready to serve; it must also pass health probes.

Health probe

A health probe is a periodic check that tells the load balancer whether a backend instance should receive new connections. Azure Load Balancer supports TCP probes (a successful handshake marks the instance as healthy) and HTTP or HTTPS probes (the instance must return a 200 OK on a configurable path). The probe interval and unhealthy threshold determine how quickly a failure is detected and how long recovery takes.

Probe design must balance depth and independence. A TCP probe on the application port confirms the listener is alive but does not verify the application is functioning correctly. An HTTP probe that chains through several downstream dependencies can cause cascading failures if a single dependency becomes slow. A dedicated readiness endpoint that checks only the minimal local dependencies is usually the best compromise.

Load‑balancing rule

A rule binds a frontend IP and port to a backend pool. It specifies:

• The protocol (TCP or UDP).
• The frontend port (the port clients connect to).
• The backend port (the port the backend service listens on; can differ from the frontend port).
• The health probe that determines backend eligibility.
• Optional settings such as session persistence (source IP affinity), idle timeout, and TCP reset behaviour.

Inbound NAT rule

An inbound NAT rule is not load balancing; it is a static port‑forwarding rule that maps a frontend port directly to a specific backend instance and port. It is commonly used to provide per‑instance SSH or RDP access. Exposing administrative ports to the internet is a security risk; prefer Azure Bastion, just‑in‑time access, or a private management network instead.

Outbound connectivity

Inbound load balancing and outbound internet access are separate architectural concerns. Backend instances that need to initiate connections to the internet require explicit outbound connectivity. Azure Load Balancer can provide this via outbound rules (SNAT), but NAT Gateway is generally recommended for predictable, scalable egress. An internal load balancer does not provide internet access at all; you must pair it with a NAT Gateway or another outbound solution if needed.

Public versus internal load balancers

	Public Load Balancer	Internal Load Balancer
Frontend IP	Public IP address, internet‑routable	Private IP from a VNet subnet
Traffic source	Internet clients	Resources in the same VNet, peered VNets, or connected via VPN/ExpressRoute
Typical use cases	Public‑facing TCP/UDP services, public APIs, game servers	Internal application tiers, private APIs, database proxies, middle‑tier services
Backend exposure	Backends can remain in private subnets; only the frontend is public	Backends are isolated from the internet
Security boundary	Requires strict NSG rules and DDoS protection	Relies on network isolation; NSGs and host firewalls still required

A public load balancer is the right choice when your service must be reachable from the internet. An internal load balancer is the standard way to connect tiers within a multi‑tier application: the web tier (behind a public load balancer or Application Gateway) calls the application tier through an internal load balancer, keeping the application servers off the public internet.

Where Azure Load Balancer fits

Azure Load Balancer is well suited for:

• Regional public TCP/UDP services – e.g., a custom protocol game server, a DNS resolver, or an IoT ingestion endpoint that does not require HTTP‑specific routing.
• Highly available VM‑based application tiers – multiple VMs or Virtual Machine Scale Sets providing a stateless service, with health probes removing failed instances.
• Internal APIs and application tiers – a stable private frontend IP for service‑to‑service communication, without exposing those services to the internet.
• Private service endpoints – an internal load balancer as the entry point for a private platform service consumed by other workloads in the network.
• Layer 4 exposure for container workloads – in Azure Kubernetes Service, a Kubernetes Service of type LoadBalancer creates an Azure Load Balancer to expose pods. This is a Layer 4 construct; for HTTP routing or TLS termination, a Kubernetes ingress controller or Azure Application Gateway is more appropriate.

In all these cases, Azure Load Balancer provides the connection‑level distribution, while the application handles TLS, session state, and application‑layer routing.

When Azure Load Balancer is not the right tool

Azure Load Balancer does not provide the capabilities of a Layer 7 reverse proxy or a global traffic manager. Choose a different service when:

• URL path routing, host‑based routing, or HTTP header inspection is required. → Azure Application Gateway (regional Layer 7).
• Global HTTP/HTTPS entry, edge caching, or cross‑region failover is required. → Azure Front Door (global Layer 7).
• DNS‑based traffic steering (e.g., geographic routing, priority failover) is sufficient. → Azure Traffic Manager.
• The primary goal is outbound internet access, not inbound load distribution. → Azure NAT Gateway.

Service	Layer	Scope	HTTP aware	TLS termination	WAF	Inbound/outbound
Azure Load Balancer	4	Regional	No	No	No	Inbound (LB rules), optional outbound SNAT
Azure Application Gateway	7	Regional	Yes (URL, host, headers)	Yes	Yes	Inbound
Azure Front Door	7	Global	Yes (URL, host, headers)	Yes	Yes	Inbound
Azure Traffic Manager	DNS	Global	No	No	No	Inbound (DNS level)
Azure NAT Gateway	3/4	Regional (subnet)	No	No	No	Outbound

These services are not mutually exclusive; they are often combined. For example, Azure Front Door can route global traffic to regional Application Gateways, which in turn forward to an internal Load Balancer in front of the backend VMs.

Availability and failure boundaries

Azure Load Balancer itself is highly available within a region and carries a 99.99% SLA when you deploy at least two healthy backend instances in a Standard SKU, zone‑redundant configuration. However, the load balancer is only one part of the availability picture:

• Redundant backends are essential. A single instance behind a load balancer still represents a single point of failure.
• Health probes detect failures, but there is a delay between a failure and the instance being removed from the eligible pool. During that interval, clients may still attempt to connect to a degraded instance.
• Existing connections to a failed instance are not migrated. The client must reconnect. Applications should implement retry logic with exponential back‑off.
• Availability Zone placement improves resilience. Distributing backends across zones and using a zone‑redundant frontend protects against a zonal outage.
• Cross‑region failover is not provided by the regional load balancer. Use Azure Front Door or Traffic Manager for global redundancy.

A common misconception is that a load balancer automatically creates a highly available application. If all backends fail because of a shared dependency (e.g., a database outage), or if the health probe does not accurately reflect application health, the load balancer cannot rescue the service. The health signal must be meaningful, and the application must be designed to degrade gracefully.

Production orientation

This article provides an architectural overview. Production deployments should explore several additional topics:

• Health‑probe design and readiness semantics – probing the right depth to avoid both false positives and cascading failures.
• Stateless application design – externalizing session state so that any backend can handle a request.
• Network security – NSG configuration, host firewalls, private management paths.
• Outbound connectivity – choosing between load‑balancer outbound rules and NAT Gateway.
• Monitoring – tracking data‑path availability, health probe status, and SNAT port usage.
• Deployment and lifecycle – rolling updates, graceful shutdown, and backend‑pool management.

The deeper pages in this topic cluster cover these areas systematically.

Explore further

• Azure Load Balancer – Topic hub with high‑level orientation and decision guidance.
• Azure Load Balancer Architecture Guide – Detailed architecture, traffic flow, configuration decisions, and design trade‑offs.
• Azure Load Balancer Best Practices for Production Workloads – Practical recommendations for health probes, NSGs, availability zones, outbound connectivity, and operational procedures.
• Azure Load Balancer Troubleshooting Guide – Symptom‑driven diagnostics for unreachable frontends, unhealthy backends, SNAT exhaustion, and configuration errors.

Decision summary

Azure Load Balancer provides transparent, high‑performance Layer 4 traffic distribution for TCP and UDP workloads within an Azure region. It is a foundational building block for horizontally scalable, highly available services. Use it when your application does not require HTTP‑level routing or TLS termination, and when you need a stable frontend with health‑based backend selection. For HTTP‑aware features, global entry points, or WAF, pair it with or replace it by Azure Application Gateway or Azure Front Door. Always design outbound connectivity explicitly and verify that your health probes accurately reflect application readiness.