Skip to main content
Azure Load Balancer is a Layer 4 (transport layer) load-balancing service that distributes TCP and UDP traffic across Azure virtual machines and virtual machine scale sets. When client requests reach the load balancer frontend, Azure evaluates load-balancing rules and health probes to route traffic to healthy backend instances — preventing any single server from becoming overloaded and improving availability for your application. Key capabilities:
  • Layer 4 TCP/UDP load balancing for VMs and VM scale sets
  • Health probes (TCP/HTTP/HTTPS) to determine instance health
  • Frontend IP configurations (public or private)
  • Integration with Network Security Groups (NSGs) for access control
A presentation slide titled "Azure Load Balancer" listing key features (Layer-4, Standard/Basic SKUs, TCP/UDP support, and security via Network Security Groups) with icons down the left. On the right is a simple diagram showing frontend traffic flowing through a load balancer to a backend.

​
Load Balancer SKUs

Azure provides two Load Balancer SKUs: Basic and Standard. Choose the SKU based on scale, resiliency, security posture, and production SLA requirements.
For production and internet-facing services, the Standard SKU is recommended because it provides higher scale, zone redundancy, stricter security defaults, and an SLA. Use Basic for small dev/test workloads where cost is the primary concern.
An infographic titled "Load Balancer SKU" showing two colored pipelines labeled "Basic Load Balancer" (blue) and "Standard Load Balancer" (orange). Below is a comparison table listing features like backend pool size, health probes, redundancy, security, and SLA.

​
Implementations: Public and Internal (Private) Load Balancer

Azure Load Balancer can be deployed as either Public (internet-facing) or Internal (private) depending on whether the frontend IP is a public IP address.

​
Public Load Balancer

A Public Load Balancer provides inbound connectivity from the internet to resources inside your virtual network. Typical usage:
  • Expose web-facing services (HTTP/HTTPS) to internet clients
  • Use a public frontend IP and one or more load-balancing rules to map client ports (e.g., 80/443) to backend pool ports
  • Health probes monitor backend VMs and take unhealthy instances out of rotation
Public Load Balancers are the recommended solution for distributing incoming internet traffic across multiple VMs and providing fault tolerance for web applications.
A diagram titled "Public Load Balancer" showing users connecting on port 80 to a public load balancer that distributes traffic to multiple web servers (VMs) in a WebSubnet inside a virtual network. A side note says "Ideal for public facing workloads."

​
Internal (Private) Load Balancer

Internal Load Balancers (ILBs) use a private frontend IP and are intended for internal communications within a virtual network or across peered VNets. Typical scenarios:
  • Load-balance traffic between application tiers (e.g., web → app → database)
  • Isolate back-end services from the public internet
  • Support stateful backends, availability groups, and private APIs
Important: a load balancer without a public IP is considered internal. When planning an ILB, ensure proper NSG rules, routing, and probe configuration so internal clients can reach the ILB and the ILB can assess backend health.
Ensure you configure NSG rules to explicitly allow traffic for Standard SKUs. The Standard SKU is locked down by default and will block traffic unless NSGs permit it. This is a common cause of misconfigured load balancing in production.

​
Core Load Balancer Concepts

​
Best Practices

  • Use Standard SKU for production workloads to gain SLA, scale, and zone redundancy.
  • Configure health probes (HTTP/HTTPS preferred when applicable) that reflect real application endpoints so the load balancer can detect unhealthy instances accurately.
  • Apply NSGs to subnets or NICs to control access, and ensure rules explicitly allow required traffic when using Standard SKU.
  • For multi-zone resilience, deploy Standard Load Balancer with zonal or zone-redundant configuration.
  • Monitor diagnostics and metrics (via Azure Monitor) to track probe failures, rule hits, and backend health.

Watch Video