Skip to main content
Choosing the right Azure load balancer is a critical decision for network design. This guide explains the available load balancer types, when to use each, and how SKU differences affect scale, availability, security, and outbound behavior. Use this to align your design with application exposure, resiliency, and inspection requirements.

​
Public vs Internal load balancers

  • Public load balancer: receives traffic from the internet using a public IP and distributes it to backend virtual machines. Use when a workload requires external access (for example, public-facing web apps or APIs).
  • Internal load balancer: balances traffic privately inside a virtual network. Use for services that must remain internal (for example, backend APIs, databases, or microservices not exposed to the internet).
Load Balancer TypeTypical Use CasesHow it Appears on the Network
Public Load BalancerExternal web apps, public APIs, CDN front-endsExposes a public IP; internet consumers connect directly
Internal Load BalancerBackend tiers, internal APIs, database accessUses private IPs within a VNet; only reachable from within the VNet or via peering/VPN/ExpressRoute
A network diagram titled "Choosing a Load Balancer Type" showing a public load balancer (from the internet on TCP port 80) distributing traffic to VMs in a Web Tier subnet, and an internal load balancer distributing traffic (port 443) to VMs in a Business Tier subnet inside a virtual network.
A common, secure pattern is a tiered application: a public load balancer handles incoming internet traffic at the web tier, while an internal load balancer distributes traffic among internal tiers (business logic, caching, or databases). This separation helps you:
  • Limit external exposure and reduce attack surface
  • Apply security controls (NSGs, firewalls) per tier
  • Optimize routing, scaling, and performance for each layer

​
Gateway Load Balancer (GWLB)

Gateway Load Balancer is designed to insert third-party Network Virtual Appliances (NVAs) — such as virtual firewalls, IDS/IPS, or other security appliances — into your traffic path. It preserves flow affinity, supports transparent inspection, and enables chaining multiple NVAs while providing high availability and throughput. In typical GWLB deployments, unfiltered traffic from the internet (or between networks) is routed through the gateway load balancer to provider NVAs for inspection. NVAs apply filtering and policies, then forward the filtered traffic to application endpoints.
A network diagram titled "Gateway Load Balancer" showing how unfiltered web traffic from customer virtual networks is routed through a gateway load balancer to provider Network Virtual Appliances (NVAs) for inspection. Filtered application traffic is then returned to the customer applications, illustrating high availability and throughput.
Gateway Load Balancer adds operational complexity and cost: you must deploy, manage, and license NVAs. Ensure routing, encapsulation (tunnels), and health checks are tested end-to-end. GWLB is ideal when you require inline inspection, third‑party security features, or service chaining.
Key Gateway Load Balancer components:
  • Front-end IP: receives incoming traffic from consumers.
  • Load-balancing rules: define packet distribution to backend pools.
  • Backend pools (backend resources): the NVAs or instances that inspect traffic.
  • Tunnel interfaces: encapsulate traffic to deliver it directly to NVAs.
  • Chaining: route traffic through multiple NVAs in sequence for layered inspection.
These components allow you to route traffic from virtual networks through GWLB to one or more NVAs, then return filtered traffic to application endpoints.

​
Load Balancer SKUs: Basic vs Standard

Azure Load Balancer comes in two SKUs: Basic and Standard. Each SKU differs in scale, features, availability, and default security posture. Choose the SKU that matches your workload requirements for throughput, resiliency, and security.
CapabilityBasic SKUStandard SKU
Backend pool sizeUp to 300 IP configurationsUp to 5,000 backend instances
Health probesTCP, HTTPTCP, HTTP, HTTPS
AvailabilityNo zone redundancy / limited availability guaranteesZonal and zone‑redundant deployments supported
Multiple frontendsNoYes — multiple front-end IP configurations
Security defaultsLess restrictive; NSGs optionalSecure by default: inbound flows blocked unless NSG allows; internal VNet flows allowed
SLANone99.99% SLA for supported configurations
A slide titled "Determining Load Balancer SKUs" showing a side-by-side table comparing Basic and Standard SKUs. The table lists differences for Backend Pool Size, Health Probes, Availability Zones, Multiple Frontends, security defaults, and SLA (e.g., Basic: up to 300 IPs, no SLA; Standard: up to 5,000 instances, 99.99% SLA).
For production workloads requiring scale, zone resiliency, and a supported SLA, the Standard SKU is strongly recommended. Use Basic only for small-scale, non-production, or legacy scenarios where limited features are acceptable.
When creating a load balancer, you will be prompted to choose:
  • SKU (Basic or Standard)
  • Region and availability options (zonal vs zone‑redundant)
  • Type (Public or Internal)
  • Front-end IP configuration(s)
  • Backend pools and health probes
  • Load‑balancing rules and optional NAT rules
The SKU and type you choose directly affect scalability, security posture, availability, and outbound connectivity behavior. Align these choices with application requirements (exposure, throughput, resiliency, inspection).

​
Design checklist

  • Use Public load balancer for internet-facing front ends; Internal load balancer for private backend tiers.
  • Prefer Standard SKU for production for SLA and zone resilience.
  • Use Gateway Load Balancer when you need inline NVAs for inspection or service chaining.
  • Plan NSGs and route tables explicitly when using Standard SKU (default inbound flows are blocked).
  • Validate health probes and failover behavior across zones in zone-redundant setups.
With these guidelines, you can select the appropriate Azure load balancer type and SKU to meet your application’s exposure, availability, and security requirements.

Watch Video