When to Use Azure Load Balancer vs Application Gateway

Azure offers multiple load-balancing services because load balancing is not one problem. Distributing TCP traffic is different from routing HTTP requests by URL path, which is different from serving a globally distributed user base from the nearest region.

Azure Load Balancer and Application Gateway are the two services for workloads within a region. Choosing between them is a layer question: Load Balancer operates at layer 4 (transport: TCP/UDP), Application Gateway operates at layer 7 (application: HTTP/HTTPS). The difference in what each can see and act on is what determines which one is right.

What each service can do

Azure Load Balancer distributes TCP and UDP traffic across a backend pool of VMs, VM Scale Set instances, or IP addresses. It uses a hash of the 5-tuple (source IP, source port, destination IP, destination port, protocol) to determine which backend receives each connection. It cannot inspect the content of the traffic: it does not read HTTP headers, URL paths, or cookies. It cannot terminate TLS, re-encrypt traffic, or make routing decisions based on anything in the HTTP request.

What it does well: high throughput, very low latency, and simplicity. It adds minimal overhead because it operates at the network layer without content inspection. For non-HTTP workloads (database connections, custom TCP protocols, UDP applications), it is the right tool.

Azure Application Gateway is an HTTP/HTTPS reverse proxy with load balancing, SSL/TLS termination, URL-based routing, host-header routing, session affinity, a web application firewall (WAF), and automatic redirects. It can route /api/ requests to one backend pool and /static/ requests to another. It can terminate TLS at the gateway and re-encrypt to the backend. It can inspect every HTTP request for malicious content via the WAF.

What it does well: flexible HTTP routing, security inspection, and centralised TLS management. It adds latency compared to Load Balancer (it must buffer and parse each request) but for HTTP workloads this is typically under 1ms and is acceptable.

The decision: do you need layer 7?

If you need any of the following, use Application Gateway: - Route requests to different backends based on URL path or host header - Terminate TLS at a single point and manage certificates centrally - Protect web applications with a WAF (OWASP rule sets, custom rules) - Session affinity (sticky sessions) based on cookies rather than source IP - Redirect HTTP to HTTPS automatically - Serve multiple applications with different domains from a single IP via host-header routing

If you do not need any of the above, use Load Balancer. It is cheaper, simpler, and adds less latency. Examples where Load Balancer is right: - A backend service that receives calls from other Azure services, not from browser clients - A UDP service - A custom TCP protocol that is not HTTP - A database connection that needs simple connection distribution without content inspection

The common mistake is deploying Application Gateway by default for every workload because it is the more feature-rich option. For internal-only services, non-HTTP protocols, or high-throughput pipelines where WAF and URL routing are not needed, Application Gateway adds cost and complexity without benefit.

Internal vs external load balancing

Both services come in public-facing and internal variants.

A public Load Balancer or Application Gateway has a public IP and accepts connections from the internet. An internal Load Balancer or Application Gateway has a private IP and accepts connections only from within the VNet (or from on-premise via VPN/ExpressRoute).

Internal Application Gateway is common in hub-and-spoke architectures where a central WAF-enabled Application Gateway receives inbound traffic from Azure Front Door or an external Load Balancer, inspects it, and forwards to backend services in spoke VNets.

SKUs and cost

Azure Load Balancer: Standard SKU is required for production (Basic is deprecated for production use). Standard charges a per-hour fee plus a per-rule fee per month and a data processing charge.

Application Gateway: v2 SKU (Standard_v2 or WAF_v2) is current. Charges a per-hour fee for the gateway instances plus a per-capacity-unit charge that scales with throughput and number of connections.

For small deployments, Application Gateway WAF_v2 costs several hundred pounds per month. For high-throughput deployments, the capacity unit costs scale with load. For workloads that do not need WAF or HTTP routing, this is unambiguously more expensive than Load Balancer for the same distribution function.

If WAF is a requirement (for PCI DSS, for compliance frameworks that mandate protection of web applications, or for FCA-regulated workloads with internet-facing services), Application Gateway WAF_v2 is cost-justified as a security control rather than a network control.

Running both

The two services are often used together. A common pattern: an external Application Gateway with WAF terminates TLS, inspects traffic, and routes based on URL path to internal Load Balancers in front of different backend tiers. The Application Gateway handles the HTTP intelligence; the internal Load Balancers handle the high-throughput distribution to individual compute instances.

This separates the security and routing concern (Application Gateway) from the connection distribution concern (Load Balancer) and keeps each service doing what it does best.

Another common pattern: Front Door (or Traffic Manager for multi-region routing) routes globally, Application Gateway handles application-layer routing and WAF within a region, and Load Balancer handles connection distribution to instances within each backend tier.

Where Critical Cloud comes in

Networking architecture decisions set the pattern for the life of the workload. The cost of choosing Application Gateway where Load Balancer was sufficient, or missing WAF protection where PCI DSS or FCA rules require it, compounds over time. We design and operate Azure networking for regulated and technology-led businesses, with load balancing architecture matched to the workload and security requirements. See how Critical Support works.