Networking Load balancing

Load Balancer

Azure Load Balancer distributes TCP and UDP traffic across backend virtual machines, virtual machine scale sets, or IP configurations. It uses frontend IPs, backend pools, health probes, and rules to provide low-latency Layer 4 traffic distribution for public or internal workloads.

Source: Microsoft Learn - Azure Load Balancer overview Reviewed 2026-06-02

Exam trap: Assuming Load Balancer can route by URL path or hostname when that requires Application Gateway or Front Door.
Production check: List backend pool members and confirm every expected VM or scale-set instance is attached.

Practice this topic Microsoft Learn

Article details and learning context

Aliases: Azure Load Balancer, Standard Load Balancer, internal load balancer, public load balancer, layer 4 load balancer
Difficulty: fundamentals
CLI mappings: 4
Last verified: 2026-06-02
Review level: template-spec-upgraded
Article depth: field-manual-template-specs

Learning paths Learn App delivery, edge, and API gateway path Load Balancer

Related context Learning path: App delivery, edge, and API gateway path Surf route: Network and private access path Prerequisite chain: Network isolation chain Concept cluster: Edge and API delivery

Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Load Balancer is the Azure service for spreading TCP or UDP traffic across multiple backend machines or scale-set instances. It does not understand URLs or cookies; it works at the network transport layer. A frontend IP receives traffic, rules decide which ports are balanced, probes decide which backends are healthy, and backend pools contain the targets. For operators, it is the standard answer when several VMs or appliances need one stable address and simple, fast traffic distribution.

Why it matters

Load Balancer matters because many platform services still depend on simple, predictable transport-level balancing. Firewalls, legacy applications, VM-based APIs, database listeners, and internal services often need one IP address that survives backend maintenance. Health probes remove failed instances from rotation, while rules keep client flows distributed without asking applications to know every server. Misconfiguration is painful: a bad probe can drain every backend, an outbound rule mistake can break internet egress, and a wrong frontend can publish a private service. For architects, Load Balancer is also the boundary between Layer 4 design and higher-level application routing choices. Ownership matters here.

Official wording and source

Azure Load Balancer is a managed Layer 4 service that distributes TCP and UDP flows to healthy backend instances. Microsoft Learn describes it as the client contact point that uses frontend IPs, backend pools, load-balancing rules, and health probes for inbound and outbound traffic.

Open Microsoft Learn

Technical context

Technically, Azure Load Balancer is a Layer 4 networking resource built from frontend IP configurations, backend address pools, health probes, load-balancing rules, inbound NAT rules, and outbound rules. It can be public, exposing a public frontend IP, or internal, exposing a private frontend inside a virtual network. Backends are commonly virtual machines, virtual machine scale sets, or IP configurations. It sits on the data path for TCP and UDP flows, while its configuration is managed through Azure Resource Manager and network APIs.

Exam context

AZ-305 Designing Microsoft Azure Infrastructure Solutions AZ-700 Microsoft Azure Network Engineer Associate

Compare with

NAT Gateway Network Security Group Public IP address Application Gateway

Where it is used

Where you see it

In the portal, Load Balancer appears with frontend IP configurations, backend pools, health probes, rules, inbound NAT rules, outbound rules, SKU settings, and diagnostics data.
In CLI output, pool membership, probe settings, port mappings, SKU, public IP references, zones, provisioning state, and resource IDs reveal the effective traffic path quickly.
In network troubleshooting, probe failures, NSG mismatches, missing NIC associations, route issues, or SNAT limits appear when backend instances stop receiving traffic from clients reliably.

Common situations

Expose several VM or scale-set instances through one stable public or private TCP or UDP address.
Front network virtual appliances that must receive symmetric Layer 4 flows without HTTP inspection.
Provide an internal listener for clustered services, legacy applications, or SQL Server workloads on VMs.
Manage outbound connectivity for backend instances through explicit outbound rules and SNAT planning.
Drain or replace backend instances during patching while healthy targets keep accepting traffic.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Internal payments listener stabilization Scenario, objectives, solution, measured impact, and takeaway.

Scenario

A payment processor ran a VM-based settlement service that several internal apps reached through hardcoded IPs. Maintenance on one VM often caused failed settlement batches.

Goals

Provide one stable private listener for settlement traffic.
Remove unhealthy VMs from rotation during patching.
Keep TCP traffic inside the virtual network.
Reduce failed settlement retries during month-end processing.

Approach using Load Balancer

