Is Azure Application Gateway a WAF?

A question that trips up almost everyone new to Azure networking, because the names overlap and the marketing pages don't help. The short version: it can be, but it isn't by default — and that gap has burned more teams than I can count.

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

No — Azure Application Gateway is a layer-7 load balancer; the WAF is an optional capability you enable on it (the WAF_v2 SKU with a WAF policy). Same story for Front Door (a global load balancer with an optional WAF). And neither is Azure Firewall, which is a network-layer firewall — a different job entirely.

I get this question in almost every cohort, and it is a fair one. Microsoft sells a product literally named "Application Gateway WAF," so people reasonably assume the whole thing is a firewall. Then someone deploys the plain Standard_v2 SKU, ships it to production, and is surprised months later to learn the WAF they thought they had was never there. The confusion is baked into the product line. Let me sort it out cleanly, because once you see the shape of it, the whole family stops being confusing.

The one distinction that fixes everything

Here is the mental model I hand every student. In Azure, the load balancer and the WAF are two different things that happen to live in the same box. The box is the load balancer. The WAF is a feature you can switch on inside it. You do not buy a WAF; you buy a load balancer and turn its WAF on.

So "is Application Gateway a WAF?" is a bit like asking "is a car a sunroof?" The car is the car. The sunroof is an option some trims have and others don't. Application Gateway is the car; the WAF is the sunroof. If you bought the base trim, there is no glass in the roof, no matter how much you wanted one.

Once you hold that separation in your head, every product in this family lines up. Let me put the whole confusing set in one place.

The whole family, sorted out

These four products get mixed up constantly because they all sit somewhere in the path of traffic and they all have "gateway" or "firewall" energy in their names. But they do genuinely different jobs at different layers. Here is what each one is, the layer it works at, and whether a WAF is part of the picture.

Read down the WAF column and the pattern is obvious. Only the two layer-7 HTTP products — Application Gateway and Front Door — can carry a WAF at all, because a WAF has to read the inside of an HTTP request to do its job. The layer-4 Load Balancer and the network-layer Azure Firewall operate below or beside that, so a web-application firewall isn't part of what they do.

You don't buy a WAF in Azure. You buy a layer-7 load balancer and switch its WAF on.

Is Application Gateway a load balancer, then?

Yes — that is its real identity. Application Gateway is a layer-7 load balancer, which means it understands HTTP. Unlike the plain layer-4 Load Balancer that just forwards TCP connections without caring what's inside them, Application Gateway reads the request and can route on it: send /api to one pool of servers and /images to another, split traffic by host header, terminate SSL, pin a user's session to one backend. That request-aware routing is the same reason it can host a WAF — it is already reading the request, so inspecting that request for attacks is a natural extension.

If you are still fuzzy on what layer-7 load balancing even means and why it matters, our class on load balancing traffic walks through the layer-4-versus-layer-7 split with Azure examples. It is the foundation this whole question sits on.

The SKU and the policy — the part people miss

This is where deployments go wrong, so it deserves its own section. Application Gateway ships in two v2 SKUs:

• Standard_v2 — the load balancer, no WAF. Routing, SSL, autoscaling. Nothing inspects requests for attacks.
• WAF_v2 — the same load balancer plus the WAF engine. This is the SKU that can enforce a firewall policy.

But choosing WAF_v2 is only half of it. The rules that do the blocking live in a separate object called a WAF policy — a managed rule set (for example the OWASP core rule set, which covers SQL injection, cross-site scripting, and the rest of the common attack classes) plus any custom rules you add. You create that policy and associate it with the gateway, a listener, or an individual route. The SKU is the engine; the policy is the ammunition. You need both.

And there is one more switch that catches everyone. A WAF policy runs in one of two modes:

• Detection — it watches, logs what it would have blocked, and lets everything through. Useful for tuning. Blocks nothing.
• Prevention — it blocks matching requests. This is the mode that protects you.

New WAF policies commonly start in Detection so you can see what would break before you turn on enforcement. That is sensible. The problem is how often nobody ever flips it to Prevention. The WAF is deployed, the dashboard is green, everyone moves on — and the thing has been in read-only mode the whole time.

Is Azure Front Door a WAF?

Same answer, different altitude: no, Front Door is a load balancer that can have a WAF. The difference from Application Gateway is where it lives. Application Gateway is regional — it sits inside one Azure region, usually inside your virtual network. Front Door is global — it runs at Microsoft's edge locations worldwide, catches users close to them, and forwards to your nearest healthy backend. It also does CDN caching.

Because Front Door terminates HTTP at the edge, it can run a WAF there too, in front of everything, before traffic ever reaches your region. You attach a Front Door WAF policy (on the Premium tier, or Standard with a smaller rule set) to the profile. Many larger setups run both WAFs — one at the Front Door edge for the internet-facing perimeter, one on Application Gateway inside the region for defence in depth. If you're weighing the two, Front Door versus Application Gateway goes through when each one fits.

Is Azure Firewall a WAF?

No, and this is the one worth being crisp about because they sound the most alike. Azure Firewall is a network firewall. Its job is controlling traffic between networks — which subnet can reach which destination, on which port, to which FQDN. It is what you put in a hub network to control what your workloads are allowed to call out to. It thinks in IP addresses, ports, and protocols.

A WAF thinks in HTTP requests. It reads the body and headers of an individual web request and decides whether that request looks like an attack on your application — a SQL injection string in a form field, a script tag smuggled into a query parameter. That is a completely different inspection at a completely different layer. Azure Firewall does not do it, and it is not supposed to.

They are not competitors; they are teammates. A typical production design runs Azure Firewall for network-level egress control and a WAF on Application Gateway or Front Door for inbound web protection. If you want the full side-by-side, Azure Firewall versus a WAF lays out exactly which threats each one stops, and NSG versus Azure Firewall covers the layer below that.

So which do you need?

Strip away the naming and it comes down to what you are protecting:

• A public web app, regional? Application Gateway on the WAF_v2 SKU, policy attached, Prevention mode. That is your load balancer and your web firewall in one resource.
• A public web app, global audience or multi-region? Front Door with a WAF policy at the edge, often with Application Gateway behind it.
• Controlling what your workloads can talk to across the network? Azure Firewall. That is a network-egress problem, not a web-request problem.
• Just spreading raw TCP traffic across backends, no HTTP smarts needed? The layer-4 Load Balancer. No WAF, because there is no HTTP for one to read.

Most real architectures use several of these together, each doing its own job. The mistake is not picking the wrong one — it's assuming the name on the box tells you what's switched on inside it. It doesn't. You have to go look.

Common questions