Skip to main content
This guide walks through deploying and configuring an Azure Load Balancer using the Azure portal. It explains the required decisions and configuration steps—frontend, backend pools, load-balancing rules, health probes, NAT rules, and outbound connectivity—then demonstrates a portal-based example using a Standard Load Balancer across availability zones.
Before you begin: ensure you have an Azure subscription, a resource group, and one or more Virtual Machines (VMs) deployed in the same virtual network (or in the zones/regions you plan to cover). If you need cross-region routing, consider Azure Front Door or Traffic Manager for global scenarios.
Overview: high-level deployment steps
  • Choose subscription, resource group, name, region, SKU, type (public/internal), and tier (regional/global).
  • Configure frontend IP configuration (public or private).
  • Create backend pool(s) and add VM NICs or IP addresses.
  • Create health probe(s).
  • Create load balancing rule(s) that map frontend IP/port to backend pool/port.
  • Optionally create inbound NAT rules for VM management and outbound rules (or use NAT gateway) for internet egress.
Start by selecting your Azure subscription and resource group, and provide a unique name for the load balancer instance.
The image is a screenshot of a form in the Azure Portal for creating a load balancer, showing fields for subscription, resource group, name, region, SKU, type, and tier. A highlighted note emphasizes providing a unique name for the load balancer instance.
Choose region and SKU (Basic, Standard, or Gateway Load Balancer) based on scale, features, and support requirements. Then pick the type:
  • Internet-facing (public) — public front end to serve internet traffic.
  • Internal — private load balancing inside a virtual network.
Finally, choose a tier: regional (single region) or global (cross-region). Backend pools A backend pool contains the VM NICs or IP addresses that will receive load-balanced traffic. Configure it with:
  • A descriptive name.
  • The virtual network containing the backend resources.
  • The configuration type:
    • NIC — add VM network interfaces (recommended for managed VMs).
    • IP address — for static or external endpoints.
The image illustrates the concept of creating backend pools, showing a cloud load balancer distributing traffic to a group of virtual machines (VMs) with various IP addresses. It explains that backend pools contain IPs of VMs to direct traffic from the load balancer.
When defining a backend pool:
  • Name the pool clearly for easier management.
  • Associate the pool with the correct virtual network/subnet.
  • Select the IP configurations or NICs to include.
The image provides instructions and options for configuring backend pools, including naming the pool, choosing a virtual network, and selecting a configuration type (NIC or IP address). A configuration panel shows fields for inputting these settings.
SKU comparison — quick reference
The image describes two types of SKUs for creating backend pools: Basic SKU, which supports VMs in a single availability set or VM scale set, and Standard SKU, supporting VMs in a virtual network with a mix of VMs, availability sets, and scale sets.
Load balancing rules A load balancing rule maps a frontend IP and port to a backend pool and backend port—this is the bridge between the frontend and backend instances.
The image shows a user interface for creating load balancer rules, with a section for adding specific rule details such as IP version, protocol, and ports. On the left, there are buttons for "Rule Mapping," "NAT Rule Integration," and "NAT Rule Behavior."
Key fields for a load balancing rule:
  • Rule name
  • Frontend IP configuration
  • Frontend port → Backend port
  • Protocol (TCP/UDP)
  • Backend pool association
  • Health probe
  • Session persistence (sticky sessions)
  • Idle timeout
  • Floating IP (Direct Server Return, if required)
Session persistence (affinity) Session persistence controls whether requests from the same client are consistently routed to the same backend instance. By default, Azure Load Balancer distributes using a five-tuple hash: source IP, source port, destination IP, destination port, and protocol. Options:
  • None — five-tuple hash, no persistence.
  • Client IP — two-tuple (client IP + destination IP).
  • Client IP and protocol — three-tuple (client IP + destination IP + protocol).
Use persistence for stateful applications (shopping carts, session-specific services).
The image illustrates "Configuring Session Persistence" options, detailing how client connections pass through the internet to a load balancer, which directs traffic to different virtual machines.
Health probes Health probes determine whether backend instances are healthy and eligible for traffic. Probe types and configuration options: Probe parameters include protocol, port, path (for HTTP/HTTPS), probe interval (seconds), and unhealthy threshold (consecutive failures). Associate the probe with the load balancing rule so traffic is only forwarded to healthy instances.
The image is a slide titled "Creating Health Probes – Association," showing a form for adding a health probe with fields like name, protocol, port, path, and interval. There's also a description explaining how probes are linked to load balancer rules to manage traffic based on backend status.
Outbound connectivity (Standard Load Balancer)
  • Standard SKU has no default outbound SNAT to the internet. You must create an outbound rule or attach a NAT gateway for backend VMs to reach the internet.
  • When an outbound rule is present, backend VM IPs are SNATed to the load balancer public IP.
  • A single outbound rule can apply to multiple backend pools.
A common limitation is SNAT port exhaustion: each public IP has a finite number of ephemeral ports. For workloads requiring a very large number of concurrent outbound connections, prefer a NAT gateway (assigned to the subnet) because it offers higher, scalable SNAT port capacity.
If you expect a large number of concurrent outbound connections, use a NAT gateway (associated to the VM subnet). NAT gateway provides scalable SNAT port allocation and avoids port exhaustion.
The image explains how to configure outbound traffic using a standard load balancer, detailing the default behavior, outbound rule requirements, frontend association, SNAT translation, and outbound port allocation, accompanied by a diagram of pools with VMs and timeout settings for outbound rules.
Portal walkthrough: create a Standard Load Balancer (example) In this example we deploy a Standard Load Balancer in East US 2 across three availability zones for zone redundancy. Begin by verifying the VMs you will add to the backend pool.
The image shows a Microsoft Azure portal interface displaying a list of virtual machines. Each entry includes information such as name, subscription, resource group, location, status, operating system, size, and disk count.
Create the load balancer:
  • SKU: Standard (general purpose; use Gateway LB only for NVAs/firewalls).
  • Subscription and resource group: choose appropriate ones.
  • Name: e.g., AZ-700-Web-LB.
  • Region: East US 2.
