Module 08 — Azure WAF on Application Gateway¶

What Is Application Gateway?¶

Azure Application Gateway is a reverse proxy that sits between clients and your backend servers. It operates at Layer 7 (HTTP/HTTPS) and provides:

• Load balancing — distributes incoming requests across a pool of backend targets using round-robin, least-connections, or cookie-based affinity.
• SSL/TLS termination — offloads encryption so backends can serve plain HTTP, reducing compute overhead.
• URL-based routing — routes requests to different backend pools based on the URL path (e.g., /images/* → media pool, /api/* → API pool).
• Multi-site hosting — hosts multiple domains on a single gateway by matching the Host header.
• WebSocket and HTTP/2 support — full protocol support for modern applications.
• Web Application Firewall — the WAF_v2 SKU adds the Azure WAF engine inline, inspecting every request before it reaches the backend.

Application Gateway v2 Architecture¶

The diagram below shows the end-to-end request flow through an Application Gateway with WAF enabled.

flowchart LR
    Internet([Internet / Clients]) --> PIP[Public IP\nor Private IP]
    PIP --> FE[Frontend\nListener]
    FE --> WAF[WAF Engine\nDRS 2.1 + Bot Manager\n+ Custom Rules]
    WAF -->|Pass| RR[Routing Rules\nURL path-based\nor basic]
    WAF -->|Block| BLOCK[403 Forbidden\nCustom Error Page]
    RR --> BP1[Backend Pool 1\nVMs / VMSS]
    RR --> BP2[Backend Pool 2\nApp Service]
    RR --> BP3[Backend Pool 3\nAKS / On-prem]

Component breakdown¶

SKU Comparison¶

Application Gateway is available in two v2 SKUs. Only the WAF_v2 SKU includes the WAF engine.

Feature	Standard_v2	WAF_v2
Layer-7 load balancing
SSL/TLS termination
URL-based routing
Multi-site hosting
Autoscaling
Zone redundancy
WebSocket & HTTP/2
Private Link
WAF engine
Managed rules (DRS 2.1)
Bot Manager
Custom rules
Rate limiting
Pricing model	Fixed + capacity units	Fixed + capacity units (higher base)

WAF Integration¶

When you associate a WAF policy with an Application Gateway, the WAF engine is injected into the request pipeline between the listener and the routing rules. Every inbound request is inspected before it can reach a backend server.

Policy association scopes¶

WAF policies can be attached at three levels, from broadest to most specific:

A more specific policy overrides a broader one. For example, a per-path policy on /api/* takes precedence over the global policy for requests matching that path.

flowchart TD
    REQ[Incoming Request] --> L{Listener match}
    L --> PP{Path-rule\npolicy exists?}
    PP -- Yes --> PR[Use per-path policy]
    PP -- No --> LP{Listener\npolicy exists?}
    LP -- Yes --> LR[Use per-listener policy]
    LP -- No --> GP[Use global policy]
    PR --> WAF[WAF Engine evaluates]
    LR --> WAF
    GP --> WAF

Key Features for WAF (2026)¶

The Application Gateway WAF platform has matured significantly. Here is a summary of the features available as of 2026:

TLS Termination & End-to-End TLS¶

One of the most important roles of Application Gateway is TLS termination: the gateway decrypts incoming HTTPS traffic at the frontend, inspects it with the WAF engine, and then re-encrypts it (or forwards it as plain HTTP) to the backend.

Why TLS termination matters for WAF¶

The WAF engine can only inspect decrypted traffic. Without TLS termination, the request payload is an opaque encrypted stream and the WAF cannot evaluate it against managed or custom rules. Application Gateway handles this transparently: it terminates TLS at the listener, feeds the plaintext request through the WAF engine, and then optionally re-encrypts it for the backend connection.

Client ──HTTPS──▶ App Gateway ──HTTP──▶ Backend
                   (TLS terminated,
                    WAF inspects
                    plaintext)

Client ──HTTPS──▶ App Gateway ──HTTPS──▶ Backend
                   (TLS terminated,        (new TLS session)
                    WAF inspects
                    plaintext,
                    re-encrypts)

Security Headers via Header Rewrite¶

Application Gateway's rewrite rules let you inject, modify, or remove HTTP headers on both request and response paths. This is a powerful complement to WAF rules: while the WAF blocks malicious input, rewrite rules ensure the response includes the security headers that modern browsers expect.

Example — Add HSTS and remove server information¶

# Define rewrite actions
$hsts = New-AzApplicationGatewayRewriteRuleHeaderConfiguration `
  -HeaderName "Strict-Transport-Security" `
  -HeaderValue "max-age=31536000; includeSubDomains"

$removeServer = New-AzApplicationGatewayRewriteRuleHeaderConfiguration `
  -HeaderName "Server"

$actionSet = New-AzApplicationGatewayRewriteRuleActionSet `
  -ResponseHeaderConfiguration $hsts `
  -ResponseHeaderConfiguration $removeServer

$rule = New-AzApplicationGatewayRewriteRule `
  -Name "AddSecurityHeaders" `
  -ActionSet $actionSet

$rewriteSet = New-AzApplicationGatewayRewriteRuleSet `
  -Name "SecurityHeaders" `
  -RewriteRule $rule

Health Probes¶

Application Gateway uses health probes to monitor the availability of backend servers. If a backend fails health checks, the gateway removes it from rotation until it recovers.

Default vs. custom probes¶

Deployment Considerations¶

Subnet requirements¶

Application Gateway v2 requires a dedicated subnet with no other resources. The subnet size determines the maximum number of gateway instances:

Network Security Group (NSG) rules¶

The gateway subnet requires specific inbound rules:

Autoscaling and capacity units¶

Application Gateway v2 supports autoscaling between a minimum and maximum number of capacity units. Each capacity unit provides approximately:

• 2 500 persistent connections
• 2 500 new connections per second
• 2.22 Mbps throughput

Set a minimum instance count of 2 for production to ensure high availability during scale-in events.

Availability zones¶

Deploy across multiple availability zones (e.g., zones 1, 2, 3) for regional resilience. Zone-redundant deployment survives the failure of an entire data centre within the region.

When to Use Application Gateway WAF¶

Application Gateway WAF is the right choice when your requirements include:

Deploying Application Gateway with WAF — Complete CLI Example¶

The following script creates a resource group, virtual network, WAF policy, and Application Gateway WAF_v2 from scratch.

# Variables
RG="rg-waf-workshop"
LOCATION="eastus2"
VNET="vnet-waf"
SUBNET_AG="snet-appgw"
SUBNET_BE="snet-backend"
POLICY="waf-policy-appgw"
APPGW="appgw-waf-workshop"
PIP="pip-appgw"

# 1. Resource group
az group create --name $RG --location $LOCATION

# 2. Virtual network with two subnets
az network vnet create \
  --resource-group $RG \
  --name $VNET \
  --address-prefix 10.0.0.0/16

az network vnet subnet create \
  --resource-group $RG \
  --vnet-name $VNET \
  --name $SUBNET_AG \
  --address-prefix 10.0.1.0/24

az network vnet subnet create \
  --resource-group $RG \
  --vnet-name $VNET \
  --name $SUBNET_BE \
  --address-prefix 10.0.2.0/24

# 3. Public IP
az network public-ip create \
  --resource-group $RG \
  --name $PIP \
  --sku Standard \
  --allocation-method Static \
  --zone 1 2 3

# 4. WAF policy with DRS 2.1
az network application-gateway waf-policy create \
  --resource-group $RG \
  --name $POLICY

az network application-gateway waf-policy managed-rule rule-set add \
  --resource-group $RG \
  --policy-name $POLICY \
  --type Microsoft_DefaultRuleSet \
  --version 2.1

az network application-gateway waf-policy managed-rule rule-set add \
  --resource-group $RG \
  --policy-name $POLICY \
  --type Microsoft_BotManagerRuleSet \
  --version 1.1

az network application-gateway waf-policy policy-setting update \
  --resource-group $RG \
  --policy-name $POLICY \
  --state Enabled \
  --mode Prevention

# 5. Application Gateway WAF_v2
az network application-gateway create \
  --resource-group $RG \
  --name $APPGW \
  --location $LOCATION \
  --sku WAF_v2 \
  --capacity 2 \
  --vnet-name $VNET \
  --subnet $SUBNET_AG \
  --public-ip-address $PIP \
  --http-settings-port 80 \
  --http-settings-protocol Http \
  --frontend-port 80 \
  --routing-rule-type Basic \
  --servers 10.0.2.4 10.0.2.5 \
  --waf-policy $POLICY \
  --zones 1 2 3 \
  --priority 100

Related Labs¶

• LAB01 — Deploy Application Gateway WAF
• LAB02 — Detection Mode
• LAB05 — Prevention Mode

Key Takeaways¶

1. Application Gateway is a regional Layer-7 load balancer with built-in WAF when deployed with the WAF_v2 SKU.
2. The WAF engine sits inline between the listener and the routing rules, inspecting every decrypted request.
3. WAF policies can be scoped globally, per-listener, or per-path for multi-tenant and multi-app scenarios.
4. TLS termination is essential — the WAF can only inspect plaintext traffic. Use end-to-end TLS for encryption in transit to backends.
5. Header rewrite rules complement WAF by injecting security response headers (HSTS, CSP, X-Frame-Options).
6. Deploy into a dedicated subnet (at least /26) with proper NSG rules and enable zone redundancy for production.
7. Use Application Gateway WAF for regional, private, or multi-site workloads. Pair with Front Door for global coverage.

References¶

• Azure Application Gateway documentation — Microsoft Learn
• Application Gateway WAF overview — Microsoft Learn
• WAF policy per-site configuration — Microsoft Learn
• Application Gateway v2 autoscaling — Microsoft Learn
• TLS termination and end-to-end TLS — Microsoft Learn
• Rewrite HTTP headers — Microsoft Learn
• az network application-gateway — CLI Reference