Configure Load Balancers
Backend Pool and Load Balancing Rules
A backend pool is a group of virtual machines that receive traffic from the load balancer — it represents the servers handling the workload. Load balancers can identify VMs by their NIC or IP address, and the scope of a backend pool is any VM within a single virtual network.
A Load Balancing Rule defines how traffic is directed from the frontend — public or private IP address — to the backend pool: it specifies the protocol (TCP, UDP), port, frontend IP configuration, and which health probe to use.
How to Create a Backend Pool
The following steps walk through creating a backend pool, adding a VM to it, creating a load balancing rule, and configuring a health probe, all via the Azure portal.
Define a group to hold the virtual machine(s) that will handle traffic. Within the Azure portal, navigate to Load Balancer → Backend Pools → Add:
- Name:
pool1 - Virtual Network: [Your Virtual Network]
This step creates a logical grouping of VMs that will receive traffic from the load balancer. Associating the pool with a virtual network ensures that the VMs are reachable.
Associate a Virtual Machine to the Backend Pool. Add the existing VM to the newly created backend pool. Within the Backend Pool configuration, select Add a VM, then choose:
- Virtual Machine: [Your Virtual Machine]
This step links the VM to the backend pool, making it eligible to receive traffic from the load balancer. The VM's network interface is used for identification.
Create a Load Balancing Rule to define how traffic should be directed to the backend pool. Within the Azure portal, navigate to Load Balancer → Rules → Add:
- Name:
Rule1 - Frontend IP address: [Your Load Balancer's Frontend IP]
- Backend pool:
pool1 - Protocol:
TCP - Port:
80
This step defines the rule that governs how traffic is routed. Specifying TCP on port 80 configures the load balancer to forward HTTP traffic to the VMs in the backend pool.
Health Probes
Health probes are the mechanism the load balancer uses to monitor the health of the VMs in a backend pool. TCP probes verify basic port connectivity, while HTTP/HTTPS probes check for a valid response from a web server, giving a more accurate picture of application health than network reachability alone. Unhealthy VMs are automatically removed from the traffic rotation: you can define the unhealthy threshold for your probes, and once a probe fails to respond, the load balancer stops sending new connections to that instance — though a probe failure doesn't affect connections already in progress.
Configure a Health Probe to set up a mechanism that monitors the health of the VMs in the backend pool. Within the Azure portal, navigate to Load Balancer → Health Probes → Add:
- Name:
probe1 - Protocol:
TCP - Port:
80
This step creates a health probe that periodically checks if the VMs are responding on port 80. Unhealthy VMs are removed from the traffic rotation, ensuring high availability.
NAT Rules
An inbound NAT rule forwards traffic from a load balancer's frontend to one specific VM, based on port mapping — for example, giving you RDP or SSH access to a single backend VM through the load balancer's public IP, rather than distributing traffic across the entire pool. This is a separate mechanism from load balancing rules and isn't involved in ordinary pool-wide traffic distribution.
Alerts and Action Groups
Alerts and action groups provide a proactive monitoring and notification system, typically triggered by health probe failures or other critical events, so you find out about a degraded backend before your users do.
Common Issues and Troubleshooting
No backend pool or rules configured. A newly created load balancer has no backend servers or rules by default. That's expected right after creation, not a bug — just remember to configure a backend pool, a load balancing rule, and a health probe before expecting any traffic to flow through it.
Public IP address conflicts. If you're using a static public IP address, make sure it doesn't conflict with another resource already using that address in your Azure subscription.
VM not appearing in, or reachable via, the backend pool. Confirm the VM is actually running, and that it's in the same region and connected to the same virtual network as the load balancer — a region or VNet mismatch is the most common reason a VM won't show up as an eligible backend pool member.
No internet access for VMs behind the load balancer. By default, VMs behind a load balancer don't have outbound internet access. You'll need to configure outbound rules to allow traffic to flow from the VMs to the internet.
Traffic not reaching the backend. This tends to have one of three causes, worth checking in order: first, confirm DNS is correctly resolving to the load balancer's public IP, so external users can actually reach it; second, confirm the VM is a healthy, running member of the backend pool and is passing its health probe; third, check that the VM's own firewall isn't blocking traffic on the probe or application port.
Health probe failing. Review the probe's protocol, port, and interval settings, then check that the VM's operating system and application are actually listening on and responding to requests on that port. A probe failure doesn't necessarily mean the VM itself is unhealthy — just that it isn't answering as expected there. Firewall rules on the VM can also block probe traffic and produce the same symptom.
Unequal traffic distribution. Verify all servers in the backend pool are healthy and responding to traffic, and check whether a session persistence setting is directing all traffic to a single server rather than spreading it across the pool.
Incorrect traffic routing. Review your load balancing rules and NAT rules to make sure traffic is being directed to the correct backend pool, port, and — for NAT rules specifically — the correct individual VM.
Lack of proactive monitoring. Configure alerts and action groups based on health probe failures, so you're notified when a server becomes unhealthy rather than finding out from your users.