Start with the big picture: what it does, where it lives, and what it does not do.

A load balancer is a traffic director. It receives network connections from users and hands each one to one of several servers behind it. The word load means the amount of work, and balancing means sharing that work fairly. Azure Load Balancer is Microsoft’s built-in, fully managed load balancer for the Azure cloud. You do not install it on a machine, patch it, or restart it. You describe what you want in the Azure portal, and Azure runs the traffic director for you.

It works at what network engineers call Layer 4. Networking is described in layers, like floors of a building. Layer 7 is the top floor, where the web conversation happens: web addresses, cookies, and page contents. Layer 4 is a lower floor, called the transport layer, which only sees TCP and UDP connections. TCP is the careful protocol that makes sure every piece of data arrives in order, like registered mail. UDP is the quick protocol that just sends, like a postcard. A Layer 4 load balancer looks only at the envelope of a message: where it came from, where it is going, and which protocol it uses. It does not open the letter.

A short history

Load balancing is older than the cloud. In the 1990s companies bought expensive hardware boxes to spread web traffic. When Azure launched, it needed its own built-in version that could handle millions of connections without anyone buying a box. Microsoft built the Azure load balancer as software that runs across its data centers, and researchers there have publicly described the early ideas behind it. Over the years the service gained health checks, zone support, a Standard version with stronger guarantees, a global tier for spreading traffic across regions, and a gateway version for security appliances. The older Basic version was retired in September 2025, so everything today builds on the Standard family.

Every tool exists because something hurt. Here is what hurts without a load balancer.

Imagine you run an online shop on a single server. On a normal day it copes. On the day of a big sale, ten times more shoppers arrive, and the server runs out of memory and processing power, a state called overload. Pages crawl, then stop. You could buy a bigger server, which is called scaling up, but there is always a limit to how big one machine can be, and a bigger machine still fails as a single point.

The alternative is scaling out: run many ordinary servers side by side and share the traffic. This is cheaper, more flexible, and more resilient. But it creates a new question. Shoppers type one address into their browser. Which of the many servers answers? Somebody has to be the single front door. That is the load balancer.

A second problem is failure. Servers crash, get patched, or run out of disk space. Without a traffic director, users keep being sent to a dead machine and see errors. With a load balancer, a failed server is detected and quietly skipped. This idea is called high availability, which simply means the service stays up even when parts of it break.

Before diving into parts, learn the few labels that Azure puts on every load balancer.

An Azure load balancer has a type. A public load balancer has a public IP address that anyone on the internet can reach. It receives traffic from outside and sends it to your servers. An internal load balancer, also called a private load balancer, has only a private address inside your own virtual network. It spreads traffic between your own tiers, for example from web servers to application servers, and cannot be reached from the internet. A virtual network, shortened to VNet, is your private network inside Azure.

It also has a SKU, a word meaning product edition. The Standard SKU is the main one. It is designed for production, works across availability zones, and is secure by default, meaning it blocks inbound traffic until you explicitly allow it using a network security group, which is a list of allow and deny rules. The older Basic SKU has been retired. There is also the Gateway SKU, a special type built for security and network appliances, which you will meet later.

Finally there is a tier. The default is the Regional tier, which balances traffic among servers inside one Azure region. The Global tier, sometimes called cross-region, sits in front of several regional load balancers and spreads traffic across regions around the world.

An Azure load balancer is made of five simple building blocks. Once you know them, every design becomes a puzzle of arranging the same pieces.

The first building block is the frontend IP configuration. This is the address that clients connect to. It can be a public IP address or a private one. The second is the backend pool, the group of servers that actually do the work. The third is the health probe, a small repeated check that asks each server, “Are you alive and ready?” The fourth is the load balancing rule, which says “traffic arriving at this frontend address and port should go to the backend pool on that port.” The fifth family includes inbound NAT rules and outbound rules, which handle special cases such as reaching one particular server or letting servers go out to the internet.

flowchart LR
    C["Clients on internet"] --> FE["Frontend IP configuration"]
    FE --> R["Load balancing rule"]
    R --> BP["Backend pool"]
    HP["Health probe"] -.->|"checks every server"| BP
    BP --> S1["Server 1"]
    BP --> S2["Server 2"]
    BP --> S3["Server 3"]
    N["Inbound NAT rule"] -.-> S1
    O["Outbound rule"] -.-> BP
    

