Load Balancer or Application Gateway: which one do you need?

Both spread traffic across your backends, but one moves packets without ever looking inside them and the other reads the HTTP request to decide where it goes — and that single difference decides which one you reach for.

New to cloud? CAMPUX is a free, build-first course. Start here →

You have two servers and you want traffic split across them. Azure gives you two answers, and picking the wrong one costs you a redeploy later. The clean way to keep them straight is the OSI layer each one operates at. Load Balancer works at Layer 4. Application Gateway works at Layer 7. Layer 4 is the transport layer — TCP and UDP, ports and IP addresses. Layer 7 is the application layer — the actual HTTP request, with its URL path, its host header, its cookies. What a service can read is exactly what it can route on. That is the whole comparison.

What Layer 4 vs Layer 7 means for a routing decision

A Layer 4 device sees a connection: source IP, destination IP, a port number, and whether it is TCP or UDP. It does not open the payload. So the only routing question it can answer is "which healthy backend gets the next connection?" — and it answers that fast, because there is nothing to parse. A Layer 7 device terminates the connection, reads the HTTP request, and can route on what is inside: send /images to one pool and /video to another, or send api.contoso.com to a different backend than shop.contoso.com. That reading costs a little time and money per request, and buys you decisions Layer 4 physically cannot make.

What a service can read is exactly what it can route on. Everything else follows from that.

What Load Balancer does

Azure Load Balancer is the Layer 4 option. Microsoft's own line: it "operates at layer 4 of the Open Systems Interconnection (OSI) model" and distributes inbound flows "for all TCP and UDP applications." It is a pass-through balancer — the client connects straight through to a backend the algorithm picks — which is why it delivers ultra-low latency and scales to millions of flows. Because it never inspects content, it is protocol-agnostic: a database on 1433, a game server on UDP, a custom TCP protocol you invented on Tuesday — Load Balancer moves all of it the same way. That is its strength and its limit in the same sentence. It cannot do path routing, it cannot terminate TLS, it cannot read a cookie, because it never looks that deep.

What Application Gateway does

Application Gateway is the Layer 7 option, and Microsoft describes it plainly: "Unlike traditional load balancers that route traffic based on IP address and port, Application Gateway makes intelligent routing decisions based on HTTP request attributes like URL paths and host headers." It is a reverse proxy that terminates the request, so it can do the things that reading the request makes possible:

• Path-based and host-based routing — /video to the video pool, one hostname to one backend set.
• TLS/SSL termination — the certificate lives on the gateway, not on every backend VM, so you manage it in one place.
• Cookie-based session affinity — a user sticks to the same backend across requests.
• Web Application Firewall — an optional layer that inspects HTTP for SQL injection, cross-site scripting, and the OWASP top ten before it reaches your app.

All of that only works on HTTP and HTTPS. Point it at your UDP game server and it has nothing to read.

The real answer is usually "both" — or Front Door for global

Production architectures rarely pick one and stop. A common pattern puts Application Gateway in front of your web tier for path routing and WAF, and a Load Balancer behind it distributing to a pool of VMs — each doing the job at its own layer. Microsoft's guidance is explicit that "an effective setup often uses more than one type of load balancing solution." And note the boundary of both: they are regional services, living inside one Azure region. The moment you go multi-region and want a single global entry point with failover and edge acceleration, you move up to Azure Front Door — global Layer 7 — often with Application Gateway still doing regional work behind it (and the global tier itself splits into Front Door vs Traffic Manager). Front Door for the globe, Application Gateway for the region's HTTP smarts, Load Balancer for the raw transport underneath.

The takeaway

Load Balancer and Application Gateway are not competing products you agonize between — they are two layers of the same stack. Load Balancer is Layer 4: fast, protocol-agnostic, blind to content, perfect for TCP and UDP you just need spread. Application Gateway is Layer 7: it reads the HTTP request, so it does path and host routing, TLS termination, session affinity, and WAF. Decide by what you must route on, remember they are regional and Front Door is the global step up, and know that the mature answer is frequently to run more than one. "Layer 4 versus Layer 7, and often both" is how the answer sounds once you have built the stack instead of agonizing over which product name to pick.

Questions people also ask

Is Azure Application Gateway a load balancer?

Yes. Application Gateway is a Layer 7 load balancer, so it spreads traffic across backends the way Azure Load Balancer does. The difference is what it reads: it terminates the HTTP request and routes on URL path and host header, terminates TLS, and can run a Web Application Firewall. Load Balancer stays at Layer 4 and never opens the payload.

What is the difference between Azure Load Balancer and Application Gateway?

Load Balancer works at Layer 4, so it routes TCP and UDP by IP address and port without reading the payload. Application Gateway works at Layer 7, so it reads the HTTP request and routes on URL path and host header, terminates TLS, holds session affinity, and adds a WAF. Both are regional. You pick by what you need to route on.

When should you use Application Gateway?

You reach for Application Gateway when you run HTTP or HTTPS and need to route on the request itself: send /images to one backend pool and /api to another, split by hostname, terminate TLS in one place, keep a user pinned to a backend, or screen traffic with a WAF. For plain TCP or UDP with no content routing, you use Load Balancer instead.

Can you use Azure Load Balancer and Application Gateway together?

Yes, and production designs often do. A common pattern puts Application Gateway in front for path routing, TLS termination, and WAF, with an internal Load Balancer behind it spreading traffic across a pool of VMs. Each works at its own layer: the gateway handles the HTTP decisions, the Load Balancer handles fast transport-level distribution.

What is the difference between Application Gateway and Azure Front Door?

Both operate at Layer 7, but the scope differs. Application Gateway is a regional service that load balances inside one Azure region. Front Door is global: it sits at Microsoft's edge, routes across regions, and adds failover and edge acceleration. For a multi-region app you often place Front Door at the front and keep Application Gateway doing regional HTTP work behind it.