Start with the one-sentence idea, then build up the picture slowly.

Azure Load Balancer is a managed Azure networking service that takes incoming network connections and spreads them across a group of servers. A server is a computer that provides a service to other computers, such as serving a website or answering database questions. In Azure, these servers are usually virtual machines, or VMs, which are software-made computers running on Microsoft’s hardware. Instead of every user connecting to one particular VM, users connect to the load balancer, which forwards each connection to one of several VMs that can do the same job.

Let us define a few words before going on. Traffic is the stream of data moving across a network. A connection is a conversation between two computers, such as a browser talking to a web server. An IP address is the number that identifies a computer or service on a network, like a street address for data. A port is a numbered door on a computer, so that one machine can offer many services at once, for example port 443 for secure web pages.

The word managed matters. You do not install load balancer software on a machine, patch it, or worry about its hardware failing. Microsoft runs it as part of the Azure network itself. You describe what you want, such as which address to listen on and which servers to use, and Azure does the rest.

Azure Load Balancer works at what is called Layer 4 of the network model. Network communication is often described in layers, from the physical cables at the bottom to the applications at the top. Layer 4 is the transport layer, where connections are made with protocols called TCP and UDP. A Layer 4 load balancer looks only at the addresses and ports on each connection. It does not read web page addresses, cookies, or the content inside the messages. That makes it extremely fast and simple, and it also defines what it can and cannot do, as we will see.

To see why load balancing exists, look at what happens without it.

In the early days of the internet, a website often lived on one powerful server. Visitors typed the address, their requests arrived at that machine, and it answered. This was simple, cheap, and easy to understand. For a small site with a modest number of visitors, it still works fine today.

The single point of failure

The trouble with one server is that it is a single point of failure, which means one component whose breakdown stops the whole system. If the machine crashes, loses power, needs a software update, or has a bad day, the website disappears. Visitors see an error, and the business loses money and trust. Every machine fails eventually, so relying on one is a gamble.

The limit of one machine

There is also a limit on how much one machine can do. Each server has a fixed amount of processing power, memory, and network capacity. When too many visitors arrive, the server slows down and then starts refusing requests. The usual first answer is scaling up, which means buying a bigger machine. This helps for a while, but bigger machines get very expensive, and eventually the biggest one available is not enough.

Scaling out and the need for a distributor

Scaling out means adding more machines that do the same job. It solves both problems at once: if one machine fails, the others carry on, and when traffic grows, more machines are added. But scaling out creates a new question: how does a visitor know which machine to talk to? Giving each machine a different address would be a mess. The answer is one shared address held by a distributor, the load balancer, which receives all visitors and hands each of them to a suitable machine.

Maintenance without downtime

A further benefit is smooth maintenance. With several servers, an administrator can remove one from the group, update it, test it, and put it back, while the others keep serving visitors. This allows updates in the middle of the working day without a notice reading “back soon”.

Every service exists because somebody had a painful problem. Here are the main ones.

Planned and unplanned events

Servers are taken out of service for two kinds of reasons. Planned events include software updates, scaling down at night, and deploying a new version. Unplanned events include crashes, hardware faults, and network trouble. A load balancer helps with both. For planned events, an administrator removes a server from the group gracefully. For unplanned events, the health checks notice trouble automatically.

Different kinds of traffic

Not all traffic is web traffic. Databases, game servers, voice systems, remote desktops, and many custom programs use TCP or UDP on all sorts of ports. Because Azure Load Balancer works at Layer 4, it can distribute almost any of these without knowing anything about what they carry.

Eight building blocks. Learn these and the rest of the topic becomes easy to follow.

Frontend IP configuration

The frontend is the address that users connect to. It is the single face the load balancer shows to the world. For a public load balancer, it is a public IP address reachable from the internet. For an internal load balancer, it is a private IP address inside your virtual network. One load balancer can have several frontend addresses.

Backend pool

The backend pool is the group of servers that receive the traffic. Members can be virtual machines, groups of VMs that scale automatically, or plain IP addresses. All members should be able to do the same job, because the load balancer treats them as interchangeable.

Health probe

A health probe is a small, regular test that the load balancer sends to each backend server to ask “are you alive and ready?”. A server that answers correctly stays in rotation. A server that fails several tests in a row is marked unhealthy, and receives no new connections until it passes again.

