Azure Application Gateway Overview
Most load balancers just split traffic — they do not look at what the traffic contains. Azure Application Gateway is different. It reads the HTTP request, inspects URLs and hostnames, terminates SSL, and can block web attacks before they reach your application. It is the right tool when you need intelligent routing and security for web traffic.
What layer 7 load balancing means
A standard load balancer works at layer 4 of the OSI model. It sees IP addresses and ports. It knows that a packet came from 203.0.113.10 on port 55000 and is going to port 443. That is all it knows.
Application Gateway works at layer 7. It decrypts HTTPS traffic (SSL termination), reads the actual HTTP request, and makes routing decisions based on:
- URL path: /api/* routes to one backend pool, /images/* routes to another.
- Hostname: app1.example.com routes to pool A, app2.example.com routes to pool B.
- HTTP headers and cookies: Session affinity based on a cookie keeps a user on the same backend.
This makes Application Gateway ideal for running multiple applications behind a single endpoint, or for routing API traffic separately from static content.
Core components
Listener: Accepts incoming connections. You define the protocol (HTTP or HTTPS), port, and optionally the hostname. A multi-site listener accepts connections for a specific hostname.
Backend pool: A set of backend targets — VMs, VM scale sets, IP addresses, FQDNs, or App Service instances.
HTTP settings: Defines how Application Gateway connects to backends — port, protocol, cookie-based affinity, connection draining timeout, and health probe settings.
Request routing rule: Links a listener to a backend pool through HTTP settings. Can be Basic (all traffic to one pool) or Path-based (routes to different pools based on URL path).
Health probe: Periodic checks against backend targets. Unhealthy backends are removed from rotation.
WAF policy: Optional Web Application Firewall rules that inspect and block malicious requests (OWASP rule sets, custom rules).
SKUs and tiers
| Feature | Standard v2 | WAF v2 |
|---|---|---|
| Layer 7 routing | Yes | Yes |
| SSL termination | Yes | Yes |
| Autoscaling | Yes | Yes |
| Zone redundancy | Yes | Yes |
| Web Application Firewall | No | Yes |
| OWASP rule sets | No | Yes |
| Best for | Internal or trusted traffic | Public-facing applications |
Always use v2 SKUs. The v1 SKUs are deprecated and will be retired. For any internet-facing application, use WAF v2.
Deploying Application Gateway with the CLI
Application Gateway requires its own subnet. Create it first:
# Create the Application Gateway subnet (minimum /26, recommended /24)
az network vnet subnet create \
--name snet-appgw \
--resource-group rg-prod-networking \
--vnet-name vnet-prod-eastus-001 \
--address-prefixes 10.0.0.0/24
# Create a public IP for the Application Gateway
az network public-ip create \
--name pip-appgw-prod \
--resource-group rg-prod-networking \
--location eastus \
--sku Standard \
--allocation-method Static \
--zone 1 2 3Create a WAF v2 Application Gateway with autoscaling:
az network application-gateway create \
--name agw-prod-eastus \
--resource-group rg-prod-compute \
--location eastus \
--sku WAF_v2 \
--capacity 2 \
--vnet-name vnet-prod-eastus-001 \
--subnet snet-appgw \
--public-ip-address pip-appgw-prod \
--frontend-port 443 \
--http-settings-port 80 \
--http-settings-protocol Http \
--routing-rule-type Basic \
--priority 1000 \
--servers 10.0.2.10 10.0.2.11Enable autoscaling so Application Gateway scales with demand:
az network application-gateway update \
--name agw-prod-eastus \
--resource-group rg-prod-compute \
--set autoscaleConfiguration='{"minCapacity": 1, "maxCapacity": 10}'Add a path-based routing rule to send /api/* to a different backend pool:
# Create the API backend pool
az network application-gateway address-pool create \
--gateway-name agw-prod-eastus \
--resource-group rg-prod-compute \
--name be-api-servers \
--servers 10.0.2.20 10.0.2.21
# Create the URL path map
az network application-gateway url-path-map create \
--gateway-name agw-prod-eastus \
--resource-group rg-prod-compute \
--name urlmap-main \
--paths /api/* \
--address-pool be-api-servers \
--http-settings appGatewayBackendHttpSettings \
--default-address-pool appGatewayBackendPool \
--default-http-settings appGatewayBackendHttpSettingsWAF policies
The WAF component runs OWASP Core Rule Set rules that block common attacks: SQL injection, cross-site scripting, remote code execution, and more. You configure it through WAF policies that can be attached to an Application Gateway or individual listeners.
# Create a WAF policy in Prevention mode
az network application-gateway waf-policy create \
--name waf-policy-prod \
--resource-group rg-prod-compute \
--location eastus
# Set the policy to Prevention mode (Detection mode only logs, does not block)
az network application-gateway waf-policy policy-setting update \
--policy-name waf-policy-prod \
--resource-group rg-prod-compute \
--mode Prevention \
--state Enabled \
--request-body-check true \
--max-request-body-size-kb 128Start the WAF in Detection mode. It will log but not block suspicious requests. Review the logs for 1-2 weeks to identify any legitimate traffic that triggers rules, then add exclusions before switching to Prevention mode. Jumping straight to Prevention can block real users.
Common mistakes
- Using too small a subnet. Each Application Gateway instance consumes IPs from its subnet. With autoscaling up to 10 instances and Azure’s 5 reserved addresses, a /28 (11 usable IPs) will run out quickly. Use /24 for the Application Gateway subnet.
- Enabling WAF Prevention mode immediately. The OWASP rule set will trigger on some legitimate requests depending on your application. Always start in Detection mode, review logs, add exclusions for false positives, then switch to Prevention. Skipping Detection mode causes unexpected user-facing blocks.
- Not configuring connection draining. When you remove a backend VM from the pool or update HTTP settings, in-flight requests get dropped without connection draining. Enable it with a drain timeout of 30-60 seconds so active connections finish before the VM is removed.
Summary
- Application Gateway is a layer 7 load balancer that routes traffic based on URLs, hostnames, and HTTP headers — not just IP and port.
- It supports SSL termination, URL path-based routing, multi-site hosting, and optional WAF protection.
- Always use v2 SKUs (Standard v2 or WAF v2). v1 is deprecated.
- For internet-facing apps, use WAF v2 starting in Detection mode, then switch to Prevention after tuning exclusions.
- The Application Gateway subnet must be at least /26, but /24 is recommended to accommodate autoscaling.
Frequently asked questions
What is the difference between Azure Load Balancer and Application Gateway?
Azure Load Balancer operates at layer 4 (TCP/UDP) and distributes traffic based on IP and port. Application Gateway operates at layer 7 (HTTP/HTTPS) and makes routing decisions based on URLs, hostnames, headers, and cookies. Use Application Gateway when you need URL routing, SSL termination, or WAF protection.
Does Application Gateway replace an NSG?
No. Application Gateway is a load balancer and optional WAF. NSGs are firewall rules that control IP-level traffic. You should run both: Application Gateway to handle HTTP routing and WAF filtering, NSGs to restrict network access to your subnets.
What is the minimum subnet size for Application Gateway?
The Application Gateway subnet must be at least /26 (64 addresses). Microsoft recommends /24 or larger to accommodate scaling. The Application Gateway consumes IPs from this subnet for each instance, and autoscaling requires room to grow.