Azure Load Balancer spreads incoming network traffic across several servers so that no single server is overwhelmed.

Let us start with a few basic words. Azure is Microsoft’s cloud platform, a large collection of computers in data centers that you can rent whenever you need them. A server is simply a computer that answers requests from other computers, for example a computer that sends a web page to your browser. A virtual machine, or VM, is a server that exists as software on one of Microsoft’s big machines. Traffic is the stream of messages that travels across a network between a user and a server.

One server can only handle a limited number of users at once. If your website becomes popular, a single server will slow down or even crash. The usual answer is to run several identical servers and share the work between them. But then a new question appears: how does a user’s request know which server to visit? That is exactly the job of a load balancer. It sits in front of the servers, receives all the requests, and passes each one to a healthy server.

Azure Load Balancer works at what experts call Layer 4 of the network model. That means it looks at basic delivery details such as the address, the port number and the type of connection (TCP or UDP), but it does not read the content of the message itself. Because it does not open the message, it is extremely fast and can handle millions of requests per second with very low delay.

Load balancing solves three problems at once: too much traffic, server failure, and growth.

Before we study the details, let us see why this service matters. Without a load balancer, an application running on a single server has several weaknesses.

A load balancer answers all four problems. It shares requests across many servers, which reduces overload. It checks the health of every server and stops sending traffic to a broken one, which removes the single point of failure. It lets you add more servers when demand grows, and it lets you update servers one at a time while the others keep serving users.

The first big choice is whether the load balancer faces the internet or stays inside your private network.

Azure Load Balancer comes in two main types, depending on who needs to reach your servers.

An IP address is the numeric address that identifies a device on a network, a little like a house number. A virtual network, often called a VNet, is your own private network inside Azure, isolated from other customers. A public IP can be reached from the internet, while a private IP exists only inside your VNet.

A load balancer is made of a few simple parts that work together.

To understand how traffic flows, you must know the main components. Each one has a clear and simple role.

flowchart LR
    U["Users on the internet"] --> F["Frontend IP configuration"]
    F --> R["Load balancing rule"]
    R --> P["Backend pool"]
    H["Health probe"] -. "checks each server" .-> P
    P --> V1["Server 1"]
    P --> V2["Server 2"]
    P --> V3["Server 3"]
        

Read the diagram from left to right. Users reach the frontend address. The load balancing rule says, “traffic arriving here should go to this backend pool.” The health probe quietly checks the servers in the background, and only healthy servers receive traffic.

The frontend is the single door; the backend pool is the room full of workers behind it.

Frontend IP configuration

Users never need to know the address of any individual server. They only know the frontend IP, or a name that points to it. This is very helpful: you can add servers, remove servers, or replace them completely, and the users keep using the same address. A load balancer can hold more than one frontend IP, so a single set of servers can serve several websites or services at once.

Backend pool

The backend pool is the list of targets that receive the traffic. You can add servers to the pool by their network interface or by their IP address. Typical members are individual VMs, VMs in an availability set, or the many identical VMs that make up a virtual machine scale set, which is a group of VMs that Azure can grow and shrink automatically. When a scale set adds a new VM, that VM can join the backend pool automatically, so traffic reaches it without any manual work.

A health probe is a regular check that lets the load balancer avoid sending traffic to broken servers.

A load balancer that blindly sent requests to a crashed server would be worse than useless. To avoid this, Azure uses health probes. A probe is a tiny test message that the platform sends to each server in the backend pool at regular intervals. If a server answers correctly, it is marked healthy. If it fails to answer several times in a row, it is marked unhealthy, and the load balancer stops sending new connections to it. When the server recovers and answers again, it is added back automatically.

You choose how often the probe runs and how many failures in a row mark a server as unhealthy. A shorter interval detects failures sooner, but creates a little more checking traffic. A longer interval is calmer, but a broken server may keep receiving requests for a few seconds longer.

The rule decides which traffic goes where, and the distribution mode decides how users are matched to servers.

A load balancing rule connects the front door to the room behind it. A typical rule says, “Any traffic arriving at this frontend IP on port 443 should be sent to port 443 of the servers in this backend pool, using this health probe.” You can create several rules on the same load balancer for different ports and services.

How does it pick a server?

By default, Azure Load Balancer uses a method that looks at five pieces of information about each connection: the source address, the source port, the destination address, the destination port, and the protocol. These five values are combined into a number, and that number decides which server receives the connection. This is called a five-tuple hash. Because the source port changes with every new connection, the same user’s different connections may reach different servers, which spreads the load evenly.

Session persistence

