Lab 03: Application Gateway WAF¶

Deploy a small WAF v2 Application Gateway in front of a test backend so you can understand subnet requirements, listener and probe behavior, and the validation steps used when applications are reachable internally but not through the gateway.

Lab Metadata¶

Prerequisites¶

• Permission to create Application Gateway, public IPs, VNets, and at least one backend VM.
• A lab resource group such as $RG=rg-net-lab03 and location such as $LOCATION=koreacentral.
• Basic familiarity with HTTP listeners and health probe semantics.
• Awareness that Application Gateway requires a dedicated subnet.

Architecture Diagram¶

mermaid flowchart TD Internet[Client] --> PublicIP[Public IP] PublicIP --> AppGw[Application Gateway WAF v2] AppGw --> Probe[Health Probe] AppGw --> Backend[Backend VM or App] Ops[Operator] --> Logs[Application Gateway logs and metrics]

Step-by-Step Instructions¶

Step 1: Create the VNet and dedicated subnets¶

az group create \
    --name $RG \
    --location $LOCATION

az network vnet create \
    --resource-group $RG \
    --name vnet-agw-lab03 \
    --location $LOCATION \
    --address-prefixes 10.130.0.0/16 \
    --subnet-name appgw \
    --subnet-prefixes 10.130.1.0/24

az network vnet subnet create \
    --resource-group $RG \
    --vnet-name vnet-agw-lab03 \
    --name backend \
    --address-prefixes 10.130.2.0/24

Keep Application Gateway isolated in its own subnet. That pattern matters in production and during troubleshooting.

Why this step matters¶

• Verify that the Application Gateway subnet is dedicated and that no backend workload is placed into it.
• Record the exact subnet prefixes because later backend-health or scaling issues are often rooted in bad subnet layout.
• Save the VNet output now so you can prove the gateway started from a supported topology.

Step 2: Deploy the backend and public IP¶

az vm create \
    --resource-group $RG \
    --name vm-web03 \
    --image Ubuntu2204 \
    --size Standard_B1s \
    --vnet-name vnet-agw-lab03 \
    --subnet backend \
    --admin-username azureuser \
    --generate-ssh-keys \
    --public-ip-address ""

az network public-ip create \
    --resource-group $RG \
    --name pip-agw03 \
    --sku Standard \
    --allocation-method Static

Install a simple web server on the backend or adapt to a prebuilt image with an HTTP listener.

Why this step matters¶

• Confirm that the backend VM lands in the backend subnet and that the gateway public IP is Standard and Static.
• Capture the backend private IP because the gateway creation step depends on the right target address.
• If the backend host is wrong here, later probe failures may look like WAF or listener problems when they are not.

Step 3: Create a WAF policy and Application Gateway¶

az network application-gateway waf-policy create \
    --resource-group $RG \
    --name wafp-lab03 \
    --location $LOCATION

az network application-gateway create \
    --resource-group $RG \
    --name agw-lab03 \
    --location $LOCATION \
    --capacity 1 \
    --sku WAF_v2 \
    --public-ip-address pip-agw03 \
    --vnet-name vnet-agw-lab03 \
    --subnet appgw \
    --servers 10.130.2.4 \
    --frontend-port 80 \
    --http-settings-port 80 \
    --http-settings-protocol Http \
    --priority 100

If your backend IP differs, replace the server address with the backend NIC private IP.

Why this step matters¶

• Wait for the gateway deployment to finish and record the frontend configuration and backend target you used.
• Save the gateway creation output because it becomes the control-plane baseline for every later health and WAF check.
• If you had to substitute a different backend IP, note that now so probe evidence remains interpretable.

Step 4: Attach a custom health probe and inspect backend health¶

az network application-gateway probe create \
    --resource-group $RG \
    --gateway-name agw-lab03 \
    --name probe-web03 \
    --protocol Http \
    --host 127.0.0.1 \
    --path / \
    --interval 30 \
    --timeout 30 \
    --threshold 3

az network application-gateway show-backend-health \
    --resource-group $RG \
    --name agw-lab03

Backend health is the single most useful command during ingress incidents.

Why this step matters¶

• Confirm that backend health turns Healthy with the intended probe configuration before you enable any failure drill.
• Save the backend-health output because it shows the exact transition from configuration to runtime evidence.
• If the pool is unhealthy here, fix the backend listener or probe path before continuing to diagnostics.

Step 5: Enable diagnostics and review WAF/Application Gateway state¶

az monitor diagnostic-settings create \
    --name send-agw-logs \
    --resource $(az network application-gateway show --resource-group $RG --name agw-lab03 --query id --output tsv) \
    --workspace $WORKSPACE_ID \
    --logs '[{"category":"ApplicationGatewayAccessLog","enabled":true},{"category":"ApplicationGatewayFirewallLog","enabled":true},{"category":"ApplicationGatewayPerformanceLog","enabled":true}]'

az monitor metrics list \
    --resource $(az network application-gateway show --resource-group $RG --name agw-lab03 --query id --output tsv) \
    --metric HealthyHostCount,UnhealthyHostCount \
    --interval PT5M

This step shows how to connect control-plane configuration with runtime evidence.

Why this step matters¶

• Verify that diagnostics start flowing to the workspace and that gateway health metrics return values.
• Capture one metric snapshot so you can compare healthy and unhealthy states after the probe failure drill.
• This is the evidence bridge between control-plane settings and what operators actually monitor during ingress incidents.

Step 6: Practice a probe failure and recovery¶

az network application-gateway probe update \
    --resource-group $RG \
    --gateway-name agw-lab03 \
    --name probe-web03 \
    --path /broken

az network application-gateway show-backend-health \
    --resource-group $RG \
    --name agw-lab03

az network application-gateway probe update \
    --resource-group $RG \
    --gateway-name agw-lab03 \
    --name probe-web03 \
    --path /

This reproduces one of the most common Application Gateway incidents in a safe way.

Why this step matters¶

• Save the backend-health output before and after changing the probe path so the failure transition is explicit.
• Compare the unhealthy state with the earlier healthy metric snapshot to distinguish backend issues from listener or WAF issues.
• Restoring the probe path should give you a clear pre-fix and post-fix evidence pair for future troubleshooting notes.

Validation Steps¶

• [ ] Application Gateway deploys successfully in its dedicated subnet.
• [ ] Backend health shows Healthy for the backend after the correct probe path is restored.
• [ ] HealthyHostCount increases and UnhealthyHostCount drops in metrics.
• [ ] The lab notes capture the difference between a gateway issue and a backend-probe issue.

Cleanup Instructions¶

az group delete --name $RG --yes --no-wait

Before cleanup, record any private IPs, route table names, or diagnostic screenshots you want to reuse in troubleshooting notes.

See Also¶

• Load Balancing Options
• Nsg And Firewall Best Practices
• Load Balancer Health Probe Failures
• Inbound Connectivity Issues

Sources¶

• overview-v2
• application-gateway-probe-overview
• ag-overview