Load-balancing rule

A load-balancing rule ties everything together. It says, for example, “traffic arriving at this frontend address on port 443 should be shared among the servers in this backend pool, on port 443, using this health probe”. Without a rule, nothing is distributed.

Inbound NAT rule

NAT stands for network address translation, which means changing the address on a message as it passes through. An inbound NAT rule forwards traffic arriving on a certain port of the frontend to a specific single server, instead of sharing it. Administrators use these to reach one particular machine, for example for remote management.

Outbound rule

An outbound rule controls how servers in the backend pool reach the internet. It decides which public addresses they use and how many connection slots each server gets.

SKU

A SKU is the product edition, such as Standard or Gateway. The edition determines features, limits, and the promises made about reliability.

Flow

A flow is one connection identified by its source address, source port, destination address, destination port, and protocol. The load balancer makes its decisions flow by flow.

How the pieces fit together, from the user to the server and back.

Look at the diagram below from left to right. A user on the internet connects to the public frontend address of the load balancer. A load-balancing rule decides that this traffic belongs to a particular backend pool. The health probe tells the load balancer which servers in the pool are healthy. The load balancer then forwards the connection to one healthy server. The reply flows back to the user along the same route.

flowchart LR
    U["User on the internet"] --> FE["Frontend public IP"]
    FE --> RULE["Load-balancing rule"]
    RULE --> BP["Backend pool"]
    BP --> VM1["Server 1 - healthy"]
    BP --> VM2["Server 2 - healthy"]
    BP --> VM3["Server 3 - unhealthy"]
    HP["Health probe"] -.->|"Checks"| VM1
    HP -.->|"Checks"| VM2
    HP -.->|"Checks"| VM3

A distributed service, not a single box

It is tempting to picture the load balancer as one machine sitting in the middle of the traffic. In Azure it is not. It is part of the software-defined network, spread across the data centre’s infrastructure. Because of this design, it does not become a bottleneck or a single point of failure itself, and it can handle very large numbers of connections. The packets are not rewritten by a central device that all traffic squeezes through, which is one reason it adds so little delay.

What Microsoft manages and what you manage

Microsoft manages the load balancing platform itself: its capacity, its availability, its updates, and its distribution across the network. You manage the configuration: the frontends, pools, probes, rules, and the security rules around them. You also manage the servers behind it, including their operating systems, applications, and updates. This is the shared responsibility model, and the load balancer’s high reliability does not remove your duty to build a healthy application behind it.

Where it lives in your network

A load balancer belongs to a region and works with servers inside the virtual networks of that region. A virtual network, or VNet, is your own private network inside Azure. The backend servers sit in subnets of this network, a subnet being a smaller section of the network with its own range of addresses.

What happens between “a new connection arrives” and “a server answers”.

When a new connection arrives, the load balancer must choose a backend server for it. Many people imagine a simple turn-taking scheme, where the first connection goes to server one, the second to server two, and so on. Azure Load Balancer does not work that way. Instead it uses a mathematical fingerprint of the connection, called a hash, to decide.

The five-tuple hash

A tuple is just a fixed list of values. By default the load balancer builds a hash from five values: the source address, the source port, the destination address, the destination port, and the protocol. A hash function takes these five values and turns them into a number. The number then picks one of the healthy servers. Because the source port changes with every new connection, even a single user’s different connections may land on different servers, which spreads the load nicely.

Why a hash and not turn-taking

Hashing has two big advantages. First, the load balancer needs to remember very little, because the same connection always produces the same answer, and this keeps it fast and scalable. Second, all packets that belong to one connection reliably go to the same server, which is essential: you cannot send half of a conversation to one server and half to another. The result over many connections is an even spread, though not a perfect one, since the distribution is statistical, like coin tosses.

flowchart TD
    N["New connection arrives"] --> H["Hash source IP, source port, destination IP, destination port, protocol"]
    H --> L["Look at the list of healthy servers"]
    L --> C["Hash value picks one healthy server"]
    C --> F["Forward the connection to that server"]
    F --> M["Remember the flow so later packets follow the same path"]

Pass-through, not termination

Azure Load Balancer does not hold your connection in the middle and start a second one to the server. It is a pass-through device: the connection from the user is delivered through to the chosen server, which sees the real address of the user, and the server answers directly through the same path. This differs from services that terminate the connection and open a new one. It means the load balancer does not decrypt secure traffic, does not read page content, and does not need to hold your security certificates. Secure connections end at your servers.