Read the picture from left to right. A client connects to the frontend address. The load balancing rule matches that connection and chooses the backend pool. Inside the pool, the load balancer picks one healthy server. Meanwhile the health probe keeps watching every server and tells the load balancer which ones may receive new traffic. The dotted lines show the optional helpers: a NAT rule can point a specific port to one specific server, and an outbound rule lets the servers reach out to the internet.

The two ends of the pipe: where traffic enters and where it ends up.

A frontend IP is simply an address. For a public load balancer, it is a public IP address resource, and with the Standard SKU this address is static, meaning it does not change. For an internal load balancer, the frontend is a private address picked from one of your subnets. A subnet is a slice of your virtual network. One load balancer can have many frontends, which is useful when one pool of servers hosts several websites or services, each reachable at its own address.

Frontends also have a zone setting. A zone-redundant frontend is served from all availability zones of a region at once and survives the loss of any one of them. An availability zone is a physically separate building within an Azure region, with its own power, cooling, and network. A zonal frontend is tied to one chosen zone. A frontend can also be non-zonal, which leaves placement to Azure. For most production designs, zone-redundant is the sensible default.

The backend pool is the list of destinations. Members can be virtual machines, the instances in a virtual machine scale set (a group of identical machines that can grow and shrink automatically), or plain IP addresses. Membership can be defined by the machine’s network card or directly by IP address. Adding a new server to the pool takes effect within moments, and removing one lets in-flight connections finish in an orderly way. A Standard load balancer supports a very large number of backend instances, in the thousands, which is plenty for nearly any design.

The load balancer must never send visitors to a broken server. Health probes are how it knows.

A health probe is a tiny test that the load balancer repeats on every backend server at regular intervals. The simplest kind is a TCP probe: the load balancer tries to open a connection to a chosen port. If the server accepts it, the server is considered healthy. An HTTP probe or HTTPS probe goes one step further. It requests a specific web path, such as a health page, and expects a successful reply. This proves not just that the port is open but that the application is actually working.

Two numbers shape the behavior. The interval is how often the probe runs, commonly every few seconds. The threshold is how many failed attempts in a row mark a server as unhealthy. A server that fails the threshold is removed from rotation, meaning no new connections are sent to it. When it starts passing again, it is added back. Probes come from a special internal address, 168.63.129.16, which is Azure’s own platform address, so your firewall and security group rules must allow it or every server will look dead.

What happens to connections already in progress

When a server turns unhealthy, existing TCP connections to that server are generally allowed to continue until they end, while new connections go elsewhere. If every server in a pool fails its probes, the load balancer ends existing TCP flows to the pool, because there is nowhere healthy to send them. UDP behaves differently, since it has no connection: new packets simply follow the healthy set.

The rule is the brain. It decides which server gets each new connection.

A load balancing rule ties everything together. It says: “Traffic that arrives at this frontend IP, on this protocol and port, should be sent to this backend pool, on this port, as long as this health probe says the server is healthy.” One load balancer can hold many rules, so a single frontend address may serve web traffic on port 443 and another service on a different port.

To pick a server, Azure uses a hash. A hash is a mathematical shortcut that turns a list of values into a number, always giving the same number for the same inputs. By default Azure hashes five pieces of information about the connection, called the five-tuple: the source IP address, the source port, the destination IP address, the destination port, and the protocol. The resulting number maps to one backend server. Because the source port changes for each new connection, different connections from the same visitor may land on different servers, which spreads load evenly. All packets of one connection share the same five-tuple, so they always stay on the same server.

Sometimes you want a visitor to keep returning to the same server. This is called session persistence or source IP affinity. Azure then hashes only the source and destination addresses, a two-tuple, or adds the protocol for a three-tuple. Every connection from the same client address goes to the same server for as long as that server stays healthy and in the pool.

Idle timeout and TCP reset

A connection that carries no data for a while is called idle. The load balancer keeps track of each connection, and if it stays idle too long, the load balancer forgets it. This idle timeout is configurable between four and thirty minutes. If the client later sends data on a forgotten connection, it fails. Two remedies exist: enable TCP keepalives, tiny periodic messages that prove the connection is alive, and enable TCP reset on idle, which tells both sides clearly that the connection ended so applications fail quickly and reconnect instead of waiting in confusion.

Where does the load balancer actually live, and what happens to one packet from start to finish?

A common first guess is that Azure Load Balancer is a virtual machine somewhere with a lot of memory. It is not. It is a distributed, software-defined service built into Azure’s network fabric. Software-defined means the behavior is controlled by programs, not by one special box. Distributed means the work is spread across many machines, so there is no single device whose failure could take the load balancer down.

