DevOpsInterviewPrep logo
Cloud Platforms & Architecture / 04
easyNewMicrosoftInfosysTCS

Azure Load Balancer, Application Gateway, Front Door: which one, and why are there three?

One is layer 4 and regional, one is layer 7 and regional, one is layer 7 and global. Answer on those two axes and the choice makes itself, including when you need two of them together.

Updated Sep 2026 · Grounded in researched DevOps, SRE and platform engineering interview loops, written to a senior-engineer editorial bar, and never padded to hit a word count.

TL;DR: Load Balancer is layer 4 within a region, Application Gateway is layer 7 within a region with a web application firewall, Front Door is layer 7 at the global edge. Pick on the two axes of protocol layer and scope, and expect to use Front Door in front of a regional gateway for anything multi-region.

How to approach it

Give the two axes before naming products, because the three names are memorisable and the reasoning is not. Then state clearly that they combine rather than compete, since the most common real architecture uses two of them and candidates often present it as an exclusive choice.

A strong answer

The two questions that decide it: does the decision need to see the HTTP request, and does it need to happen close to the user or inside one region?

Azure Load Balancer is layer 4. It distributes TCP and UDP connections across a backend pool inside one region, using a five-tuple hash. It cannot see a URL path or a hostname, cannot terminate TLS and cannot route on anything in the request. It is extremely fast, costs little, and is the right answer for non-HTTP traffic, for internal traffic between tiers, and for anything where the routing decision is per connection. The internal variant gives you a private front end inside a VNet, which is how you balance an internal API without exposing it.

Application Gateway is layer 7 and regional. It terminates TLS, reads the request, and routes on hostname and path. That gives you path-based routing to different backend pools, host-based routing for several sites, cookie-based session affinity, URL rewriting, and end-to-end TLS if you want it re-encrypted to the backend. Its Web Application Firewall tier adds OWASP rule sets, which is often the reason it is chosen at all. It lives in a VNet, so it can reach private backends directly.

Front Door is layer 7 and global. It is an edge network with points of presence worldwide, terminating the connection close to the user and carrying traffic onward over Microsoft's backbone. What that buys is latency (the TLS handshake happens near the user, which takes a round trip out of every new connection and shows up most in tail latency), global routing to the healthiest or nearest region, failover between regions on health probes, caching for static content, and DDoS absorption at the edge. It also has a WAF.

The architecture that uses two:

user -> Front Door (global routing, WAF, TLS at the edge, caching)
          -> Application Gateway, region A (path routing, private backends)
          -> Application Gateway, region B

Front Door decides which region, the gateway decides which service inside it. For a single-region application, Application Gateway on its own is usually enough, and adding Front Door buys you edge termination and DDoS protection rather than routing you need.

Traffic Manager deserves a mention because it looks like Front Door and is not. It is DNS-based: it returns a different answer depending on the routing method, and the client then connects directly. So it works for any protocol, not just HTTP, and it inherits DNS's failover problem, which is that clients and resolvers cache the answer and keep using a dead region for minutes after the record changed. Front Door, terminating the connection itself, moves traffic in seconds. For HTTP, prefer Front Door; for non-HTTP global routing, Traffic Manager is what exists.

What interviewers probe next

"How does failover actually work in Front Door?" Health probes against each backend, with priority and weight. Traffic moves at the edge as soon as probes fail, with no client involvement, which is why it is far faster than a DNS change.

"Where would you put the WAF?" Once, as far forward as possible, so Front Door if you have it. Running WAF in both places doubles the cost and the false positives for little benefit.

"Can Application Gateway reach a backend in another region or on-premises?" Yes over VNet peering or a VPN, and it is usually the wrong shape. Cross-region backends belong behind a global front end rather than a regional one reaching across.

Common mistakes

Presenting the three as competitors when the common design layers Front Door over Application Gateway.

Using Traffic Manager for HTTP failover and being surprised that recovery takes minutes because of DNS caching.

Reaching for Application Gateway to balance non-HTTP traffic, which is what Load Balancer is for.

Putting a WAF at two layers and paying twice for the same rule set.

That one was free, and so are 18 answers per topic without an account. Signing in doubles that to 28, keeps your bookmarks, and tracks which topics you keep getting wrong.one Google click · no card · nothing to cancel
HOW DID IT GO?
0
UP NEXT ON YOUR JOURNEY
DISCUSSION · 0

Nothing here yet. Say how you would answer it.