Equal servers

The basic distribution treats all healthy servers as equals. It does not know that one server is busier or more powerful than another, and it does not count the active connections on each. If your servers differ widely in power, or if some requests are much heavier than others, the spread of work may be uneven. Keeping servers identical, and keeping requests reasonably similar in cost, gives the best results.

The life of a request, and the life of a load balancer project.

The path of one request

Follow a single visit. The user’s browser looks up the website name and receives the frontend public address. It opens a connection to that address on port 443. The packet reaches the Azure network, where the load balancer matches it to a rule, checks which servers are healthy, hashes the flow, and delivers the packet to the selected server. The server processes the request and sends the reply. The reply returns directly to the user, with the load balancer making sure it appears to come from the address the user contacted.

flowchart LR
    A["Plan servers and ports"] --> B["Create virtual network and servers"]
    B --> C["Create load balancer and frontend"]
    C --> D["Create backend pool and health probe"]
    D --> E["Create load-balancing rule"]
    E --> F["Open security rules for traffic and probe"]
    F --> G["Test with traffic and failure drills"]
    G --> H["Operate and monitor"]
    H --> I{"Servers added or removed?"}
    I -->|"Yes"| D
    I -->|"No"| H

Adding and removing servers

One of the pleasant things about a load balancer is how easy it is to change the pool. A new server is added to the backend pool, passes its health probe, and begins receiving new connections. A server being retired is removed, and new connections stop going to it. Existing connections to a server that is simply taken out of the pool may continue until they finish or reset, depending on the circumstances, so applications should be prepared to retry if a connection breaks.

The load balancer is only as smart as its idea of what “healthy” means.

Health probes are how the load balancer learns about the state of your servers. Every few seconds, it sends a small test to each server in the pool. The test can be of several kinds. A TCP probe simply tries to open a connection to a port, and if the server accepts it, the server counts as healthy. An HTTP or HTTPS probe requests a particular web address and expects a successful answer, which allows the application to say “I am ready” in its own way.

Thresholds and timing

A probe has settings for how often it runs and how many failures in a row mark a server as unhealthy. If it is too sensitive, a short hiccup removes a good server and causes needless reshuffling. If it is too relaxed, a broken server keeps receiving traffic for too long. A sensible middle ground detects real failures within a few seconds to a minute, without reacting to single blips.

What happens when a server fails

When a server fails its probes, the load balancer stops sending it new connections. The rest of the pool absorbs the traffic. When the server starts passing again, it is added back to the rotation. For connections already open on a failed server, the behaviour depends on the protocol and the circumstances. Those connections may break and need to be restarted by the client, so applications must tolerate this.

flowchart TD
    P["Probe runs every few seconds"] --> R{"Server answers correctly?"}
    R -->|"Yes"| H["Server stays in rotation"]
    R -->|"No"| C["Count a consecutive failure"]
    C --> T{"Failures reach the threshold?"}
    T -->|"No"| P
    T -->|"Yes"| U["Mark server unhealthy - no new connections"]
    U --> Q["Keep probing the server"]
    Q --> S{"Passes again?"}
    S -->|"Yes"| H
    S -->|"No"| Q

Make the probe honest

A TCP probe only proves that the operating system accepts connections. The web program behind it could be crashed or stuck, and the probe would still pass. For web applications, it is better to use an HTTP probe pointing at a small, light health page that checks the things the application truly needs, such as its ability to reach its database. But keep the page cheap, because it is requested constantly by every probe from the load balancer.

The probe’s source address

Probes come from a special platform address that Azure uses for such services. Your network security rules must allow traffic from this source to your servers on the probe’s port. A very common mistake is to block it, which makes every server look unhealthy and the whole service appear broken even though the servers are fine.

Choosing the right flavour and making it resilient.

Public load balancer

A public load balancer has a public IP address as its frontend. It accepts traffic from the internet and spreads it over servers that usually have only private addresses. This means the servers themselves are not directly exposed, and only the ports named in your rules can be reached through the load balancer.

Internal load balancer

