Load Balancer
Azure Load Balancer is a high-throughput Layer 4 load balancer for TCP and UDP traffic. It distributes connections across a backend pool of VMs or scale-set instances within a region, at very low latency and very high scale, with no per-connection processing of the application payload. It moves packets, it does not read HTTP.
Because it works at Layer 4, it sees ports and IPs, not URLs, headers, or cookies. For HTTP routing, TLS termination, or a web application firewall you need Application Gateway (regional) or Front Door (global). Reaching for a Layer 4 balancer when you needed Layer 7 features is the common confusion this chapter untangles.
Public and Internal
A public load balancer has a public IP and balances internet-facing traffic; an internal load balancer has a private IP and balances traffic inside a VNet — between application tiers, for example. The same engine serves both; the difference is where the frontend IP lives and who can reach it. Most deployments are regional, but a cross-region (Global) tier exists for Layer 4 anycast that fronts regional load balancers worldwide.
SKU
The Standard SKU is the production choice: zone-redundant, secure-by-default (traffic is denied unless an NSG allows it), and integrated with availability zones. The Basic SKU was retired on 30 September 2025 — existing Basic load balancers still run but are unsupported and without an SLA, and new ones can no longer be created. All deployments should use Standard.
Load BalancerLayer 4, regional
Application GatewayLayer 7, regional
Front DoorLayer 7, globalHealth Probes
Health probes determine which backend instances receive traffic. A probe checks a port or path on each instance; instances that fail are removed from rotation until they recover. A misconfigured or missing probe is a classic outage cause — the balancer keeps sending traffic to dead instances, or removes healthy ones because the probe target was wrong.
Rules and Outbound
Load-balancing rules map a frontend IP and port to a backend pool and port, with a distribution mode. Outbound connectivity must now be explicit: default (implicit) outbound access was retired on 30 September 2025, so a new VM has no internet access at all until you attach a NAT gateway, an outbound rule, or a public IP. Even before that, leaning on implicit SNAT exhausted ports under load. Plan outbound deliberately — a NAT gateway is the usual answer — rather than discovering the gap in production.
Load Balancer — Layer 4 (TCP/UDP), regional, highest throughput, no payload inspection. Choose it for non-HTTP or raw-performance traffic distribution.
Application Gateway — Layer 7, regional, with URL routing, TLS termination, and an optional WAF. Choose it for web ingress inside a region.
Front Door — Layer 7, global anycast with caching and edge WAF. Choose it for multi-region web apps and edge delivery.
- Reaching for Load Balancer when the workload needs URL routing, TLS termination, or a WAF — those are Layer 7, on Application Gateway or Front Door.
- Still depending on the retired Basic SKU (retired September 2025, now unsupported) instead of migrating to Standard with zone redundancy and an SLA.
- Misconfiguring the health probe so the balancer sends traffic to dead instances or drops healthy ones.
- Expecting new VMs to reach the internet by default — implicit outbound access was retired in September 2025, so they need a NAT gateway, an outbound rule, or a public IP (a NAT gateway also avoids the old SNAT port-exhaustion trap).
- Forgetting that the Standard SKU is deny-by-default, so traffic fails until an NSG explicitly allows it.
- Deploying a single-zone configuration where zone redundancy was needed for the SLA.
- Use the Standard SKU for production — zone-redundant, secure-by-default, with an SLA.
- Use Application Gateway or Front Door for anything needing Layer 7 features; keep Load Balancer for L4.
- Configure health probes against a meaningful endpoint so only healthy instances receive traffic.
- Plan outbound connectivity with a NAT gateway or explicit outbound rules to avoid SNAT port exhaustion.
- Allow required traffic explicitly with NSGs, since the Standard SKU denies by default.
- Spread the backend across availability zones for resilience.
Knowledge Check
Why can Azure Load Balancer not perform URL-based routing or TLS termination?
- It operates at Layer 4 (TCP/UDP) and does not inspect the payload — that is Application Gateway or Front Door
- It only supports internal private traffic and can never serve a public-facing internet frontend of any kind at all
- Those Layer 7 features require upgrading to the Basic SKU tier
- It lacks a configured backend address pool to route into
Instances behind a Standard Load Balancer fail outbound connections under heavy load. What is the likely cause?
- SNAT port exhaustion from relying on implicit outbound instead of a NAT gateway or explicit outbound rules
- The health probe is checking the wrong backend port on instances
- The load balancer is deployed in the wrong Azure region, far away from the backend instances it actually serves
- Zone redundancy is disabled across the availability zones
What happens when a backend instance fails its health probe?
- It is removed from the rotation until its probes pass and it recovers
- The entire load balancer instance fails over to another paired Azure region
- Traffic is still sent to it but logged as failed
- The probe is disabled to avoid false positives
You got correct