The publicly described design works in two broad parts. A pool of multiplexers, often shortened to muxes, receives traffic from the internet or the Azure network. Routing in the network spreads incoming packets across the muxes, so no single mux is a bottleneck. Each mux knows the mapping of frontends to backend servers and picks a destination using the hash described earlier. Then, on each physical host where your virtual machines run, a small component in the virtual switch, the software that connects virtual machines to the network, handles the final delivery and the return path.

One important result of this design is that the load balancer does not terminate your connection. It does not answer the client on behalf of the server. Instead it forwards packets, rewriting only the destination address to that of the chosen server. The server therefore sees the real client IP address. For many applications, such as ones that log users or apply per-client rules, this is a major advantage. On the way back, replies can often travel directly from the server to the client without passing through the load balancer again, a trick called direct server return, which saves capacity.

sequenceDiagram
    participant Client as Client
    participant Mux as Load balancer data path
    participant Host as Host virtual switch
    participant VM as Chosen backend server
    Client->>Mux: Connect to frontend IP and port
    Mux->>Mux: Hash five values and pick a healthy server
    Mux->>Host: Forward packet with new destination
    Host->>VM: Deliver packet with real client IP
    VM-->>Client: Reply goes back toward the client
    

Traffic does not only come in. Servers also need to go out, and sometimes you need to reach one server on purpose.

NAT stands for network address translation. It means swapping one address for another as packets pass through, like a receptionist who stamps the company’s main address on every outgoing letter while keeping track of which employee sent which one. NAT appears twice in a load balancer.

Inbound NAT rules

A load balancing rule sends a connection to any healthy server. Sometimes you want the opposite: to reach one specific server. An inbound NAT rule forwards a chosen frontend port to a chosen port on one chosen server. For example, frontend port 50001 could always lead to server one on its remote administration port. This is handy for management access, though modern designs often prefer safer tools such as Azure Bastion, a secure browser-based way to reach machines without exposing ports.

Outbound connectivity and SNAT

Your servers often need to call out: to download updates, call a payment service, or fetch data from an external site. Servers with only private addresses cannot simply send traffic to the internet, because a private address means nothing there. The solution is SNAT, source network address translation. The load balancer rewrites the private source address of each outgoing connection into one of its public frontend addresses, and remembers the mapping so replies come back to the right server.

Each public address offers about sixty-four thousand ports, which you can think of as numbered slots. Every outgoing connection to the same destination needs its own slot. A busy server that opens thousands of short connections to the same service can use up its share of slots, a problem called SNAT port exhaustion. When that happens, new outgoing connections fail or time out, which often looks like random application errors.

flowchart LR
    VM1["Server 1 - private IP"] --> LB["Outbound rule - SNAT"]
    VM2["Server 2 - private IP"] --> LB
    VM3["Server 3 - private IP"] --> LB
    LB -->|"Public IP and port slot"| NET["Internet service"]
    NET -->|"Reply"| LB
    LB -->|"Match slot and return"| VM1
    

Two special features solve problems that ordinary rules cannot.

High availability ports

An ordinary rule handles one port, such as 443. But some servers, like firewalls and routing appliances, must handle traffic on every port at once. Writing thousands of rules would be silly. A high availability ports rule, usually called an HA ports rule, uses a single entry that says “all protocols, all ports.” It is available on an internal Standard load balancer and is the key tool for putting groups of network virtual appliances, which are virtual firewalls or routers from security vendors, behind a single address for resilience and scale.

Floating IP

Normally the load balancer rewrites the destination address to the chosen server’s own address. With floating IP, also called direct server return, the destination address is left as the frontend address, and the server is configured to accept traffic for that address. This lets several servers share the same address and port, or lets one cluster move a service from one server to another by simply deciding which server answers for the address. It is widely used by database clusters such as SQL Server Always On availability groups, where a listener address must always point to whichever server currently holds the main copy of the data.

Reliable systems are built by assuming something will break and planning what happens next.

Azure Load Balancer’s Standard SKU carries an availability target of 99.99 percent when you have at least two healthy backend instances. That figure allows only about fifty-two minutes of downtime in a year. Reaching it in your own system depends on your design, not just on the load balancer, because a perfect load balancer in front of a single server is still a single point of failure.

