Configure Internal and Public Azure Load Balancers (2026)

Azure Load Balancer is actually a stateless, Layer 4 (TCP/UDP) load balancer that distributes traffic across multiple healthy VMs or services.

Here’s a breakdown of how to configure both internal and public Azure Load Balancers, with a focus on understanding their behavior and common pitfalls.

Public Azure Load Balancer

A public load balancer has a public IP address and distributes incoming internet traffic to your backend pool of VMs.

Scenario: You have a web application running on multiple VMs behind a public load balancer.

Configuration Steps:

1. Create the Load Balancer:

   • Go to the Azure portal, search for "Load balancers," and click "Create."
   • SKU: Standard is recommended for production; Basic has limitations.
   • Type: Public.
   • Name: my-public-lb
   • IP version: IPv4.
   • Frontend IP configuration:
     • Click "Add frontend IP configuration."
     • Name: my-frontend-ip
     • Public IP address: Click "Create new."
       • Name: my-public-frontend-pip
       • SKU: Standard
       • Assignment: Static
       • Click "OK."
     • Click "Add."
   • Backend pools:
     • Click "Add backend pool."
     • Name: my-web-backend-pool
     • Virtual machines: Select the NICs of the VMs you want to include.
     • Click "Add."
   • Health probes:
     • Click "Add health probe."
     • Name: my-http-probe
     • Protocol: HTTP
     • Port: 80
     • Path: /health (This is crucial; your application must expose a /health endpoint that returns a 200 OK status.)
     • Interval: 5 (seconds)
     • Unhealthy threshold: 2 (consecutive probes failing)
     • Click "Add."
   • Load balancing rules:
     • Click "Add load balancing rule."
     • Name: my-http-rule
     • IP Version: IPv4
     • Frontend IP address: my-frontend-ip
     • Protocol: TCP
     • Port: 80 (This is the port clients connect to.)
     • Target port: 80 (This is the port your backend VMs listen on.)
     • Backend pool: my-web-backend-pool
     • Health probe: my-http-probe
     • Session persistence: None (or Client IP, Client IP and protocol, depending on your app needs)
     • Floating IP (direct server return): Disabled (usually)
     • Click "Add."
   • Review and create the load balancer.

2. Configure Network Security Groups (NSGs):

   • Ensure the NSG associated with your backend VMs allows inbound traffic on the target port (e.g., port 80 for HTTP) from the Azure Load Balancer’s service tag (AzureLoadBalancer).
   • Example NSG rule:
     • Source: Service Tag
     • Source service tag: AzureLoadBalancer
     • Source port ranges: *
     • Destination: Any
     • Destination port ranges: 80
     • Protocol: TCP
     • Action: Allow
     • Priority: 100 (or a suitable number)

How it works: The public IP address is the entry point. When traffic arrives on port 80, the load balancer directs it to one of the healthy VMs in the my-web-backend-pool on port 80. The health probe continuously checks the /health endpoint on your VMs; if a VM fails two probes, it’s temporarily removed from the pool.

Internal Azure Load Balancer

An internal load balancer has a private IP address and distributes traffic from within your virtual network to your backend pool. This is common for multi-tier applications where the front-end web tier might be exposed publicly, but the back-end API or database tiers are only accessible internally.

Scenario: You have an API service running on VMs that should only be accessible from other VMs within the same VNet.

Configuration Steps:

1. Create the Load Balancer:

   • Follow the same steps as for the public load balancer, but with these key differences:
   • Type: Internal.
   • Frontend IP configuration:
     • Name: my-internal-frontend
     • Virtual network: Select your VNet.
     • Subnet: Select a subnet within your VNet.
     • IP assignment: Static (recommended for predictable access).
     • Private IP address: Assign a specific private IP (e.g., 10.0.1.10).
   • Backend pools: Similar to public LB, define your backend VMs.
   • Health probes: Similar to public LB, define your probe.
   • Load balancing rules:
     • Name: my-api-rule
     • Frontend IP address: my-internal-frontend
     • Protocol: TCP
     • Port: 5000 (Example API port)
     • Target port: 5000 (Port your API listens on)
     • Backend pool: my-api-backend-pool
     • Health probe: my-api-probe
     • Session persistence: None or Client IP.

2. Configure Network Security Groups (NSGs):

   • Ensure NSGs on backend VMs allow inbound traffic on the target port (e.g., 5000) from the subnet where the internal load balancer’s frontend IP resides, or from specific VMs that need to access the service.
   • Example NSG rule:
     • Source: IP Addresses
     • Source IP addresses/CIDR ranges: 10.0.1.0/24 (The subnet of your internal LB frontend)
     • Source port ranges: *
     • Destination: Any
     • Destination port ranges: 5000
     • Protocol: TCP
     • Action: Allow
     • Priority: 110

How it works: Clients within the VNet (other VMs, services) will use the private IP address (10.0.1.10 in the example) to access the API. The internal load balancer intercepts this traffic and distributes it to healthy VMs in the my-api-backend-pool on port 5000.

Key Considerations & Common Pitfalls

• Health Probes are Paramount: A load balancer will only send traffic to VMs that are passing their health probes. If your application isn’t responding on the probe port/path, the load balancer won’t send traffic to it, even if the VM is otherwise healthy. Ensure your application exposes a reliable health check endpoint.
• NSG Rules: This is the most common mistake. VMs behind a load balancer still need NSG rules to allow traffic from the load balancer’s service tag (AzureLoadBalancer) or the LB’s frontend IP/subnet. If the NSG blocks the probe or the actual traffic, the LB will see the backend as unhealthy or unreachable.
• Port Mismatches: Double-check that the "Port" (frontend listener) and "Target Port" (backend VM listener) are correctly configured in the load balancing rule.
• Stateful vs. Stateless: Azure Load Balancer is stateless. It doesn’t store information about previous connections. If your application requires session affinity, use the "Session persistence" option (Client IP or Client IP and Protocol).
• Standard vs. Basic SKU: Standard Load Balancer offers more features, higher performance, and better availability guarantees. Basic Load Balancer has limitations on the number of rules, backend pool size, and probe intervals. For production, always use Standard.
• Floating IP (Direct Server Return): This is an advanced feature. When enabled, the destination IP address of the packet is not changed by the load balancer; the backend server sees the original client IP. This is useful for specific scenarios like running SQL Server Always On Availability Groups. For most web applications, keep it disabled.
• Internal LB and DNS: For internal load balancers, you’ll typically want to create a Private DNS Zone entry that maps a friendly name (e.g., my-api.internal.local) to the static private IP address of the internal load balancer’s frontend.

The next concept you’ll likely encounter is configuring Application Gateway for Layer 7 (HTTP/HTTPS) load balancing, which offers features like SSL termination, cookie-based session affinity, and URL-based routing.