Sometimes you want the same user to keep returning to the same server, for example when the server remembers a shopping basket in its own memory. Azure Load Balancer supports source IP affinity, also called session persistence. In this mode, only the user’s address, or the address and protocol, is used to pick the server, so the same user is sent to the same server as long as it stays healthy and in the pool.

Following one request from start to finish makes the whole system easy to picture.

Suppose a customer opens your store’s website. Their browser connects to your public frontend address. The load balancer receives the connection, looks at the five details we described, and picks a healthy server from the backend pool. It then forwards the traffic to that server. The reply from the server travels back to the customer along the same flow.

An important feature of Azure Load Balancer is that it is not a proxy. A proxy is a middleman that takes a request, makes a fresh request of its own, and then relays the answer. Azure Load Balancer does not do this. It forwards the original connection, so the server can see the real address of the user. This keeps delay low and makes the setup simple. It also means that the load balancer does not read, change or cache the content.

sequenceDiagram
    participant C as Customer
    participant LB as Load Balancer
    participant S1 as Server 1
    participant S2 as Server 2
    LB->>S1: Health probe
    S1-->>LB: Healthy
    LB->>S2: Health probe
    S2--xLB: No answer
    C->>LB: Open connection to frontend
    LB->>S1: Forward to a healthy server
    S1-->>C: Reply
        

In the diagram, the probe to Server 2 gets no answer, so the load balancer marks it unhealthy and sends the customer to Server 1. Nothing else needs to happen. When Server 2 returns to health, the next probes will succeed and it will rejoin automatically.

Azure sells load balancers in different flavors, and today the Standard SKU is the one to use.

A SKU is simply a product version with its own features and price. Azure Load Balancer has had more than one over the years, and it is important to know what is current.

Regional and global tiers

Apart from the SKU, there are two tiers. A regional load balancer works inside one Azure region, which is a geographic area with Azure data centers. A global load balancer, also called a cross-region load balancer, sits in front of several regional load balancers and gives you a single worldwide address. It sends each user to the closest healthy region, and if a whole region has problems, traffic moves to another one.

Zones let your load balancer and servers survive the loss of an entire data center building.

An availability zone is a physically separate location inside an Azure region, with its own power, cooling and networking. A region with zones has at least three of them. If one building loses power, the other two keep running.

A Standard load balancer can be made zone-redundant. In this setup, the frontend address is served from all zones at the same time, so if one zone fails, the frontend stays available through the remaining zones. You can also make a frontend zonal, which ties it to one chosen zone. This is useful when you want to keep traffic inside a single zone for the lowest delay, but it gives no protection against the loss of that zone.

Sometimes you need to reach one particular server instead of any server in the pool.

The load balancing rules we studied pick any healthy server. But administrators sometimes need to connect to one exact machine, for example to repair it. NAT stands for Network Address Translation, a technique that rewrites the destination of traffic. An inbound NAT rule says, “Traffic arriving at this frontend on port 50001 should go to Server 1 only, on its management port.” Another rule can send port 50002 to Server 2.

Load balancers also help private servers reach the internet, and this needs careful planning.

So far we discussed traffic coming in. But servers also need to go out, for example to download updates or call an external service. Servers with only private addresses cannot be reached from the internet, and replies must find their way back. For this, Azure uses SNAT, short for Source Network Address Translation. It replaces the server’s private address with a public one on the way out, and remembers the connection so that the reply returns to the right server.

Each public IP address has a limited number of ports it can use for these outgoing connections. If many servers open many connections to the same destination, the ports can run out, and new outgoing connections fail. This is called SNAT port exhaustion, and it is a classic cause of mysterious connection errors in busy applications.

Ways to manage outbound traffic

A few advanced options solve particular problems, and it helps to know what they are for.

Why idle timeout matters

Many beginners meet idle timeout by surprise. An application opens a connection to a server, then sits quietly for several minutes. The load balancer, seeing no traffic, forgets the connection. When the application finally sends data, the connection no longer exists and an error appears. Two fixes are common: have the application send a tiny keep-alive message now and then, or raise the idle timeout setting within the allowed limit.

The Standard load balancer is closed to inbound traffic until you explicitly allow it.

The Standard SKU follows a principle called secure by default. A public Standard load balancer and its public IP do not accept inbound traffic unless a network security group allows it. A network security group, or NSG, is a set of allow and deny rules attached to a subnet or a network interface. This is like a building where every door is locked until you hand out keys.

Azure has several traffic services, and choosing between them is one of the most common beginner questions.

Azure Load Balancer is not the only service that distributes traffic. Each of the others works at a different level and solves a different problem.