Zones are the core tool. A zone-redundant load balancer keeps working even if one entire zone fails, because its frontend lives in all zones at once. If you spread your backend servers across at least two zones as well, the loss of a zone removes only a share of the servers, and the health probes quickly mark them unhealthy. The survivors carry the load. Remember to leave spare capacity: if you have three zones and lose one, the other two must absorb the extra work.

Failure scenarios and recovery

Notice that a failing probe can also cause trouble when it is too touchy. If the probe has a very short interval and a threshold of one failure, a brief hiccup could remove a healthy server, and then the remaining servers get even more traffic and may fail too. This domino effect is why thresholds should allow for small blips.

When your users are spread around the world, one region is not enough.

A regional load balancer lives in one region. If that region has trouble, or if your users are far away and experience slow connections, you need another layer above it. The global tier of Azure Load Balancer, also called the cross-region load balancer, does this. It sits in front of several regional Standard public load balancers, in different parts of the world, and spreads traffic among them.

It gives you a single anycast public address. Anycast is a clever network trick where the same address is announced from many places, and each user’s traffic is routed to the nearest one. Traffic enters Microsoft’s global network close to the user, and from there the global load balancer chooses a regional backend, usually the one geographically closest to the user, and falls back to others if the closest is unhealthy. Because it works at Layer 4, it keeps the original client IP and supports any TCP or UDP service, not just web traffic.

flowchart TB
    U1["Users in Europe"] --> G["Global load balancer - one anycast IP"]
    U2["Users in Asia"] --> G
    U3["Users in America"] --> G
    G -->|"closest and healthy"| R1["Regional LB - West Europe"]
    G --> R2["Regional LB - Southeast Asia"]
    G --> R3["Regional LB - East US"]
    R1 --> A1["Servers in Europe"]
    R2 --> A2["Servers in Asia"]
    R3 --> A3["Servers in America"]
    

A special version made for security and inspection appliances.

Many companies insert security tools in the path of traffic: firewalls that block attacks, systems that inspect packets for threats, or tools that record traffic for audits. These tools usually come as network virtual appliances, ready-made virtual machines from security vendors. Wiring them into the path of your servers, scaling them, and keeping them highly available used to take a lot of routing work.

The Gateway Load Balancer makes this simple, using what is sometimes called a bump in the wire design. You place the appliances behind a Gateway Load Balancer. Then you chain it to the frontend of a public load balancer or to the network card of a virtual machine. From then on, traffic headed to those resources is first sent through the appliances, inspected, and sent onward, without changing the original source or destination addresses and without changing your routing tables. Packets travel to the appliances wrapped in a tunneling format named VXLAN, which is like putting a letter inside another envelope so it can be delivered across a network and unwrapped on arrival.

A front door must be strong. Here is how the load balancer helps keep it that way.

The most important security trait of the Standard SKU is secure by default. A new Standard load balancer, and the public addresses behind it, will not let inbound traffic through until a network security group explicitly allows it. A network security group is a list of allow and deny rules attached to a subnet or a network card. This approach is called default deny, and it prevents accidental exposure of servers.

Because the load balancer does not open or change your traffic, it does not inspect for attacks, and it does not remove encryption. Data stays encrypted end to end if your servers use TLS. Protection against floods of fake traffic comes from Azure DDoS Protection, an add-on service that detects and absorbs huge attacks aimed at public addresses. For deeper checks, many designs combine the load balancer with Azure Firewall, a Web Application Firewall on Application Gateway, or appliances behind a Gateway Load Balancer.

You cannot fix what you cannot see. Azure gives you the numbers.

The main tool is Azure Monitor, the central place for numbers, charts, and alerts in Azure. A metric is a measurement taken over time. Standard Load Balancer publishes many of them, and a few are especially valuable. Data path availability tells you whether the load balancer’s frontend is answering test traffic. Health probe status shows how many backend servers currently pass their probes. SYN count counts new connection attempts, showing how busy you are. SNAT connection count and used SNAT ports warn you before outbound slots run out. Byte and packet counts show how much data flows.

A useful view called Insights draws a live map of your load balancer, its pools, and the health of each part, so a quick glance shows which server is red. Resource Health tells you whether Azure itself sees a platform problem. The Activity Log records every management action such as who changed a rule and when. For deeper analysis you can send metrics to a Log Analytics workspace, a searchable store, and build alerts and dashboards.

Load balancers are cheap compared with most Azure services, but knowing how the bill works prevents surprises.

Standard Load Balancer is billed mainly in two ways. First, there is an hourly charge related to the number of rules you configure, with a small number of rules included in the base price. Second, there is a charge for the amount of data processed through the load balancer, measured in gigabytes. Public IP addresses are billed separately, and so are services you add around it, such as NAT Gateway, DDoS Protection, and the global tier. Always check the current price list, since rates and included amounts change.

