Azure Application Gateway and WAF

Azure Application Gateway is a fully managed layer 7 (application layer) load balancer that routes HTTP/S traffic to backend web servers. Unlike a layer 4 load balancer (like Azure Load Balancer) that only sees IP addresses and ports, Application Gateway understands the content of HTTP requests — URLs, headers, cookies, and even the body. This allows intelligent routing based on the request path, hostname, or query string.

Business problem: Modern web applications often consist of multiple microservices or pages served from different backend pools. For example, /images might be served from a VM running an image server, /api from a containerized API, and /checkout from a high-availability cluster. Without a layer 7 load balancer, you'd need to expose each backend separately or use a reverse proxy that you manage yourself. Application Gateway centralizes this routing and offloads SSL/TLS termination, cookie-based session affinity, and web application firewall (WAF) protection — all as a managed service.

Components: - Frontend IP: Public or private (internal) IP address. - Listeners: Rules that match incoming traffic by protocol, port, hostname, and IP address. - Routing Rules: Bind listeners to backend pools and HTTP settings. - Backend Pools: Targets (VMs, VMSS, App Service, etc.) with optional health probes. - HTTP Settings: Protocol, port, cookie affinity, timeout, connection draining. - WAF Policy: Managed rule sets, custom rules, bot protection, and policy mode (Detection or Prevention). - SSL Certificates: For TLS termination or end-to-end TLS.

Tiers: - Standard v2: Autoscaling, zone-redundant, supports static IP, SSL offload, URL-based routing, and cookie affinity. No WAF. - WAF v2: Includes all Standard v2 features plus a fully integrated WAF with OWASP CRS 3.x. It has two modes: Detection (log only) and Prevention (block and log). - Basic (v1): Older tier, limited to manual scaling, no autoscaling, no zone redundancy. Not recommended for new deployments.

Pricing: Pay-as-you-go based on gateway capacity units (compute + throughput + number of rules) and data processed. WAF v2 adds a fixed monthly fee plus per-rule costs for custom rules. Autoscaling means you only pay for what you use, but there's a minimum hourly cost.

On-premises, you might use an F5 BIG-IP, NGINX Plus, or HAProxy for layer 7 routing and WAF. These require hardware procurement, software licensing, manual configuration, and ongoing maintenance (patching, scaling). Azure Application Gateway is fully managed: Microsoft handles patching, scaling, and high availability. The trade-off is less customization — you can't install custom modules or tweak kernel parameters. But for most cloud-native apps, the managed service is faster to deploy and more cost-effective.

Portal: - Navigate to 'Create a resource' > 'Networking' > 'Application Gateway'. - Fill in basics: subscription, resource group, name, region, tier (Standard v2 or WAF v2), autoscaling min/max instances, and virtual network. - Configure frontend IP: public, private, or both. - Add backend pool: targets can be VMs, VMSS, IP addresses, or App Services. - Create routing rule: define listener (port, hostname), backend pool, HTTP settings, and optionally WAF policy. - Review and create.

CLI Example (creating a simple WAF v2 gateway):

az network application-gateway create \
  --name myAppGateway \
  --resource-group myResourceGroup \
  --location eastus \
  --capacity 2 \
  --sku WAF_v2 \
  --http-settings-cookie-based-affinity Enabled \
  --public-ip-address myPublicIP \
  --vnet-name myVNet \
  --subnet mySubnet \
  --servers 10.0.1.4 10.0.1.5 \
  --waf-policy myWAFPolicy

PowerShell:

New-AzApplicationGateway -Name "myAppGateway" `
  -ResourceGroupName "myResourceGroup" `
  -Location "East US" `
  -Sku @{Name="WAF_v2";Tier="WAF_v2";Capacity=2} `
  -GatewayIPConfigurations $gipconfig `
  -FrontendIPConfigurations $fipconfig `
  -FrontendPorts $frontendPort `
  -BackendAddressPools $pool `
  -BackendHttpSettingsCollection $poolSetting `
  -HttpListeners $listener `
  -RequestRoutingRules $rule `
  -WebApplicationFirewallConfiguration $wafConfig

Scenario 1: E-commerce Platform with Microservices

A large online retailer deploys its application as microservices: a user service, product catalog, order service, and payment service, each running in separate Azure VM Scale Sets. They need a single public endpoint that routes /users to the user service, /products to the catalog, /orders to the order service, and /payments to the payment service. They also need to protect against SQL injection and cross-site scripting attacks. The team deploys a WAF v2 Application Gateway with four backend pools. They configure path-based routing rules and enable the OWASP 3.2 rule set in Prevention mode. Cost is based on gateway capacity units; with autoscaling, they pay for the traffic they handle. During a flash sale, traffic spikes; the gateway automatically scales out to handle 10,000 requests per second. Without the gateway, they would have needed to manage a custom reverse proxy and WAF, increasing operational overhead. If incorrectly configured (e.g., wrong path patterns), users might see 404 errors or traffic could be sent to the wrong service, causing checkout failures.

Scenario 2: Internal HR Application with SSL Offload

A multinational company runs an internal HR portal on a set of VMs in Azure. The app uses HTTPS with a certificate from an internal CA. The app team wants to offload SSL decryption to the gateway so backend VMs don't waste CPU on encryption. They deploy a Standard v2 Application Gateway with a private frontend IP. They upload the internal certificate to the gateway and configure HTTPS listener. Backend HTTP settings use HTTP on port 80, since SSL is terminated at the gateway. The gateway also enables cookie-based session affinity so users stay on the same backend during their session. If the team mistakenly uses the wrong certificate or forgets to update it before expiry, users will see certificate errors. The gateway's health probe checks the /health endpoint every 30 seconds; if a backend VM is down, traffic is redirected to healthy ones, ensuring high availability.

Scenario 3: Multi-Tenant SaaS with Hostname Routing

A SaaS provider hosts different customers on separate backend pools for isolation. Each customer has a unique hostname (e.g., acme.contoso.com, beta.contoso.com). They deploy a WAF v2 gateway with multiple listeners, each listening on port 443 with a different hostname. Each listener routes to a dedicated backend pool. The WAF policy is customized per customer: for a financial services customer, they add custom rules to block non-US IPs. The gateway also provides TLS termination, so each customer can bring their own certificate. If a hostname is misconfigured, traffic might go to the wrong tenant, causing data leakage. The solution scales automatically as new customers are added — just create a new listener and backend pool.