The infrastructure team deployed an internal Standard Load Balancer with a private frontend IP in the payments subnet. Backend pools contained three settlement VMs, and TCP health probes checked the service port plus a lightweight readiness endpoint through a sidecar listener. Load-balancing rules distributed settlement traffic across healthy VMs, while NSGs allowed only application subnets and Azure probe traffic. Runbooks used CLI to list backend pool membership, probe health, and rules before patch windows. During maintenance, operators drained one VM by removing it from the backend pool, patched it, validated readiness, and returned it without changing client configuration. A rollback table captured old pool membership before patching.

Potential outcomes

Failed month-end settlement retries dropped 72% after unhealthy nodes stopped receiving flows.
Patching completed during business hours with no client IP changes.
Traffic stayed private, satisfying the internal network-segmentation requirement.
Operations reduced settlement maintenance coordination from six teams to one runbook.

What to learn

Internal Load Balancer is valuable when legacy or VM-based services need stable private access while individual backends change safely.

Scenario 02 Network appliance scale set ingress Scenario, objectives, solution, measured impact, and takeaway.

Scenario

A logistics company used firewall appliances in Azure to inspect partner TCP traffic. A single appliance became a throughput bottleneck whenever shipment updates spiked.

Goals

Distribute partner TCP flows across multiple firewall appliances.
Keep symmetric flow behavior for inspection stability.
Scale appliance instances without changing partner allowlists.
Expose only approved ports through a controlled frontend.

Approach using Load Balancer

Network architects placed a public Standard Load Balancer in front of a firewall virtual machine scale set. The frontend public IP remained the address partners allowlisted, while backend pools contained appliance instances. Load-balancing rules covered only approved TCP ports, and probes checked appliance readiness rather than basic VM status. NSGs restricted management access, and outbound routing kept inspected flows on the required path. CLI checks were added to the network runbook to verify backend pool membership, probe state, rule definitions, and public IP association whenever the scale set changed capacity. Partner test traffic verified every approved port after scaling, and the team recorded evidence.

Potential outcomes

Peak accepted connection rate increased 2.6 times without partner allowlist changes.
Probe-based removal prevented two unhealthy appliances from blackholing shipment traffic.
Unapproved public ports were eliminated from the frontend rule set.
Capacity increases now take 18 minutes instead of a two-day partner coordination window.

What to learn

Load Balancer lets appliance patterns scale while preserving one stable network entry point and controlled Layer 4 exposure.

Scenario 03 Outbound SNAT incident cleanup Scenario, objectives, solution, measured impact, and takeaway.

Scenario

An analytics team ran worker VMs that called external vendor APIs. Random timeout spikes appeared after a new batch job increased parallel connections.

Goals

Identify whether failures came from application code or outbound networking.
Stabilize vendor API calls under high concurrency.
Create explicit outbound behavior for worker pools.
Reduce failed batch reruns and wasted compute time.

Approach using Load Balancer

Engineers found the worker pool behind a Standard Load Balancer with default outbound behavior that no one had documented. CLI inspection showed frontend IP associations but no planned outbound rules, while metrics indicated SNAT port pressure during batch peaks. The team created explicit outbound rules with a dedicated public IP prefix, tuned connection reuse in the workers, and split high-volume jobs across additional backend instances. NSG rules and vendor allowlists were updated to match the new outbound addresses. Runbooks now check outbound rule configuration and SNAT indicators before increasing batch concurrency. Runbook ownership was documented clearly.

Potential outcomes

Vendor API timeout rate fell from 6.8% to 0.7% during nightly jobs.
Failed batch reruns dropped by 81%, saving about 220 VM-hours per month.
Vendor allowlist changes became predictable because outbound addresses were explicit.
Incident triage time fell from two days to under one hour for similar symptoms.

What to learn

Load Balancer design affects outbound reliability too; explicit SNAT planning prevents network limits from masquerading as random application failures.

Azure CLI

With ten years of Azure engineering experience, I use Azure CLI for Load Balancer because the service is easy to draw and easy to misconfigure. CLI output quickly shows frontend IPs, backend pools, probes, rules, NAT rules, outbound rules, SKU, and backend membership. During outages, that evidence tells you whether traffic is failing before the VM, at the probe, or inside the application. CLI also helps compare standard patterns across environments and capture exact settings before changing rules or pools. The portal is useful, but fast network triage benefits from repeatable commands and JSON that can be diffed. Evidence wins incidents.

Useful for

List frontends, backend pools, probes, and rules before changing a production listener.
Inspect backend membership when only some VMs receive traffic or probes fail.
Review outbound rules and public IP associations while troubleshooting failed external calls.

Before you run a command

Confirm tenant, subscription, resource group, load balancer name, SKU, region, frontend IP, and backend pool targets.
Know whether the command changes live traffic, NAT access, outbound connectivity, or only reads configuration.
Check NSG rules, route tables, backend health, and maintenance windows before removing or adding backend members.

