Azure Application Gateway: Layer 7 routing, WAF, TLS, probes, and service selection
Master listeners, routing rules, backend settings and pools, URL and host routing, cookie affinity, health probes, TLS termination, end-to-end TLS, WAF, autoscaling, connection draining, and the right Azure traffic service.
Suggested study time: 70 minutes • Intermediate • Original rewrite based on the supplied Microsoft Learn module and corrected against current Application Gateway documentation
By João Ricardo Dutra••Complete original content
1. Replace an aging web gateway with an Azure-managed service
Adatum runs an expanding industrial-drone store. Its web applications still live on servers in the on-premises datacenter, and an aging perimeter appliance controls incoming traffic. The networking team wants Azure to mediate that traffic without losing the appliance’s availability, performance, affinity, or security behavior.
The replacement must remove unavailable servers from rotation, terminate TLS to reduce backend CPU work, keep a customer session on the same backend when local state requires it, and reject attacks such as SQL injection and cross-site scripting before they reach the application.
Explain what does and identify its core components.
Trace HTTP(S) requests through listeners, rules, backend settings, and pools.
Configure URL-path and host-based routing, affinity, probes, and graceful maintenance.
Compare TLS termination with end-to-end TLS and explain WAF inspection.
Choose or another Azure traffic service for a workload.
You should already understand basic networking, Azure virtual machines, , virtual networks, HTTP, and TLS.
combines a client endpoint, an application-aware decision, backend connectivity, and continuous health evaluation.
2. is a terminating proxy for application traffic
accepts client connections and opens separate connections to selected backend targets. For HTTP and HTTPS, it can read application-layer attributes such as the host header and URL path, then route requests more precisely than an IP-and-port load balancer.
Backend pools may contain virtual machines, instances, applications, private IP addresses, FQDNs, or on-premises servers reachable through the virtual network. The service can distribute traffic, inspect it with WAF, terminate TLS, re-encrypt it to backends, scale capacity, drain connections, and preserve session affinity.
3. Layer 7 routing differs from Layer 4 flow distribution
Choose the processing layer that matches the requirement.
Capability
Azure
Primary model
Terminating proxy with application-aware routing
Pass-through flow distributor
Typical protocols
HTTP, HTTPS, HTTP/2, WebSocket; v2 also supports TCP/TLS proxy listeners
TCP and UDP
Decision inputs
Host, path, listener, headers, and configured rules
IP addresses, ports, protocol, and flow hash
Security
Optional WAF for HTTP(S)
No web payload inspection
Scope
Regional application delivery
Regional or cross-region transport distribution
The supplied module describes as Layer 7, which remains its central AZ-104 role. Current v2 gateways can also proxy TCP and TLS, but WAF does not inspect those non-HTTP listeners.
4. The request path is frontend, listener, WAF, rule, setting, and pool
DNS first resolves the application hostname to a gateway frontend IP. A matching listener accepts the connection. When WAF is enabled for HTTP(S), the request is evaluated against the policy. A request-routing rule then selects a backend pool and backend setting, and the gateway creates a new connection to a healthy pool member.
A rule does not work alone: it binds the client-side listener to both a destination pool and connection behavior.
5. Frontend IP configurations define how clients reach the gateway
A frontend can be public, private, or both so internet and internal clients can use different entry points. The older one-public-plus-one-private statement in the PDF is no longer complete: current listener documentation supports as many as four frontend configurations—public and private for IPv4 and IPv6—subject to SKU and feature availability.
Each listener references one frontend IP and port. Standard_v2 uses static virtual IPs and can be zone redundant. A private-only deployment keeps the gateway entirely inside the virtual network.
6. Listeners recognize the connection that should be accepted
An HTTP(S) listener is defined by frontend IP, port, protocol, and optionally one or more host names. HTTPS listeners also reference a certificate for the client-facing TLS connection. A basic listener catches matching traffic without a specific host, while a multi-site listener uses the HTTP Host header or TLS SNI to distinguish sites on the same gateway.
When multiple listeners could match, v2 routing-rule priority determines evaluation order. Put a specific hostname ahead of a wildcard so a broad pattern does not capture the request first.
7. Rules and backend settings control where and how traffic travels
A basic request-routing rule maps a listener to one backend pool. A path-based rule adds a URL path map whose patterns can select different pools and settings. Each v2 rule has a unique priority, where a lower number is evaluated first.
The backend setting controls the second connection: HTTP or HTTPS, destination port, request timeout, host-name behavior, cookie-based affinity, connection draining, and the health probe. It is therefore the link between routing intent and protocol behavior toward the server.
Client-side TLS belongs to the listener; backend-side protocol and certificate validation belong to the backend setting.
8. Backend pools collect reachable and consistently configured targets
A pool is a logical destination set. Members can be VM NICs or scale-set instances, IP addresses, or FQDNs—including reachable on-premises servers. All members serving one application should expose compatible ports, content, session handling, and security settings.
For an FQDN member, the gateway resolves DNS and caches the answer for that record’s TTL. Backend membership says where targets are; the associated backend setting says how to connect to them. works best with its custom domain preserved, and trusted Azure services normally do not require a manually uploaded trusted root certificate.
9. Round-robin distribution and cookie affinity solve different needs
Among healthy targets in the selected pool, distributes new work with round-robin behavior. Cookie-based affinity adds a gateway cookie so later requests from the same user session return to the same backend. This is useful when session state exists only on one server, as in the Adatum scenario.
Affinity does not repair application state design. It can create uneven utilization and a failed backend still loses its local session. Prefer stateless applications or an external session store when practical, and enable affinity only when the workload requires it.
10. Health probes keep failed endpoints out of new requests
periodically probes every backend member and stops routing new requests to an endpoint marked unhealthy. Monitoring continues, so a recovered endpoint automatically returns to service.
Default and custom probes.
Probe
Behavior
Use
Default
HTTP(S) GET using the backend setting port, every 30 seconds; status 200–399 is healthy
Simple endpoints that respond correctly at the default host and root path
Applications with a dedicated health endpoint, host requirement, or stricter success criteria
The PDF’s phrase “waits 30 seconds before deciding” oversimplifies the process. On v2, the interval and consecutive-failure threshold together determine when a backend becomes unhealthy. Test application dependencies in a lightweight health path instead of proving only that the VM is running.
Health probes handle failure; connection draining handles intentional removal.
11. Path-based routing sends different URL areas to specialized pools
A URL path map can send `/video/*` to media-streaming servers, `/images/*` to image servers, and unmatched requests to a default pool. Patterns are evaluated only after the listener and path-based rule match.
This lets one hostname expose several independently scaled application areas. Order and specificity matter: broad patterns should not unintentionally shadow narrower paths.
Path-based routing makes the URL structure part of the load-balancing decision.
12. Multi-site routing hosts many domains on one gateway
Several DNS names can resolve to the same frontend IP. Separate multi-site listeners recognize `contoso.com`, `fabrikam.com`, or wildcard names and their rules route each site to its own pool. This pattern is useful for multitenant platforms and shared ingress infrastructure.
Current can host more than 100 sites and allows multiple or wildcard hostnames per listener within documented limits. For HTTPS, certificates and SNI must cover the names presented by clients.
Host-based routing isolates sites while reusing the gateway and its frontend.
13. Redirects, rewrites, and custom errors shape the HTTP exchange
Redirect the client to another URL or force HTTP to HTTPS. The browser receives a redirect and makes a new request.
Rewrite a request URL, query string, or supported request/response header inside the gateway. The browser does not see a URL rewrite.
Inject security headers or remove response headers that expose backend details.
Return branded custom error pages for gateway-generated failures instead of the platform default.
Header and URL rewrite are v2 features. Rewrite, redirect, and custom-error behavior have interaction limits, so attach each rule set to the intended basic rule, default path, or specific path and validate it with access logs.
14. TLS termination offloads cryptography from backend servers
With TLS termination, the client establishes HTTPS to the listener. The gateway presents the listener certificate, decrypts the request, applies routing and WAF logic, and can forward HTTP to the backend. Central certificate management and reduced backend encryption work are the main benefits.
Only the gateway is directly exposed on the listener ports—commonly 80 and 443—while backend servers remain private. This reduces direct internet exposure, but unencrypted backend traffic is acceptable only when the trust boundary and security requirements permit it.
15. End-to-end TLS creates two separately validated encrypted sessions
For sensitive or compliance-bound traffic, set the backend protocol to HTTPS. terminates the client session for Layer 7 processing, then creates a new TLS session and re-encrypts the request with the backend certificate’s public key.
A v2 gateway validates certificate trust, validity, and whether the backend hostname matches the certificate identity. Publicly trusted and trusted Azure backends such as are simpler; private certificate authorities require the appropriate trusted root certificate configuration. HTTPS probes must also succeed.
End-to-end does not pass one TLS session through; the gateway decrypts, processes, and re-encrypts.
16. WAF inspects HTTP traffic before it reaches the application
The optional policy evaluates HTTP headers, body, and other request attributes against managed and custom rules. It helps block SQL injection, cross-site scripting, command or remote-code injection, HTTP request smuggling, HTTP response splitting, remote file inclusion, protocol violations and anomalies, scanners, bots, crawlers, and other common web attacks.
The PDF lists old OWASP CRS versions and calls CRS 3.1 the default. Current WAF uses Azure-managed Default Rule Sets: DRS 2.2 is the newest release and is based on OWASP CRS 3.3.4 plus Microsoft Threat Intelligence protections. Rules, actions, exclusions, file-upload limits, and inspected request limits can be tuned carefully to reduce false positives without opening broad gaps.
WAF operating modes.
Mode
Result
Detection
Logs matched threats for validation and tuning but does not block them.
Prevention
Logs and blocks requests whose evaluated action requires blocking.
Security inspection and service scope are separate design decisions.
17. Autoscaling and connection draining protect capacity and maintenance
Standard_v2 and WAF_v2 can autoscale between configured minimum and maximum capacity as traffic changes. Zone redundancy can spread instances across availability zones. Keep a sensible minimum capacity to reduce cold-start impact and validate subnet capacity for scale-out.
Connection draining stops new requests to a deregistering or updating backend while allowing active connections to finish within the configured timeout. Use it for planned updates; use probes for unexpected failure. v1 retired on April 28, 2026, so production designs and rewrites should use v2.
18. WebSocket and HTTP/2 support long-lived, interactive traffic
natively supports WebSocket and HTTP/2 on conventional web ports. WebSocket upgrades an HTTP connection to long-lived, full-duplex communication without polling. HTTP/2 multiplexes exchanges efficiently over fewer TCP connections. These protocols still depend on listener, timeout, health, and backend compatibility.
19. The Adatum design maps each requirement to one feature
From business requirement to configuration.
Requirement
design
Retire the perimeter appliance
Public or private v2 frontend connected through the hybrid network to an on-premises backend pool.
Stop using failed servers
Custom health probe that validates the actual application endpoint.
Reduce cryptographic CPU
HTTPS listener with TLS termination; optionally HTTPS again to the backend for end-to-end protection.
Keep local session state
Cookie-based affinity, while planning a longer-term shared session store.
Block SQL injection and XSS
WAF_v2 policy in prevention mode after detection-mode tuning.
Perform maintenance safely
Connection draining plus probe-aware deployment steps.
The backend can remain on-premises if private connectivity and name resolution let the gateway reach it. Monitoring, diagnostic logs, certificates, WAF tuning, NSGs, DNS, capacity, and failure testing complete the production design.
20. Choose the Azure traffic service by layer, scope, and protocol
Traffic-service decision guide.
Service
Scope and layer
Choose it when
Regional terminating proxy; mainly Layer 7
You need regional HTTP(S) routing, TLS termination, host/path decisions, or WAF before private backends.
Global application delivery network; Layer 7
You need edge acceleration, caching, global failover, global web routing, and optional WAF.
Azure Traffic Manager
Global DNS-based direction
You need DNS endpoint selection and can accept resolver caching and TTL-dependent failover.
Azure
Regional or cross-region Layer 4
You need high-performance TCP/UDP flow distribution without HTTP inspection.
Do not deploy for one lightly used server merely to add complexity, or when the requirement is purely UDP, DNS steering, or global edge caching. Services can be combined—for example, Front Door globally and regionally.
21. Assessment answers, compact review, and official resources
Assessment answers.
Question
Answer
Why
What protects a web app from SQL injection?
It inspects HTTP requests against managed and custom attack rules.
What stops traffic to an unresponsive VM?
Health probe
The endpoint is removed from new routing decisions until it recovers.
What stops new connections but lets active work finish?
Connection draining
It gracefully removes a backend during planned maintenance.
