Azure Load Balancer is a core networking component in Microsoft Azure that distributes incoming traffic across multiple virtual machines to ensure high availability and scalability. This chapter covers the fundamentals of Azure Load Balancer, including its types (public and internal), SKUs (Basic and Standard), configuration components, and operational behavior. For the AZ-104 exam, load balancing topics typically appear in 5-10% of questions, often integrated with other networking and high-availability scenarios. Mastering this chapter will help you design resilient applications and confidently answer exam questions on traffic distribution, health probes, and session persistence.
Jump to a section
Think of Azure Load Balancer as a hotel concierge desk with a single public phone number. The hotel has 100 guest rooms (VMs) in a building, each with an internal room phone extension (private IP). When a guest wants to order room service, they call the front desk number (frontend IP and port). The concierge (load balancer) has a list of available waitstaff (backend pool members) and uses a rule (load balancing rule) to decide which waiter to assign—for example, always send to the waiter who has taken the fewest calls (distribution algorithm). The concierge also notes which guest called and which waiter took the order (session persistence via source IP affinity) so that if the guest calls back about the same order, they get the same waiter. If a waiter goes on break (backend VM becomes unhealthy), the concierge stops sending calls to that waiter until they return (health probe). The concierge never enters the guest rooms; they just manage the calls. Similarly, Azure Load Balancer operates at Layer 4 (TCP/UDP) and does not inspect the content of the traffic. The hotel also has a separate service for international calls (outbound SNAT) where the concierge uses a pool of public numbers (frontend IPs) to make outbound calls on behalf of guests, mapping each guest's internal extension to a temporary public number.
What is Azure Load Balancer?
Azure Load Balancer is a Layer 4 (TCP/UDP) load balancer that distributes incoming traffic among healthy virtual machine instances in a backend pool. It operates at the transport layer, meaning it does not inspect or modify application-layer data. The load balancer uses a hash-based distribution algorithm to map traffic to backend servers. It supports both inbound and outbound scenarios, including outbound SNAT (Source Network Address Translation) for VMs without public IPs.
Why does it exist?
In a cloud environment, individual VMs can fail, become overloaded, or require maintenance. A load balancer provides: - High availability: Distributes traffic across multiple VMs; if one fails, traffic is redirected to healthy ones. - Scalability: Allows adding or removing VMs without disrupting service. - Outbound connectivity: Enables VMs in private subnets to access the internet via SNAT.
How it works internally – Step through the mechanism
Frontend IP configuration: The load balancer has one or more frontend IP addresses (public or private) that clients connect to.
Backend pool: A collection of VMs (or instances in a Virtual Machine Scale Set) that receive the traffic.
Load balancing rules: Map a frontend IP and port to a backend pool and port. For example, map TCP 80 on the frontend to TCP 80 on backend VMs.
Health probes: Determine which backend VMs are healthy. Probes are sent to a specified protocol (TCP, HTTP, or HTTPS) and port. If a probe fails (no response within timeout), the VM is removed from the rotation.
Distribution algorithm: By default, Azure Load Balancer uses a 5-tuple hash (Source IP, Source Port, Destination IP, Destination Port, Protocol) to map traffic to a backend instance. For session persistence, you can use 2-tuple (Source IP, Destination IP) or 3-tuple (Source IP, Destination IP, Protocol) hashing.
Key Components, Values, Defaults, and Timers
- SKU: Basic vs. Standard. Standard is recommended for production and is required for Availability Zones. - Frontend IP: Can be public (for internet-facing) or private (internal). Standard SKU supports multiple frontends. - Backend pool: Can contain VMs, VMSS, or IP addresses (Standard SKU). Basic SKU only supports VMs in a single availability set or scale set. - Health probe: - Protocol: TCP, HTTP, or HTTPS. - Port: Must match the backend port or a custom port. - Interval: Default 5 seconds, configurable. - Unhealthy threshold: Default 2 consecutive failures. - Timeout: Default 31 seconds (probe must respond within this time). - Load balancing rule: - Protocol: All (TCP+UDP), TCP, or UDP. - Session persistence: None (default), Client IP (2-tuple), or Client IP and Protocol (3-tuple). - Idle timeout: Default 4 minutes for public load balancer, configurable up to 30 minutes. - Floating IP: Direct Server Return (DSR) – when enabled, backend VM responds directly to client, not via load balancer. Default is disabled. - Outbound rules: For SNAT, Standard SKU provides outbound connectivity via the frontend IPs. Basic SKU uses default outbound access.
Configuration and Verification Commands
Using Azure CLI:
Create a public load balancer (Standard SKU):
az network lb create --resource-group myRG --name myLB --sku Standard --public-ip-address myPublicIP --frontend-ip-name myFrontend --backend-pool-name myBackendPoolCreate a health probe:
az network lb probe create --resource-group myRG --lb-name myLB --name myHealthProbe --protocol tcp --port 80 --interval 5 --threshold 2Create a load balancing rule:
az network lb rule create --resource-group myRG --lb-name myLB --name myHTTPRule --protocol tcp --frontend-port 80 --backend-port 80 --frontend-ip-name myFrontend --backend-pool-name myBackendPool --probe-name myHealthProbeVerify:
az network lb show --resource-group myRG --name myLB --output tableInteraction with Related Technologies
Virtual Machine Scale Sets: Load balancer integrates natively; you can assign a load balancer to a scale set.
Availability Sets: Basic SKU requires VMs in the same availability set or scale set. Standard SKU can span across availability zones.
Azure Firewall / NSG: Network Security Groups (NSGs) can be applied to the backend VM subnet to filter traffic. For public load balancer, you must allow health probe traffic from the AzureLoadBalancer service tag.
Azure Application Gateway: Unlike Load Balancer (Layer 4), Application Gateway is Layer 7 (HTTP/HTTPS) and can do SSL termination, URL-based routing, and WAF.
Traffic Manager: DNS-level load balancing, used for global traffic distribution across regions.
Default Values and Limits
Maximum backend pool instances: Basic: 100 VMs per pool. Standard: 1000 instances.
Maximum load balancing rules: Basic: 150 rules. Standard: 1500 rules.
Health probe interval: Minimum 5 seconds.
Idle timeout: 4-30 minutes for public LB; not applicable for internal LB (no idle timeout).
Outbound SNAT ports: Standard SKU provides 64,000 ports per frontend IP, shared across all backend VMs.
Trap Patterns on the Exam
Basic vs. Standard SKU: Candidates often confuse the features. Standard is zone-redundant, supports multiple frontends, and is required for cross-region load balancing (via Global Load Balancer). Basic does not support availability zones.
Health probe port vs. application port: The probe port can be different from the application port; it just needs to be a port where the VM responds.
Session persistence modes: 'Client IP' means 2-tuple (source IP + destination IP); 'Client IP and Protocol' means 3-tuple. The default is 'None' (5-tuple).
Floating IP (DSR): When enabled, the backend VM must have the frontend IP configured on its loopback interface. This is rarely used and often misunderstood.
Outbound rules: In Standard SKU, outbound connectivity is not automatic; you must configure outbound rules or use NAT gateway. Basic SKU provides default outbound access.
Summary of Key Exam Concepts
Azure Load Balancer operates at Layer 4.
Two SKUs: Basic (no zones, limited features) and Standard (zones, multiple frontends, higher limits).
Distribution based on 5-tuple hash by default.
Health probes: TCP, HTTP, HTTPS; interval and unhealthy threshold configurable.
Session persistence: None, Client IP, Client IP and Protocol.
Floating IP (DSR) is a special mode for specific scenarios.
For outbound connectivity, use outbound rules (Standard) or default outbound (Basic).
Client sends request to frontend
A client (e.g., web browser) sends a TCP SYN packet to the public IP address of the load balancer on port 80. The packet arrives at the Azure network fabric, which routes it to the load balancer's frontend IP configuration. The load balancer inspects the 5-tuple of the packet: source IP (client), source port (ephemeral), destination IP (frontend), destination port (80), and protocol (TCP). This packet is the first in a new flow.
Load balancer selects a backend VM
The load balancer uses the 5-tuple hash algorithm to compute a hash value. It then maps this hash to one of the backend VMs in the pool. The mapping is consistent for the same 5-tuple, ensuring all packets of the same flow go to the same VM. The load balancer checks the health probe status of the selected VM; if the VM is unhealthy, it selects another VM (the hash maps to the next available healthy VM).
Load balancer translates destination to backend
The load balancer performs Destination Network Address Translation (DNAT). It rewrites the destination IP address from the frontend IP to the private IP of the selected backend VM, and the destination port to the backend port (if different). The source IP and port remain unchanged. The load balancer also creates a flow entry in its internal state table so that return traffic can be reverse-NATed correctly.
Load balancer forwards packet to backend VM
The modified packet is forwarded over the Azure virtual network to the backend VM's private IP. The backend VM receives the packet as if it were destined directly to it. The VM's network stack processes the packet and generates a response (e.g., TCP SYN-ACK). The response packet has source IP = backend VM's private IP, destination IP = client IP.
Return traffic goes through load balancer
The response packet from the backend VM is sent to the default gateway (the load balancer). The load balancer looks up the flow entry created earlier, performs Source NAT (SNAT) to replace the source IP with the frontend IP, and forwards the packet to the client. The client sees the response as coming from the frontend IP. This process continues for all subsequent packets in the same TCP connection.
Enterprise Scenario 1: High-Availability Web Application
A financial services company runs a customer-facing web application on a set of VMs in Azure. They deploy two VMs in an availability set (Basic SKU) behind a public Azure Load Balancer. The load balancer distributes HTTPS traffic (TCP 443) across the VMs. A health probe checks TCP 443 every 5 seconds; if a VM fails to respond twice consecutively, it is removed from the backend pool. The company also enables session persistence (Client IP) to ensure that a user's session sticks to the same VM for the duration of their interaction. In production, they handle 10,000 concurrent users with 4 VMs. The load balancer's idle timeout is set to 10 minutes to accommodate long-running API calls. A common issue is that when a VM is patched, the health probe fails, and traffic is seamlessly redirected to the remaining VMs. Misconfiguration often occurs when the health probe port does not match the application port, causing false unhealthy status. Another pitfall is forgetting to allow the AzureLoadBalancer service tag in the NSG, which blocks health probes and causes all VMs to be marked unhealthy.
Enterprise Scenario 2: Internal Load Balancer for Multi-Tier Application
A retail company has a three-tier application with web, application, and database tiers. The application tier runs on VMs in a private subnet and needs to be load-balanced for internal traffic from the web tier. They deploy an internal Standard Load Balancer with a private frontend IP. The backend pool contains application VMs spread across two availability zones for zone redundancy. The load balancer uses a TCP health probe on port 8080 (the application port). The web tier is configured to send requests to the internal load balancer's private IP. This setup ensures that if one application VM fails or a zone goes down, the web tier continues to function. A common scaling consideration is that the Standard Load Balancer supports up to 1000 backend instances, but the company only uses 10. They also configure outbound rules so that the application VMs can access a third-party API via the load balancer's frontend IP. Misconfiguration: if the web tier's NSG does not allow traffic to the internal load balancer's frontend IP, requests fail. Also, the backend VMs must have the load balancer's private IP as their default gateway for return traffic to work correctly.
Enterprise Scenario 3: Outbound SNAT for VMs without Public IPs
A software development company runs hundreds of VMs in a virtual network that must not have public IPs for security reasons. They deploy a Standard Load Balancer with a public frontend IP and configure an outbound rule to provide SNAT for all VMs in the backend pool. The outbound rule maps all outbound traffic to the frontend IP, using port address translation (PAT) to share the public IP among many VMs. The company monitors the SNAT port usage because each VM can use up to 64,000 ports per frontend IP; if they run out, outbound connections fail. They add a second frontend IP to increase port capacity. A common mistake is not configuring outbound rules at all, expecting that Standard Load Balancer provides default outbound access (it does not). Another issue is that when VMs make many short-lived connections, SNAT port exhaustion can occur quickly, requiring tuning of the idle timeout or adding more frontend IPs.
Exactly what AZ-104 tests on this topic
AZ-104 objective 4.2 covers "Configure and manage Azure Load Balancer." The exam expects you to:
Choose the appropriate SKU (Basic vs. Standard) based on requirements.
Configure frontend IP, backend pool, health probes, and load balancing rules.
Understand session persistence modes and when to use each.
Implement outbound connectivity via outbound rules or NAT gateway.
Troubleshoot common issues like health probe failures and SNAT port exhaustion.
Common wrong answers and why candidates choose them
Choosing Basic SKU for a zone-redundant deployment: Candidates think Basic is cheaper and sufficient, but Basic does not support availability zones. The exam will present a scenario requiring zone redundancy, and the correct answer is Standard SKU.
Setting health probe interval to 1 second: The minimum is 5 seconds. Candidates might think faster probes are better, but they are not allowed.
Enabling Floating IP (DSR) without configuring the backend VM: Floating IP requires the backend VM to have the frontend IP on its loopback. Candidates enable it without understanding the prerequisite, causing connectivity issues.
Assuming Standard Load Balancer provides default outbound access: Standard SKU does not; you must explicitly configure outbound rules or use NAT gateway. Basic SKU does provide default outbound access.
Confusing load balancer with Application Gateway: The exam may present a scenario requiring SSL termination or URL-based routing; candidates might choose Load Balancer instead of Application Gateway.
Specific numbers, values, and terms that appear verbatim on the exam
SKU: Basic, Standard.
Health probe interval: 5 seconds (default), can be increased.
Unhealthy threshold: 2 consecutive failures (default).
Idle timeout: 4 minutes (default for public LB), configurable up to 30 minutes.
Session persistence: None, Client IP, Client IP and Protocol.
Distribution algorithm: 5-tuple hash (source IP, source port, destination IP, destination port, protocol).
Backend pool limits: Basic 100, Standard 1000.
Floating IP: Direct Server Return (DSR).
Outbound SNAT ports: 64,000 per frontend IP for Standard SKU.
Edge cases and exceptions the exam loves to test
Health probe on a different port: The probe can use a different port than the application. For example, probe on TCP 80 while application runs on 443. This is valid.
Multiple frontends: Standard SKU supports multiple frontend IPs (public and private) on the same load balancer.
Cross-region load balancing: Azure Cross-Region Load Balancer (Preview) is a separate SKU; not in scope for AZ-104 but may appear as a distractor.
Backend pool with IP addresses: Standard SKU allows adding VMs by IP address, not just by resource ID. Useful for hybrid scenarios.
How to eliminate wrong answers using the underlying mechanism
If a question mentions "zone redundancy," eliminate Basic SKU.
If a question mentions "SSL termination" or "URL path routing," eliminate Load Balancer (use Application Gateway instead).
If a question mentions "outbound connectivity without public IPs on VMs," look for outbound rules or NAT gateway; if the load balancer is Standard, default outbound is not sufficient.
If a question mentions "sticky sessions" without further details, session persistence (Client IP) is the correct feature.
If a question mentions "health probe fails," check if the NSG allows traffic from AzureLoadBalancer service tag; also check if the probe port is open on the VM.
Azure Load Balancer operates at Layer 4 (TCP/UDP) and uses a 5-tuple hash for traffic distribution.
Standard SKU is required for Availability Zones, multiple frontends, and higher backend pool limits (1000 vs 100).
Health probe interval minimum is 5 seconds; unhealthy threshold default is 2 consecutive failures.
Session persistence modes: None (5-tuple), Client IP (2-tuple), Client IP and Protocol (3-tuple).
Floating IP (DSR) enables the backend VM to respond directly to the client; requires loopback configuration on the VM.
Standard Load Balancer does not provide default outbound access; use outbound rules or NAT gateway.
NSG must allow traffic from the AzureLoadBalancer service tag for health probes to work.
Idle timeout for public load balancer defaults to 4 minutes, configurable up to 30 minutes.
These come up on the exam all the time. Here's how to tell them apart.
Azure Load Balancer (Basic SKU)
Free tier; included with VMs.
No support for Availability Zones.
Backend pool limited to 100 VMs.
Default outbound access via SNAT.
Single frontend IP only.
Azure Load Balancer (Standard SKU)
Paid service; per-rule or per-hour pricing.
Supports Availability Zones (zone-redundant and zonal).
Backend pool up to 1000 VMs.
No default outbound access; must configure outbound rules.
Supports multiple frontend IPs (public and private).
Mistake
Azure Load Balancer can do SSL termination.
Correct
Azure Load Balancer operates at Layer 4 (TCP/UDP) and does not inspect or terminate SSL. For SSL termination, use Azure Application Gateway or a reverse proxy like NGINX on the backend VM.
Mistake
Basic SKU supports Availability Zones.
Correct
Basic SKU does not support Availability Zones. Only Standard SKU supports zone-redundant and zonal deployments.
Mistake
Standard Load Balancer provides outbound internet access by default.
Correct
Standard Load Balancer does not provide default outbound access. You must configure outbound rules or use a NAT gateway. Basic Load Balancer does provide default outbound access via SNAT.
Mistake
Health probe must use the same port as the application.
Correct
Health probes can use any port; they do not have to match the application port. They just need to be a port where the VM responds (e.g., a management port).
Mistake
Floating IP (DSR) is required for all load balancing scenarios.
Correct
Floating IP is a special mode for specific use cases (e.g., when the backend VM must see the client IP). It is not recommended for typical web applications because it requires additional configuration on the backend VM.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Basic SKU is free and provides basic load balancing but lacks support for Availability Zones, multiple frontends, and higher backend pool limits (max 100 VMs). It also provides default outbound SNAT. Standard SKU is paid, supports Availability Zones, multiple frontends, and up to 1000 backend VMs. However, outbound connectivity must be explicitly configured. For production and high-availability scenarios, Standard SKU is recommended.
Session persistence (also called sticky sessions) ensures that all packets from a client session go to the same backend VM. By default, no persistence is used (5-tuple hash). Options include Client IP (2-tuple: source IP + destination IP) and Client IP and Protocol (3-tuple: source IP + destination IP + protocol). Note that if a client's IP changes (e.g., due to NAT), the session may be redirected.
Common causes: (1) The NSG on the backend VM subnet blocks traffic from the AzureLoadBalancer service tag. (2) The health probe port is not open on the VM (firewall or application not listening). (3) The probe is using HTTP/HTTPS but the endpoint does not return 200 OK. (4) The VM is not responding due to high CPU or network issues. Check the NSG rules and ensure the VM is healthy.
Floating IP (also known as Direct Server Return, DSR) is a configuration where the backend VM responds directly to the client, bypassing the load balancer for return traffic. This requires the backend VM to have the frontend IP configured on its loopback interface. It is used for scenarios like SQL Server Always On Availability Groups. It is disabled by default.
You must configure an outbound rule on the load balancer or use a NAT gateway. Outbound rules define which frontend IP(s) to use for SNAT and which backend pool VMs get outbound connectivity. Alternatively, you can assign each VM a public IP, but that is less scalable. Without explicit configuration, Standard Load Balancer does not provide outbound access.
Yes, Azure Load Balancer integrates natively with Virtual Machine Scale Sets (VMSS). You can specify a load balancer during scale set creation or attach it later. The load balancer automatically distributes traffic to all instances in the scale set. For Standard SKU, the backend pool can be the scale set's IP configuration.
For a public load balancer, the default idle timeout is 4 minutes. You can configure it between 4 and 30 minutes using the 'idle-timeout' parameter. For internal load balancers, there is no idle timeout because the connection is within the virtual network. Adjust the timeout for long-lived connections like database or API calls.
You've just covered Azure Load Balancer — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?