The image shows a Microsoft Azure interface for creating a load balancer, including fields for project and instance details such as subscription, resource group, name, region, SKU, type, and tier.
Note: Basic SKU may not be available in some subscriptions or regions; consult the current Azure documentation for SKU availability. Frontend configuration (example)
  • Type: Public (internet-facing) for this demo.
  • Frontend name: AZ-700-LB-FE
  • IP version: IPv4
  • Public IP: create AZ-700-LB-PIP (optionally zone-redundant)
The image shows a Microsoft Azure page where a frontend IP configuration for a load balancer is being set. There are options to select the IP version, type, and a section to add a public IP address.
Backend pool (example)
  • Add a backend pool and select the virtual network where your VMs reside.
  • Select VM NICs (IP configurations) that should receive traffic and save.
The image shows a Microsoft Azure interface for adding IP configurations to a backend pool, with a table listing virtual machines and their details such as resource group and IP address.
You can skip inbound NAT and outbound rules during initial deployment and add them later. Review + create to deploy the load balancer. After deployment, inspect the load balancer blade to verify frontend IP configuration, backend pools, health probes, load balancing rules, and NAT rules.
The image shows a user interface of a load balancer setup on a cloud platform, with options for configuration and management, including resource group, location, and subscription details.
Create a load balancing rule (example) To load balance web traffic on port 80:
  • Name: AZ-700-web-rule
  • IP version: IPv4
  • Frontend IP: AZ-700-LB-FE
  • Backend pool: AZ700LBBE
  • Protocol: TCP
  • Frontend port: 80 → Backend port: 80
  • Health probe: create an HTTP probe (path /, interval 5s)
  • Session persistence: None (adjust if needed)
  • Idle timeout & floating IP: defaults unless required otherwise
The image shows a Microsoft Azure interface for adding a load balancing rule, with options for IP version, frontend IP address, backend pool, protocol, port, health probe, session persistence, and idle timeout settings.
Save the rule. You should now be able to browse to the load balancer front-end public IP and receive responses from one of the backend VMs (responses may alternate based on hashing and session persistence settings). Find the public frontend IP via the Load Balancers list, copy it, and open it in a browser.
The image shows a Microsoft Azure portal page displaying a list of load balancers under "Load balancing and content delivery," with details such as name, SKU, resource group, location, and subscription.
The frontend IP shown is the public address clients use to reach your service.
The image shows a configuration screen for a load balancer, displaying the frontend IP address 20.12.96.233 associated with the name az700-lb-fe.
If you refresh the browser you may see responses from different backend VMs (for example AZ3, AZ2) depending on the hashing algorithm and client source/port behavior. Inbound NAT rules Use inbound NAT rules when you need direct access to a specific VM on a specific port through the load balancer public IP. Azure recommends the newer V2 NAT format to avoid future migrations.
The image shows the Microsoft Azure portal with a "Load balancing rules" page open for a load balancer named "az700-web-lb," displaying a rule with TCP/80 protocol linked to a backend pool and health probe.
Example NAT rule to reach a VM’s SSH port:
  • Name: AZ-700-LB-NAT-VM1
  • Target VM: select VM in zone 1
  • Frontend IP: AZ-700-LB-FE
  • Frontend port: 9090 (public)
  • Backend port: 22 (SSH on VM)
  • Protocol: TCP
This image shows a Microsoft Azure interface for adding an inbound NAT rule, including options to specify the rule's name, type, target virtual machine, and protocol. There is a warning about the retirement of Inbound NAT rule version 1 by September 30, 2027.
The image shows the "Add inbound NAT rule" setup page in Microsoft Azure, where various configuration options for adding a NAT rule are being displayed, including fields for name, type, target virtual machine, and protocol.
With that NAT rule in place, connecting to the load balancer public IP on port 9090 will forward to port 22 of the selected VM. From a terminal, SSH to the VM via the load balancer public IP and NAT port:
You will likely see a host authenticity prompt similar to:
Answer yes and provide your credentials to verify inbound NAT mapping to port 22. Testing outbound connectivity from a backend VM If a VM in the backend pool cannot reach the internet (typical with Standard SKU and no outbound rule/NAT gateway), test with:
If the request times out, create an outbound rule and associate it with the frontend IP and the backend pool, or attach a NAT gateway to the subnet for scalable outbound SNAT. After adding an outbound rule or NAT gateway, internet-bound requests (e.g., apt update or curl) should succeed. Summary
  • Load balancing rules map frontend IP/port to backend pool and port to distribute inbound traffic.
  • Health probes ensure only healthy backend instances receive traffic.
  • Inbound NAT rules map unique frontend ports to backend VM ports (useful for SSH/RDP or management).
  • Standard Load Balancer requires an outbound rule (or NAT gateway) for backend VMs to access the internet; NAT gateway is recommended for high-scale outbound needs to avoid SNAT port exhaustion.
Further reading and references This completes the Azure Load Balancer deployment and configuration walkthrough.

Watch Video