Because the load balancer is distributed and managed, you do not size it like a virtual machine. There is no instance size to pick and no warm-up period. It scales with the underlying Azure network. What you do plan for are limits: the maximum number of rules, frontends, and backend instances per load balancer, and the quotas on public addresses in your subscription. These numbers are large and rarely block normal designs, but very big architectures should check them early.

No tool is right for everything. A fair look at both sides helps you choose well.

The big trade-offs

Speed versus smarts. Layer 4 is quick and simple because it does not read your traffic. Layer 7 services are smarter but add processing and cost. Even spread versus stickiness. The default hash spreads connections nicely, while affinity keeps users on one server but can concentrate load, especially when many users share one network address through a corporate gateway. Simplicity versus control. Default settings are easy, while custom probes, rules, and outbound plans give precision but create more things to maintain. Regional versus global. A regional load balancer is simple and local, while the global tier adds reach and region-level failover at extra cost and complexity.

Proven recipes, and a simple guide for picking among Azure’s four load balancing choices.

Azure offers several traffic distribution services, and beginners often mix them up. Two questions sort them out. First, is the traffic web (HTTP and HTTPS) or anything else? Second, do you need distribution within a region or across the world?

Pattern: the layered three-tier application

A classic design places a public entry service in front of the web tier, then an internal load balancer between the web tier and the application tier, and another internal load balancer in front of the data tier. Each tier scales on its own, each is spread across zones, and only the very first layer is exposed to the internet.

flowchart TB
    U["Users"] --> FD["Public entry - Front Door or Application Gateway"]
    FD --> W["Web tier servers"]
    W --> ILB1["Internal load balancer"]
    ILB1 --> APP["Application tier servers"]
    APP --> ILB2["Internal load balancer with floating IP"]
    ILB2 --> DB["Database cluster"]
    NSG["Network security groups on each tier"] -.-> W
    NSG -.-> APP
    NSG -.-> DB
    

Kubernetes pattern

Azure Kubernetes Service uses Azure Load Balancer behind the scenes. When a developer creates a service of the load balancer type, AKS automatically adds a rule and a frontend address on the cluster’s load balancer. The same piece also provides outbound access for the cluster’s nodes, which is why outbound design matters here as well.

An anti-pattern is a habit that looks sensible but leads to pain.

A short checklist that separates calm operations from late-night emergencies.

Common mistakes

• Mixing editions. Resources of different SKUs cannot be combined, so plan the whole design on Standard.
• Forgetting the network security group. A new Standard load balancer rejects inbound traffic until allowed.
• Letting probes and rules disagree. A probe on one port while the application listens on another marks every server unhealthy.
• Calling the internal frontend from a backend member. The call fails because of the return path problem.
• Ignoring idle timeouts. Long quiet connections break, and users see strange hangs.
• Treating the balancer as a firewall. It spreads traffic, it does not inspect it.

Where does Azure Load Balancer shine in practice?

No. It is a managed, distributed, software-defined service built into the Azure network. There is nothing to patch, size, or restart.

Load Balancer works at Layer 4 and handles any TCP or UDP traffic quickly without reading it. Application Gateway works at Layer 7, understands web requests, and can route by path, remove TLS, and apply a web application firewall.

No. Encrypted traffic passes straight through to your servers, which hold the certificates.

Yes. Because the load balancer forwards packets instead of acting as a proxy, the real client address is preserved.

It was retired in September 2025. New and existing designs should use the Standard SKU, which is zone-aware and secure by default.

Standard is secure by default. You must allow the traffic with a network security group, and also allow health probe traffic from the Azure platform.

By default it hashes the source address, source port, destination address, destination port, and protocol, and maps the result to a healthy server. It does not measure each server’s current load.

Use source IP affinity in the rule. It keeps connections from the same client address on the same server, although stateless designs are usually better.

It happens when outgoing connections use up all available port slots on the public address. New outgoing connections then fail. Use NAT Gateway, reuse connections, and watch SNAT metrics.

Yes, with the global tier, which sits in front of regional Standard public load balancers and gives one anycast address with regional failover.

When you want to insert scalable and highly available security or inspection appliances into the path of traffic without changing addresses or building complex routing.

The reply would return to the same machine that sent the request, so the network cannot match it to a connection. Call the frontend from a different machine or tier.