Demystifying Azure Networking: WAF vs. Front Door vs. App Gateway vs. Firewall

When I first started diving deep into Azure architecture, I found the networking stack incredibly confusing. Why is there a WAF option inside Front Door? Is Application Gateway just a fancy Load Balancer? Do I need a Firewall if I already have a WAF?

After building several projects on Azure, I've finally mapped out the "why" and "where" for each tool. Here is the definitive guide to the Azure security stack.

---

1. The Core Hierarchy: Global vs. Regional

The first thing to understand is where these services live. If you don't get the scope right, you'll end up with a slow app or a security hole.

---

2. Web Application Firewall (WAF): The Brain, Not the Body

A common mistake is searching for "WAF" and expecting a standalone server. WAF is a Policy. Think of it as a set of instructions — "Block SQL Injection," "Block XSS," and so on. To work, that policy needs a "Body" to execute it.

In Azure, you have two choices for that body:

• •Front Door — to stop attacks at the global edge, closest to the attacker.
• •Application Gateway — to stop attacks right before they hit your web server in a specific region.

A WAF policy on its own does nothing. It is always attached to one of these two hosts.

---

3. Azure Front Door: The Global "Live Proxy"

Front Door is a Reverse Proxy and CDN. Every request from a user's browser stops at a Microsoft Edge node (190+ worldwide) before it ever reaches your origin server.

What it actually does

Without WAF, Front Door is a pure CDN and global load balancer. It caches your static assets (images, JS, CSS) at edge nodes closest to your users. A visitor in Tunis hits a node in Africa. A visitor in Tokyo hits a node in Asia. For cached content, neither makes a round trip to your Azure region — your origin server never sees those requests. Dynamic requests like /api/* are never cached and always forwarded to your origin, but they still benefit from travelling through Microsoft's private backbone instead of the public internet.

With WAF attached, every request is also inspected against your security rules before the cached or forwarded response is returned.

When to use it

• •Your app has global users and you want low latency everywhere.
• •You want to cache static assets without managing a separate CDN.
• •You want to absorb DDoS and block attacks before traffic ever reaches your infrastructure.
• •You have multiple backends (e.g. different origins per region) and need intelligent global routing.

The Decryption Catch

For Front Door to do its job, it must decrypt your traffic at the Edge. Here's why:

• •WAF Visibility: A WAF cannot block a malicious script if the payload is an encrypted black box.
• •Path Routing: Front Door needs to read the URL path (/api vs. /static) to route the request to the correct backend.

Pro tip: Use End-to-End TLS. Front Door decrypts the data for a microsecond to inspect it, then re-encrypts it before forwarding to your origin. Your data is never sent over the wire in plain text — it just briefly exists decrypted inside Microsoft's edge infrastructure.

User  ──>  Front Door Edge (decrypt → inspect → re-encrypt)  ──>  Your Server

---

4. Application Gateway: The Regional Load Balancer

If Front Door is the "Global Gate," Application Gateway is the "Lobby Manager" — it lives inside your VNet and decides which internal server handles each request.

What it actually does

Application Gateway is a Layer 7 (HTTP/S) load balancer. Unlike a basic load balancer that routes by IP and port, App Gateway reads the actual URL path and routes based on it. This is called path-based routing:

/api/*      ──>  API backend pool  (your Node.js servers)
/images/*   ──>  Static backend pool  (your storage servers)
/admin/*    ──>  Admin backend pool  (separate, locked-down VMs)

All of this happens at the VNet boundary. App Gateway does have a public IP and can receive traffic directly from the internet — what it protects is everything behind it. Your backend servers are never exposed; App Gateway is the only entry point in that region.

When to use it

• •You have microservices and want to route /orders, /users, /payments to different backend services without exposing each one separately.
• •You need session affinity — your app stores login state on a specific server instance and a user must always land on the same one.
• •You want a WAF closer to your servers as a second security layer after Front Door.
• •You need TLS termination inside the VNet so your app servers don't have to handle SSL.

Can you use both Front Door and App Gateway? Yes — and it's the most common production pattern. Front Door handles the global edge (CDN, DDoS, edge WAF). App Gateway handles internal routing and a second WAF layer right before your servers.

Internet  ──>  Front Door (global WAF + CDN)  ──>  App Gateway (path routing + regional WAF)  ──>  VMs / Containers

---

5. Azure Firewall: The Network Gatekeeper

Both WAF and Azure Firewall can process HTTP/S traffic, but they operate at completely different inspection levels. WAF understands HTTP content — it reads the request body, headers, and query strings to catch SQLi or XSS payloads. Azure Firewall understands network traffic — it enforces rules based on IPs, ports, and FQDNs regardless of what's inside the packet.

• •It operates at Layer 3 & 4 (IPs and Ports) and Layer 7 for application rules.
• •Use it to block RDP (3389) or SSH (22) access to your servers from the public internet.
• •Use it for FQDN Filtering: "My backend server is only allowed to reach github.com for package updates — block all other outbound destinations."

This is the tool that governs east-west traffic (between services inside Azure) and outbound traffic from your VMs. A WAF never sees an RDP packet. A Firewall does.

---

6. Architecture Cheat Sheet: When to Use What

The "Gold Standard" Architecture

In production, Azure Firewall doesn't typically sit inline between Front Door and App Gateway. Because Front Door delivers traffic from hundreds of Microsoft edge IPs, a Firewall in that path would need to allowlist the entire Microsoft IP range — which defeats the purpose. Instead, Firewall lives in a Hub VNet and controls two things: outbound traffic from your servers, and east-west traffic between internal services.

Internet
   │
   ▼
Azure Front Door  (global anycast, CDN, WAF policy)
   │
   ▼
Application Gateway  (regional load balancer, WAF policy)  ◄── Spoke VNet
   │
   ▼
Your Servers / Containers
   │
   ▼
Azure Firewall  (Hub VNet — controls outbound + east-west traffic)
   │
   ▼
Other Internal Services / Internet (outbound)

Each layer has a distinct job. Front Door handles the global edge. App Gateway routes and inspects traffic at the VNet boundary. Firewall governs what your servers are allowed to reach and what can travel between internal services. They are not redundant — they are complementary.

---

The confusion usually comes from the fact that WAF is a policy, not a service, and that Front Door and App Gateway both look like "load balancers" from the outside. Once you anchor each tool to its scope — global edge vs. regional VNet vs. network layer — the architecture decisions become much clearer.