What the output tells you

Frontend output shows the address and port surface that clients or internal services actually target.
Probe and backend pool output shows which instances are eligible to receive balanced flows.
Rule and outbound-rule output explains inbound distribution, NAT behavior, protocol scope, and egress design.

Mapped commands

Load Balancer CLI commands

direct

az network lb show --name <load-balancer> --resource-group <resource-group>

az network lbdiscoverNetworking

az network lb list --resource-group <resource-group> --output table

az network lbdiscoverNetworking

az network lb address-pool list --lb-name <load-balancer> --resource-group <resource-group>

az network lb address-pooldiscoverNetworking

az network lb probe list --lb-name <load-balancer> --resource-group <resource-group>

az network lb probediscoverNetworking

az network lb rule list --lb-name <load-balancer> --resource-group <resource-group>

az network lb rulediscoverNetworking

az network lb outbound-rule list --lb-name <load-balancer> --resource-group <resource-group>

az network lb outbound-rulediscoverNetworking

Architecture context

Architecturally, Load Balancer belongs in the regional network design for workloads that need Layer 4 distribution rather than Layer 7 routing. Public Load Balancer fronts internet-facing TCP or UDP services, while internal Load Balancer fronts private services inside a virtual network. It often works with virtual machine scale sets, network virtual appliances, SQL Server availability groups on VMs, or custom appliances. It is not a TLS terminator and does not route by host name or path, so architects pair it with Application Gateway or Front Door when HTTP intelligence is required. Subnet, NSG, route table, public IP, and outbound SNAT design all influence its behavior.

Security: Security impact is direct for public load balancers and indirect for internal ones. A public frontend can expose TCP or UDP ports to the internet, so NSGs, allowed source ranges, firewall appliances, and backend hardening matter. Load Balancer does not inspect application payloads, terminate TLS, or provide WAF protection, so do not treat it as an application firewall. Internal load balancers still matter because they can make services reachable across subnets or peered networks. Limit who can change rules, NAT mappings, and backend pools. Review diagnostic settings, public IP ownership, and NSG flow logs when investigating unexpected exposure. Document exposure.
Cost: Load Balancer cost depends on SKU, rule count, data processed, public IP resources, outbound traffic, diagnostic logs, and unused resources left behind after migrations. The direct bill is usually modest, but the indirect cost can be severe when a bad probe or SNAT design causes downtime. Multiple teams sometimes create duplicate load balancers for small services instead of sharing a planned pattern, which adds management overhead. Diagnostic and flow logs can also grow quickly in high-throughput environments. FinOps checks should identify idle frontends, obsolete NAT rules, unused public IPs, unexpected data transfer, and basic-tier resources that should be retired. Review monthly.
Reliability: Reliability depends on probes, backend pool membership, SKU selection, zone design, and clear maintenance procedures. Standard Load Balancer supports stronger production patterns than Basic, and zone-redundant or zonal frontends can reduce failure risk when designed correctly. Health probes must represent actual service readiness, not just open ports. Backend instances should be drained or removed deliberately during patching. Outbound connectivity should be planned so SNAT exhaustion does not appear as random application failures. Monitor data path availability, probe health, SYN counts, SNAT port usage, and backend VM health to separate network balancing issues from workload issues. Test failover during maintenance windows.
Performance: Performance is generally strong because Load Balancer works at Layer 4 and does not proxy application payloads. Still, throughput, latency, and connection success depend on backend capacity, health probe intervals, flow distribution, SNAT port availability, NSG rules, and route-table paths. Hot backends can occur if session behavior, client patterns, or hashing results concentrate traffic. Outbound SNAT exhaustion can look like slow or failed external calls even when inbound balancing is fine. Track flow counts, data path availability, probe status, backend CPU, connection resets, and application response time. Use Application Gateway or Front Door when performance problems require HTTP-aware routing or caching.
Operations: Operators inspect Load Balancer by listing frontend IPs, backend pools, probes, rules, NAT rules, outbound rules, and backend associations. Routine work includes adding VM scale set instances, changing probe paths or ports, reviewing inbound NAT access, validating outbound rules, and documenting public exposure. During incidents, operators check whether probes mark backends down, whether NSGs allow probe and client traffic, and whether route tables or appliances changed the path. Production runbooks should include how to drain backends, capture current configuration, validate from test clients, and coordinate with application owners before modifying rules. Keep a signed change record for every production rule update.

Common mistakes

Assuming Load Balancer can route by URL path or hostname when that requires Application Gateway or Front Door.
Using a health probe that checks an open port but not the application service behind it.
Forgetting outbound SNAT planning and then treating external connection failures as application bugs.