This chapter covers Azure Application Gateway and Web Application Firewall (WAF), two critical components for securing and load-balancing HTTP/HTTPS traffic to web applications. For the AZ-104 exam, understanding Application Gateway's layer-7 capabilities, WAF rule sets, and how they differ from Azure Load Balancer and Traffic Manager is essential. Approximately 10-15% of exam questions on the Networking domain will involve selecting or configuring Application Gateway for scenarios involving SSL termination, path-based routing, or WAF policies. This chapter provides the deep technical knowledge needed to answer those questions confidently.
Jump to a section
Imagine a large international airport with multiple terminals. Each terminal has dozens of gates (backend servers) that handle specific flights (applications). Passengers (HTTP requests) arrive at the airport's main entrance. Instead of letting passengers wander freely to any gate, which would create chaos and security risks, the airport uses a centralized security checkpoint (Application Gateway). At this checkpoint, a security officer (the gateway's routing engine) checks each passenger's boarding pass (URL path) and directs them to the correct terminal and gate. Additionally, before entering, all passengers go through a metal detector and bag scanner (WAF) that inspects for prohibited items (SQL injection, XSS, etc.). The security checkpoint can also perform SSL termination: passengers present their passports (HTTPS) to the officer, who verifies them and then communicates internally with the gates using a simpler ID card (HTTP). The checkpoint also maintains a log of all passengers (access logs) and can rate-limit (throttle) if too many passengers arrive at once. If a particular gate is overwhelmed, the officer can distribute passengers evenly among multiple identical gates (load balancing). Critically, the checkpoint itself is a single point of entry, so it must be highly available — the airport has a backup checkpoint in another building (redundant gateway in another region) that takes over if the primary fails.
What is Azure Application Gateway?
Azure Application Gateway is a fully managed Layer 7 (HTTP/HTTPS) load balancer. Unlike Azure Load Balancer which operates at Layer 4 (TCP/UDP), Application Gateway can make routing decisions based on HTTP attributes like URL path, host header, or query string. It supports features like SSL termination, cookie-based session affinity, URL path-based routing, and WebSocket support. It is designed for web applications that need intelligent traffic distribution, security, and high availability.
Why Use Application Gateway?
Application Gateway solves several problems:
- SSL Termination: Offloads SSL/TLS decryption from backend servers, reducing CPU load.
- Path-Based Routing: Routes requests to different backend pools based on the URL path (e.g., /images/* goes to pool A, /api/* goes to pool B).
- Multi-Site Hosting: Host multiple websites on the same gateway using different host headers.
- Session Affinity: Ensures a client's requests are sent to the same backend server using cookie-based affinity (Gateway-managed cookie).
- WAF Integration: Protects against common web exploits.
How It Works Internally
Application Gateway runs as a scalable, highly available service in Azure. When you create an Application Gateway, it is deployed in a specific virtual network (VNet) and subnet. The gateway listens on frontend IP addresses (public, private, or both) for incoming traffic. Each incoming HTTP/HTTPS request goes through the following steps:
Listener: The gateway's frontend IP and port combination (e.g., 10.0.0.4:443) is defined as a listener. The listener specifies the protocol (HTTP/HTTPS) and optionally the host name for multi-site routing.
Rule: A rule binds the listener to a backend pool and defines how to route traffic. Rules can be basic (all traffic to one pool) or path-based (different paths to different pools).
Backend Pool: A logical group of backend servers (VMs, VMSS, App Service, or IP addresses). The gateway forwards traffic to these servers based on the rule.
Health Probes: The gateway periodically sends health probes to backend servers. Only healthy servers receive traffic. The probe interval defaults to 30 seconds, and the unhealthy threshold is 3 consecutive failures (default). Custom probes can specify paths, intervals, and thresholds.
SSL Termination: If the listener uses HTTPS, the gateway decrypts the traffic using a configured SSL certificate. It then forwards the request to the backend over HTTP (or HTTPS if end-to-end SSL is required).
WAF Inspection: If WAF is enabled, the request passes through WAF rules before routing. If a rule matches, the request can be blocked, logged, or allowed (depending on policy mode: Prevention or Detection).
Key Components and Defaults
SKU: Standard_v2 or WAF_v2. v2 supports autoscaling and zone redundancy. WAF_v2 includes all WAF features.
Capacity Units: v2 SKU uses capacity units (CU) for billing. Each CU can handle 10 new connections/sec, 2,500 persistent connections, or 2.22 Mbps throughput.
Request Timeout: Default is 20 seconds for the backend request timeout. Configurable up to 24 hours for streaming scenarios.
Session Affinity: Uses a gateway-managed cookie named ApplicationGatewayAffinity. The cookie is set by the gateway, not the backend.
Path-Based Rules: Can use URL path maps with wildcards (*) at the end of a path (e.g., /images/*).
Health Probe Defaults: Interval 30s, timeout 30s, unhealthy threshold 3, healthy threshold 1.
SSL Certificates: Must be uploaded to the gateway for HTTPS listeners. For end-to-end SSL, backend certificates must also be trusted.
WAF Modes: Detection (log only) and Prevention (block and log).
OWASP Rule Sets: WAF uses OWASP Core Rule Set (CRS) 3.2 by default. Can be customized with exclusions.
Configuration and Verification Commands
Using Azure CLI:
# Create a subnet for the gateway
ez network vnet subnet create -g MyRG --vnet-name MyVNet -n GatewaySubnet --address-prefixes 10.0.1.0/24
# Create a public IP
ez network public-ip create -g MyRG -n MyPublicIP --sku Standard --zone 1 2 3
# Create the Application Gateway (v2 SKU)
ez network application-gateway create -g MyRG -n MyAppGateway --sku WAF_v2 --public-ip-address MyPublicIP --vnet-name MyVNet --subnet GatewaySubnet --servers 10.0.2.4 10.0.2.5
# Add a path-based rule
ez network application-gateway url-path-map create -g MyRG --gateway-name MyAppGateway -n myPathMap --paths /images/* --pool-name ImagesPool --rule-name myRule
# Enable WAF (if not already)
ez network application-gateway waf-config set -g MyRG --gateway-name MyAppGateway --enabled true --mode Prevention
# View health of backend pools
ez network application-gateway show-backend-health -g MyRG -n MyAppGatewayUsing PowerShell:
New-AzApplicationGateway -Name MyAppGateway -ResourceGroupName MyRG -Location eastus -Sku WAF_v2 -GatewayIPConfigurations $gipconfig -FrontendIPConfigurations $fipconfig -FrontendPorts $fport -HttpListeners $listener -BackendAddressPools $pool -BackendHttpSettingsCollection $setting -RequestRoutingRules $rule -WebApplicationFirewallConfiguration $wafconfigInteraction with Related Technologies
Azure DNS: Application Gateway can be associated with a custom domain via CNAME or A record (using public IP). For Azure Front Door, you can use Application Gateway as an origin.
Azure Firewall: For network-level security, Azure Firewall sits in front of Application Gateway or in a hub VNet. Application Gateway handles web traffic, Azure Firewall handles non-web traffic.
Traffic Manager: Can be used for global load balancing across multiple Application Gateways in different regions. Traffic Manager uses DNS-based routing, while Application Gateway does local load balancing.
Azure Load Balancer: Application Gateway provides layer-7 features; Load Balancer provides layer-4. They can be chained (LB -> App Gateway) but typically you choose one based on need.
Virtual Machine Scale Sets: Backend pools often consist of VMSS for autoscaling. Application Gateway can distribute traffic to VMSS instances.
App Service: Application Gateway can route traffic to App Service apps, including support for App Service's IP restrictions and custom domains.
Limits and Scalability
Maximum number of Application Gateways per subscription: 50 (standard) or 25 (WAF) per region.
Maximum frontend ports: 10 (v1) or 100 (v2).
Maximum backend pools: 100 (v2).
Maximum listeners: 100 (v2).
Maximum URL path maps: 100 (v2).
Maximum HTTP settings: 100 (v2).
Autoscaling: v2 SKU can scale from 0 to 125 capacity units based on load.
Zone redundancy: v2 SKU can be deployed across multiple availability zones for high availability.
WAF Details
WAF on Application Gateway protects against:
SQL injection
Cross-site scripting (XSS)
HTTP request smuggling
Bot attacks (via Bot Manager rule set)
Common web attacks (OWASP top 10)
WAF policies can be associated at the gateway level, listener level, or path-based rule level. Custom rules allow you to block or allow traffic based on IP addresses, geo-location, request size, or string patterns. The default rule set is OWASP 3.2, which includes over 100 rules. You can enable/disable individual rules and set actions (allow/block/log).
WAF logs are sent to Azure Monitor, Log Analytics, or Storage. The gateway also supports diagnostic logs for performance, access, and firewall logs.
SSL/TLS Configuration
Minimum TLS version: 1.0, 1.1, or 1.2 (default 1.0). For compliance, set to 1.2.
Supported cipher suites: Defined by the gateway's SSL policy. Predefined policies: AppGwSslPolicy20150501, AppGwSslPolicy20170401S, AppGwSslPolicy20220101S. Custom policies allow selection of specific ciphers.
End-to-end SSL: Requires backend servers to have certificates trusted by the gateway. The gateway re-encrypts traffic to the backend.
SSL profiles: Used for end-to-end SSL to define trusted root certificates and client certificate authentication.
Troubleshooting
Common issues:
Backend health shows unhealthy: Check NSG rules allowing traffic from gateway subnet to backend, ensure health probe path returns 200, check backend server is running.
Connection timeout: Default timeout is 20 seconds. For long-running requests, increase timeout in HTTP settings.
WAF blocking legitimate traffic: Switch to Detection mode to identify false positives, then create exclusions or disable specific rules.
Session affinity not working: Ensure backend server does not set its own cookies that override the gateway cookie. The gateway cookie name is ApplicationGatewayAffinity.
Define Frontend IP Configuration
First, you must specify how the gateway is reachable from clients. This involves creating a frontend IP configuration that can be either public (using a public IP address) or private (using an IP from the VNet subnet). For internet-facing applications, you typically use a public IP. The frontend IP is associated with one or more listeners. The public IP must be Standard SKU for v2 gateways to support zone redundancy. You can also have both public and private frontend IPs on the same gateway, allowing internal and external access.
Create Listeners
A listener defines the protocol (HTTP or HTTPS), port, and optionally host name for incoming traffic. For HTTPS, you must upload an SSL certificate. Listeners can be basic (single site) or multi-site (based on host header). Multi-site listeners allow hosting multiple domains on the same gateway. Each listener is bound to a frontend IP configuration. The listener also specifies whether to use WAF (if enabled). The gateway can have up to 100 listeners (v2 SKU).
Configure Backend Pools
Backend pools contain the target servers that will receive traffic. They can be composed of specific IP addresses (IPv4), FQDNs, or references to Azure resources like VMSS, App Service, or AKS. For v2 SKU, you can have up to 100 backend pools. Each pool can have multiple targets. The gateway distributes traffic among healthy servers in the pool using a round-robin algorithm (or weighted if using weighted round-robin via custom settings).
Set Up Health Probes
Health probes monitor the availability of backend servers. By default, the gateway probes the root path (/) every 30 seconds. You can create custom probes with specific paths, intervals (default 30s), timeouts (default 30s), and unhealthy thresholds (default 3). If a server fails three consecutive probes, it is marked unhealthy and removed from rotation. The probe uses HTTP/HTTPS GET requests. For custom probes, the response must return a 200-399 status code to be considered healthy.
Define Routing Rules
Routing rules bind a listener to a backend pool and optionally a backend HTTP settings. Basic rules send all traffic from a listener to a single pool. Path-based rules use URL path maps to route traffic based on URL path patterns (e.g., `/images/*` to pool A, `/api/*` to pool B). Rules also define backend HTTP settings, which include protocol (HTTP/HTTPS), port, timeout, cookie-based affinity, and connection draining. Connection draining allows existing requests to complete before removing a backend from rotation.
Enable WAF (Optional)
If using WAF_v2 SKU, you can enable WAF at the gateway level or associate a WAF policy at the listener or path level. WAF policies define the mode (Detection or Prevention) and the rule sets (OWASP 3.2, Bot Manager, custom rules). In Prevention mode, malicious requests are blocked. In Detection mode, they are logged but allowed. You can also create exclusions to bypass specific rules for certain parameters. WAF logs are essential for tuning.
Enterprise Scenario 1: E-Commerce Platform with SSL Offloading and Path-Based Routing
A large e-commerce company runs its website on Azure VMs. The site has a public-facing storefront and a separate admin portal. They use Application Gateway with WAF_v2 to:
Terminate SSL (TLS 1.2) at the gateway, reducing CPU load on backend VMs.
Route all traffic to /store/* to a backend pool of web servers, and /admin/* to a separate pool with stricter access (via NSG and WAF rules).
Enable WAF in Prevention mode to block SQL injection and XSS attacks on the storefront.
Use cookie-based session affinity to keep users on the same server during their shopping session.
Deploy the gateway across three availability zones for high availability.
Scale and Performance: The gateway handles 10,000 requests per second. They use autoscaling with a minimum of 2 capacity units and maximum of 20. The backend consists of 10 VMSS instances per pool. They monitor backend health and WAF logs via Azure Monitor and set up alerts for high latency or blocked requests.
Misconfiguration Pitfall: Initially, they forgot to update the health probe path to /health instead of /, causing false unhealthy status because the root path returned a 404. They also had to add WAF exclusions for the /admin path because some admin features triggered false positives.
Enterprise Scenario 2: Multi-Tenant SaaS Application with Host-Header Routing
A SaaS provider hosts multiple customer applications on a shared infrastructure. They use a single Application Gateway to route traffic based on the host header (e.g., customer1.example.com, customer2.example.com). Each customer has a dedicated backend pool of AKS pods. The gateway:
Uses multi-site listeners for each customer domain.
Terminates SSL using a wildcard certificate *.example.com.
Enables WAF in Detection mode initially to tune rules per customer.
Uses path-based routing within each customer for API and static content.
Scale and Performance: The gateway handles 5,000 requests per second across 50 customers. They use custom health probes that check a specific API endpoint. They set up connection draining (30 seconds) to allow graceful removal of pods during updates.
Misconfiguration Pitfall: They initially used a single listener with a single host header, but that caused all traffic to go to one pool. They had to reconfigure to multi-site listeners. Also, they had to ensure that the backend AKS service uses the correct host header (via HTTP settings override) to avoid routing issues.
Enterprise Scenario 3: Internal Line-of-Business App with Private Frontend
A financial services company hosts an internal web application that should only be accessible from the corporate network. They deploy Application Gateway with a private frontend IP (10.0.0.4) in a VNet. The backend is a set of VMs in a different subnet. The gateway:
Uses a private IP only, no public endpoint.
Terminates SSL using an internal CA certificate.
Enables WAF in Prevention mode to protect against internal threats (e.g., compromised clients).
Uses path-based routing for different modules (finance, HR, IT).
Scale and Performance: The gateway handles 500 requests per second. It is sized with a fixed capacity of 2 CUs (no autoscaling needed). Backend health is monitored with a custom probe that checks a specific page.
Misconfiguration Pitfall: They initially forgot to add a route from the gateway subnet to the backend subnet via a UDR, causing health probes to fail. They also had to configure NSGs to allow traffic from the gateway subnet on port 443.
What AZ-104 Tests on Application Gateway and WAF
The AZ-104 exam objectives for this topic are under 'Configure and manage virtual networking' (4.2). Specifically, you should be able to:
Choose the appropriate load-balancing solution (Application Gateway vs. Load Balancer vs. Traffic Manager) based on requirements.
Configure Application Gateway components: listeners, rules, backend pools, health probes.
Enable and configure WAF (mode, rule sets, exclusions).
Implement SSL termination and end-to-end SSL.
Troubleshoot backend health and connectivity.
Common Wrong Answers and Why Candidates Choose Them
Choosing Azure Load Balancer when Application Gateway is needed: Candidates see 'load balancing' and pick Load Balancer, ignoring that the requirement mentions URL path routing or SSL termination. Remember: Application Gateway is Layer 7; Load Balancer is Layer 4.
Selecting Traffic Manager for regional load balancing within a single region: Traffic Manager is for global DNS-based load balancing across regions. For local load balancing, use Application Gateway or Load Balancer.
Enabling WAF on Standard_v2 SKU: WAF is only available on WAF_v2 SKU. Standard_v2 does not support WAF. Candidates may think WAF is a separate service that can be attached.
Setting health probe interval too low (e.g., 5 seconds): The minimum interval is 5 seconds, but candidates might think 1 second is possible. The default is 30 seconds.
Assuming session affinity requires backend configuration: The gateway manages session affinity via its own cookie. Backend servers do not need to do anything, but they must not override the gateway cookie.
Key Numbers and Terms That Appear on the Exam
SKUs: Standard_v2, WAF_v2 (v1 SKUs are legacy but may appear in older questions).
Capacity Units: 1 CU = 10 new connections/sec, 2,500 persistent connections, 2.22 Mbps throughput.
Default timeout: 20 seconds (backend request timeout).
Health probe defaults: Interval 30s, timeout 30s, unhealthy threshold 3.
WAF modes: Detection and Prevention.
OWASP CRS version: 3.2 (default).
Session affinity cookie name: ApplicationGatewayAffinity.
Maximum listeners: 100 (v2).
Zone redundancy: Only available with v2 SKU.
Connection draining: Up to 3600 seconds (1 hour) for v2.
Edge Cases and Exceptions
End-to-end SSL: Requires backend certificates to be trusted by the gateway. The gateway re-encrypts traffic; it does not forward the original client certificate unless configured.
WebSocket support: Application Gateway supports WebSocket natively for both HTTP and HTTPS listeners.
HTTP/2 support: Supported for incoming client connections (v2 SKU).
Custom error pages: Can be configured for WAF blocks or backend errors.
Rewriting HTTP headers: Supported via rewrite sets (v2 SKU).
Private link support: Application Gateway can be used with Private Link to expose services privately.
How to Eliminate Wrong Answers
If the scenario mentions 'URL path-based routing' or 'SSL offloading', eliminate Load Balancer and Traffic Manager.
If the scenario mentions 'global load balancing across regions', eliminate Application Gateway and Load Balancer.
If the scenario mentions 'protect against SQL injection', WAF is needed, so choose WAF_v2 SKU.
If the scenario mentions 'internal-only access', use private frontend IP.
If the scenario mentions 'cookie-based session affinity', Application Gateway is the correct choice (not Load Balancer).
Application Gateway is a Layer 7 load balancer with SSL termination, URL path routing, and WAF capabilities.
WAF is only available on the WAF_v2 SKU; Standard_v2 does not include WAF.
Default backend request timeout is 20 seconds; configurable up to 24 hours.
Health probe default interval is 30 seconds, unhealthy threshold is 3 consecutive failures.
Session affinity uses a gateway-managed cookie named 'ApplicationGatewayAffinity'.
Application Gateway v2 SKU supports autoscaling and zone redundancy.
WAF modes: Detection (log only) and Prevention (block and log).
OWASP Core Rule Set 3.2 is the default WAF rule set.
Maximum listeners per gateway: 100 (v2 SKU).
Connection draining can be set up to 3600 seconds (1 hour) for v2 SKU.
These come up on the exam all the time. Here's how to tell them apart.
Azure Application Gateway
Operates at Layer 7 (HTTP/HTTPS)
Supports URL path-based routing
Supports SSL termination and WAF
Uses cookie-based session affinity
Ideal for web applications with advanced routing needs
Azure Load Balancer
Operates at Layer 4 (TCP/UDP)
Distributes traffic based on source IP and port
No SSL termination or WAF capabilities
Supports source IP affinity (5-tuple hash)
Suitable for non-HTTP traffic and high-performance scenarios
Mistake
Application Gateway can only route traffic to Azure VMs.
Correct
Application Gateway can route traffic to any endpoint with an IP address or FQDN, including on-premises servers, other clouds, and Azure services like App Service and AKS.
Mistake
WAF can be enabled on any Application Gateway SKU.
Correct
WAF is only available on the WAF_v2 SKU. Standard_v2 does not include WAF capabilities. You must choose WAF_v2 when creating the gateway if you need WAF.
Mistake
Session affinity requires the backend server to set a cookie.
Correct
Session affinity is managed by the Application Gateway itself. It inserts a cookie named `ApplicationGatewayAffinity` into the client's response. The backend does not need to do anything, but it must not overwrite that cookie.
Mistake
Health probes always use the root path '/'.
Correct
By default, health probes use the root path, but you can configure custom probes with any path. The probe expects a 200-399 status code. Custom probes are essential for applications where the root path does not return a valid response.
Mistake
Application Gateway supports only HTTP/1.1.
Correct
Application Gateway v2 SKU supports HTTP/2 for incoming client connections. This can reduce latency and improve performance for modern web applications.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Application Gateway operates at Layer 7 (HTTP/HTTPS) and can route based on URL path, host header, and support SSL termination and WAF. Azure Load Balancer operates at Layer 4 (TCP/UDP) and distributes traffic based on source IP and port. Use Application Gateway for web applications; use Load Balancer for non-HTTP traffic or when you need ultra-low latency.
Yes, Azure also offers Azure Front Door WAF and Azure CDN WAF, but for regional web applications, Application Gateway WAF is the primary choice. Front Door WAF is for global scenarios.
Create an HTTPS listener and upload a valid SSL certificate (PFX or PEM) to the gateway. The gateway decrypts the traffic and forwards it to the backend over HTTP (or HTTPS if end-to-end SSL is configured). The certificate must be in the gateway's certificate store.
The default health probe sends an HTTP GET to '/' every 30 seconds with a 30-second timeout. If three consecutive probes fail, the backend is marked unhealthy. You can customize the path, interval, timeout, and thresholds.
Check that NSGs allow traffic from the gateway subnet to the backend on the health probe port. Ensure the health probe path returns a 200-399 status code. Verify the backend server is running. Use the 'show-backend-health' CLI command to see the status.
Yes, as long as the on-premises servers are reachable from the gateway's subnet via a VPN or ExpressRoute. Add the on-premises IP addresses to the backend pool.
Connection draining allows existing requests to complete before a backend server is taken out of rotation (e.g., during maintenance). You set a timeout (up to 3600 seconds for v2). During draining, new requests are not sent to that server, but existing connections remain until they finish or the timeout expires.
You've just covered Azure Application Gateway and WAF — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?