An internal load balancer, sometimes called a private load balancer, has a private address from your virtual network. It is used to spread traffic between layers of an application, for example between web servers and the application servers behind them, or between your applications and a pool of database servers. It can also serve traffic that arrives from your office through a private link, such as a VPN. The outside world cannot reach it at all.

flowchart TD
    I["Internet 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

Editions

The Standard edition is the main one for production. It supports availability zones, a larger pool size, richer monitoring, and a service level promise. It is also secure by default: inbound traffic is blocked until you explicitly allow it using network security rules. The older Basic edition lacked many of these features, and Microsoft has retired it, so new designs should not use it. There is also a Gateway edition, designed to place partner network appliances, such as firewalls, transparently in the path of traffic. Check the current documentation for exact capabilities.

Zones and resilience

An availability zone is a separate data centre building, or group of buildings, inside a region, with independent power, cooling, and network. A Standard load balancer frontend can be zone-redundant, meaning it survives the loss of a whole zone, or zonal, meaning it is pinned to a single zone. For most production services, zone-redundant frontends combined with backend servers spread over several zones give the strongest protection. Remember that the load balancer cannot help if all your servers are in the zone that fails.

Global load balancing

Beyond a single region, Azure offers a cross-region or global tier of load balancer. It sits in front of regional load balancers in different parts of the world and directs users to a nearby healthy region, and fails over to another region if one is lost. This is useful for global applications that use Layer 4 traffic. Details and limits change over time, so check the current documentation.

What it costs

The Standard edition is typically billed on the number of rules you configure and on the amount of data it processes, and public IP addresses and outbound data transfer carry their own charges. Internal and public load balancers differ in some respects, and prices vary by region. Use the Azure pricing calculator with your own numbers. Because rules and data volume drive the bill, avoid creating many unnecessary rules, and review them from time to time.

Traffic leaving your network deserves as much care as traffic arriving.

Inbound NAT rules

Sometimes you want to reach one specific server rather than any server in the pool. An inbound NAT rule maps a port on the frontend to a port on one named backend server. For example, one frontend port might lead to a remote management port on server one, and another frontend port to server two. This is handy for administration, though more secure methods exist, and these ports should be tightly restricted.

The outbound problem

Your backend servers often have only private addresses, which the internet cannot route to. When such a server needs to reach the internet, for instance to download an update or call an outside service, its private address must be swapped for a public one. This swap is called SNAT, short for source network address translation. The public address is shared by many servers, so the system tells them apart using different source port numbers.

SNAT port exhaustion

Every outbound connection to the same destination address and port needs its own source port on the shared public address, and the number of ports available to each server is limited. If an application opens a great many short-lived outbound connections, such as calling an outside service for every request, it can use up its ports, and new outbound connections fail or wait. This is called SNAT port exhaustion, and it is a classic cause of mysterious, intermittent failures.

flowchart TD
    S["Backend server with private IP"] --> O{"How does it reach the internet?"}
    O -->|"Load balancer outbound rule"| LBO["Shared public IP with limited ports per server"]
    O -->|"NAT Gateway"| NG["Dedicated public IPs with large port supply"]
    O -->|"Public IP on the server itself"| PIP["Its own public IP"]
    LBO --> NET["Internet"]
    NG --> NET
    PIP --> NET

Better ways to go outbound

For heavy or important outbound traffic, Azure recommends a NAT Gateway, a dedicated service for outbound connections that offers a large supply of ports and predictable public addresses. Another option is to give each server its own public address, though this exposes it more. Whatever you choose, check that your design deliberately addresses outbound traffic, because the default arrangements may not be enough for busy applications.

Reducing the demand for ports

Applications can also help themselves. Reusing connections instead of opening a new one for each request, using connection pooling, and keeping connections alive between requests all reduce the number of source ports needed. Microsoft’s documentation describes patterns for avoiding exhaustion, and it is wise to follow them in applications that call outside services frequently.

Special settings for special jobs.

Session persistence

Some applications want a visitor’s connections to keep going to the same server, for example because the server remembers things about that visitor in its own memory. This is called session persistence or “sticky sessions”. With the default hash, a visitor’s separate connections may land on different servers. Azure Load Balancer can instead hash on fewer values, such as just the source address, or the source address and the protocol, so that the same client address tends to reach the same server.

Floating IP

Some clustered applications, such as certain database availability setups, need the backend server to use the frontend address as its own. The floating IP option, known elsewhere as direct server return, lets the server accept traffic addressed to the load balancer’s frontend address and reply directly. This is a specialist setting, normally used only when the application’s own documentation requires it.

HA ports

An HA ports rule, available on internal Standard load balancers, balances traffic on all ports and protocols at once with a single rule. This is typically used for network virtual appliances, which are software firewalls or routers running on VMs, where every kind of traffic must pass through whichever appliance is healthy. It saves you from creating a separate rule for every port.

Idle timeout and keepalive

If a connection carries no data for a while, the load balancer eventually forgets it, to free resources. This period is the idle timeout, which has a default of a few minutes and can be changed within limits. If the application sends nothing during that time, and then tries to continue, the connection may be found dead. To avoid this, applications can send tiny keepalive messages that show the connection is still in use. The load balancer can also be set to send a reset to both sides when a connection times out, so that applications notice the break immediately rather than hanging.

Same-network limits

There are some special rules in how internal load balancers behave when a backend server tries to reach its own pool’s frontend address. In certain cases, the connection can fail because of how the network treats traffic that loops back to the sender. If your design needs servers in a pool to call the same frontend, check the current documentation for this limitation and for workarounds.

Who may reach what, and how to stay safe.

Security around a load balancer has several parts. What traffic is allowed in, which is filtering. Who can change the configuration, which is access control. How attacks are absorbed, which is protection against floods. And how data stays private, which is encryption.

Network security groups

A network security group, or NSG, is a set of allow and deny rules attached to a subnet or a server’s network card. The Standard load balancer is closed by default, so traffic only reaches your servers if an NSG allows it. Create rules that allow just the ports the application needs from the sources that should reach it, and allow the platform’s probe address as well. Deny everything else.

Limit exposure

Prefer internal load balancers for any tier that outsiders do not need to reach, and keep backend servers on private addresses. Avoid exposing management ports such as remote desktop or secure shell to the whole internet. Use a private path, such as a VPN or a managed bastion service, for administration.

Protection against floods

Attackers sometimes try to overwhelm a service with huge amounts of junk traffic, called a denial of service attack. Azure offers DDoS protection for public addresses, with a basic level on by default for the platform and a higher, paid level that adds tuning and support. Review the options in the documentation and choose the level that matches the risk to your business.

Encryption

Because the Layer 4 load balancer passes connections through without opening them, encryption between the user and your server is unaffected. Traffic stays encrypted all the way, and your servers hold the certificates. This is good for privacy, but it means the load balancer cannot inspect traffic for attacks or sort it by web address. For that, use a service that works at Layer 7.

Access control for administrators

Use Azure’s role-based access control, which gives each person only the permissions they need, to limit who can change or delete load balancers and their rules. A single wrong change can disconnect a whole application, so changes deserve review. Use resource locks on critical load balancers, and keep activity logs so you can see who changed what.

Security checklist

• Use the Standard edition and keep inbound closed until a rule opens it.
• Write tight NSG rules that allow only the needed ports and sources.
• Allow the probe source or the pool will look dead.
• Use internal load balancers for internal tiers, with servers on private addresses.
• Do not expose administration ports to the internet.
• Use DDoS protection at a level that fits your risk.
• Control who can change the configuration, and lock the critical resources.
• Add a Layer 7 service with a web application firewall when you need to inspect web traffic.

You cannot manage what you cannot see. Here is what to watch.

Monitoring means continuously checking the health and behaviour of your system. Metrics are numbers measured over time. Logs are written records of events. Azure Monitor collects metrics from the load balancer, and you can set alerts, which are automatic messages sent when a number crosses a line you choose.

Probe status is the heartbeat

The single most useful metric is the number of healthy servers. When it falls, you have lost capacity, and users may be affected soon. Set an alert that tells you when the pool drops below the number needed to carry the load, not just when it reaches zero.

Diagnostic tools

Azure provides visual views of the load balancer’s topology and health, called insights, which show the connected resources and where things have gone wrong. There are also tools to check whether traffic from one point can reach another, and logs of the rules that allowed or blocked traffic at the network security group. Together they help you answer the common question: “Is it the load balancer, the NSG, or the server?”

Troubleshooting step by step

Azure offers several traffic services. Compare before you choose.

The capabilities of these services evolve, so confirm current features and limits in the documentation before you design around any of them.

A simple decision guide

flowchart TD
    Q1{"Is the traffic web HTTP or HTTPS?"} -->|"Yes"| Q2{"Need routing by page address or a web firewall?"}
    Q1 -->|"No"| LB["Use Azure Load Balancer"]
    Q2 -->|"Yes"| Q3{"Users in many parts of the world?"}
    Q2 -->|"No"| LB2["Azure Load Balancer may be enough"]
    Q3 -->|"Yes"| FD["Consider Azure Front Door"]
    Q3 -->|"No"| AG["Use Application Gateway"]

Layering the services

Real systems often combine them. A global service may direct users to the nearest region. Within the region, a Layer 7 gateway may inspect and route web requests. Behind it, an internal Layer 4 load balancer may spread traffic across a tier of application servers or a pool of appliances. Each service does the job it is best at, and the combination gives speed, protection, and resilience.

When Layer 4 is the right level

Choose the Layer 4 load balancer when your traffic is not web traffic, when you want the lowest delay, when you need to keep end-to-end encryption untouched, when you balance traffic inside your network between tiers, or when you need HA ports for appliances. Choose a Layer 7 service when you need decisions based on the content of web requests.

Every design choice gives something and takes something. Be honest about both sides.

The central trade-off

The big trade-off is speed and simplicity versus intelligence. A Layer 4 load balancer is fast and simple because it knows little about your traffic. A Layer 7 service knows a lot, and can make clever decisions, but it adds processing, cost, and complexity. A good architect uses the simple tool where it is enough, and adds the clever one where it is truly needed.

Statistical fairness versus exact fairness

Hash-based distribution gives an even spread over many connections, but not an exact one. Over a short time, one server might get slightly more than another. For most workloads the difference is small, and the saving in complexity is worth it.

Stickiness versus balance

Session persistence keeps users on the same server, which helps applications that remember state, but may unbalance the load and complicates scaling. Storing state outside the servers is usually the better route, because it frees the load balancer to spread work evenly.

Proven shapes to copy, and common shapes to avoid.

Patterns that work

Anti-patterns

An anti-pattern is a common solution that looks sensible but causes trouble. Here are the usual ones.

A practical list you can print and keep next to your desk.

Best practices

• Use the Standard edition for all new work, and check the current documentation for editions and limits.
• Run at least two servers, spread over availability zones, and use zone-redundant frontends.
• Keep servers identical, so that even hashing produces an even load.
• Design honest, light health probes and set sensible intervals and thresholds.
• Allow the probe source through every security layer.
• Prefer private backends. Keep servers on private addresses and use internal load balancers between tiers.
• Keep servers stateless, storing sessions in a shared store.
• Handle idle timeouts. Use keepalives and retry logic in applications, and enable resets on idle where it helps.
• Plan outbound traffic with a NAT Gateway for busy workloads.
• Monitor probe status, availability, and SNAT usage, and alert on loss of capacity.
• Test failure on purpose, including stopping a server and losing a zone in a test environment.
• Control changes. Use role-based access and locks, and review configuration changes carefully.
• Automate. Describe load balancers in an infrastructure-as-code tool, which means keeping your setup in text files so it can be repeated and reviewed.

Common mistakes

Four typical situations, described as illustrative examples, showing when the service fits.

The stories below are illustrative composites of the kinds of situations where teams commonly use Azure Load Balancer. They are not claims about any particular company, but they reflect the reasoning real architects use.

Short answers to the questions beginners ask most often.

Everything important, in one place.

Azure Load Balancer is a fast, managed Layer 4 service that spreads TCP and UDP connections across a pool of healthy servers behind one shared address. It uses a hash of each connection’s details to choose a server, checks the health of every server with regular probes, and avoids those that fail. It can face the internet or stay private, can survive the loss of a zone when designed that way, and can also manage how servers reach the internet. It does not read web content, does not decrypt traffic, and does not fix a poorly built application behind it.

Remember the comparison we began with: a staff member at the supermarket entrance pointing shoppers to counters with short lines and closing counters whose cashiers have gone. That helper is valuable only if there are enough counters, if each is staffed by a capable cashier, and if the signs honestly show which ones are open. Treat Azure Load Balancer the same way: run several identical servers, give them honest health checks, plan how traffic leaves as well as how it arrives, and test what happens when something breaks.