flowchart TD
    S["What traffic do you have?"] --> Q1{"Web traffic over HTTP or HTTPS?"}
    Q1 -- No --> A["Azure Load Balancer"]
    Q1 -- Yes --> Q2{"Need URL routing or a web firewall?"}
    Q2 -- No --> A
    Q2 -- Yes --> Q3{"Users in many regions?"}
    Q3 -- No --> B["Application Gateway"]
    Q3 -- Yes --> C["Azure Front Door"]
    A --> Q4{"Need DNS-based routing across regions?"}
    Q4 -- Yes --> D["Add Traffic Manager or global load balancer"]
        

Often, these services are combined. A global entry point may send users to the closest region, an Application Gateway may handle web rules there, and an internal Azure Load Balancer may balance traffic between application servers behind it.

Real systems usually combine a public load balancer in front and an internal one in the middle.

Let us see how the pieces combine in a very common design. A multi-tier application splits the system into layers: a web tier that talks to users, an application tier that runs business logic, and a data tier that stores information. Each tier has several servers, and each needs a load balancer in front so that the failure of one server does not stop the layer.

flowchart TD
    U["Users"] --> PLB["Public Load Balancer"]
    PLB --> W1["Web server 1"]
    PLB --> W2["Web server 2"]
    W1 --> ILB["Internal Load Balancer"]
    W2 --> ILB
    ILB --> A1["App server 1"]
    ILB --> A2["App server 2"]
    A1 --> DB["Database tier"]
    A2 --> DB
        

Users only ever meet the public load balancer. The web servers talk to the application tier through an internal load balancer, which has no public address. The database tier is not reachable from the internet at all. This layered layout reduces the number of exposed doors and lets each tier grow or shrink on its own.

A handful of metrics tell you whether the load balancer and its servers are healthy.

Azure Monitor collects numbers from your load balancer, called metrics. You can display them on charts and set alerts when they cross a limit. Standard load balancers provide a rich set of metrics.

A simple troubleshooting path

Every tool has strengths and boundaries, and knowing both leads to better designs.

The key idea is to match the tool to the job. When you need speed and support for all kinds of traffic, Azure Load Balancer is excellent. When you need to look inside web requests, pair it with or replace it by a Layer 7 service.

The bill depends mainly on how many rules you have and how much data passes through.

For the Standard SKU, pricing is built from a few parts. There is a charge related to the number of load balancing and outbound rules you configure, and a charge based on the amount of data processed. Public IP addresses used by the load balancer have their own price. Using a NAT Gateway, a cross-region tier, DDoS protection or extra services adds to the total. Exact prices change and differ by region, so always check the official pricing page before estimating a budget.

Habits that experienced teams follow, and traps that beginners often fall into.

Seeing how organizations use the service makes the ideas easier to remember.

No. Azure Load Balancer works at Layer 4 and forwards TCP and UDP traffic without reading it. Application Gateway works at Layer 7, understands web requests, and can route by URL, end secure connections and include a web firewall. They are often used together.

It can forward HTTPS traffic because HTTPS runs over TCP, but it does not end or inspect the secure connection. Your servers handle the encryption. If you want the secure connection ended at the entrance, use Application Gateway or Front Door.

The health probe fails several times in a row, and the load balancer stops sending new connections to that server. When the server recovers and passes the probe again, it is added back automatically.

Yes. A load balancer can have several frontend IP addresses and several rules, so different ports or addresses can lead to different backend pools or services.

No. Backend servers can have only private addresses. The public load balancer holds the public address for inbound traffic, and outbound traffic can use a NAT Gateway or outbound rules.

The most common causes are a security rule blocking the Azure probe address, the application not listening on the probe port, or a wrong probe path. Check these three first.

Yes, using source IP affinity, but it is better to design stateless servers that keep user data in a shared place, so persistence is not needed.

No. The Basic SKU has been retired, so new designs should use Standard, and any remaining Basic load balancers should be upgraded. Check the official documentation for the latest status.

Azure Load Balancer is the fast, simple traffic guide at the entrance of your cloud applications. It shares incoming TCP and UDP traffic among healthy servers, removes failed servers automatically, and lets you grow or shrink your backend without changing the address that users see. You have learned how public and internal load balancers differ, how the frontend, backend pool, health probe and rules fit together, how distribution modes and session persistence work, and how zones, outbound rules, NAT rules and special features solve particular problems.

You have also seen where Azure Load Balancer ends and where services such as Application Gateway, Front Door and Traffic Manager begin. The best designs combine the right tools, keep servers stateless, test health probes, spread resources across zones, and plan outbound connections on purpose.