Azure Application Gateway: Layer 7 Load Balancing, TLS Termination, and WAF

Azure Application Gateway is a Layer 7 (application-layer) load balancer for web traffic. It's also a regional resource: a gateway is deployed into a dedicated subnet of a single virtual network in one Azure region, and doesn't on its own span regions the way Azure Front Door or Traffic Manager do. Because it operates at the application layer, it can inspect HTTP/HTTPS requests and make routing decisions based on their content — the host name, the URL path, headers, and cookies — rather than only on IP addresses and ports. That awareness is what unlocks its headline features: TLS termination, URL-based routing, multi-site hosting, and an integrated web application firewall (WAF). This note walks through how those pieces fit together, from the components that make up a gateway to how it terminates TLS and screens traffic for attacks.

When Application Gateway is the right fit

Because Application Gateway understands application-level protocols like HTTP and HTTPS, it's the right tool when routing has to depend on the content of the request rather than just the transport-layer flow. The table below frames a few concrete scenarios around a fictional company, Adatum:

Capability	What it does
Hybrid backend routing	Directs traffic from an endpoint in Azure to a backend pool of servers running in Adatum's on-premises datacentre. Health probes ensure traffic isn't directed to any server that becomes unavailable.
TLS termination	Reduces the CPU capacity that servers in the backend pool allocate to encryption and decryption operations by offloading that work to the gateway.
Web application firewall	Blocks cross-site scripting and SQL injection traffic before it reaches servers in the backend pool.
Session affinity	Keeps a user pinned to the same backend server. Adatum needs this because several of its web applications store user session state locally on individual servers.

Session affinity is worth a caveat from a design point of view: pinning users to a specific server works, but it undermines even load distribution and means a server failure loses that user's session. Where you can, externalising session state (for example to Azure Cache for Redis) is the more resilient design, and affinity becomes a fallback rather than the mechanism you rely on.

Layer 4 vs Layer 7 load balancing

Layer 4 load balancing operates at the transport layer of the OSI model, making decisions based on IP addresses and ports. It's fast and efficient but lacks application awareness. Layer 7 load balancing operates at the application layer, understanding HTTP headers, cookies, and other application-specific data. This allows for more intelligent routing decisions based on content. For example, requests for /images can be directed to an image backend pool and requests for /videos to a video backend pool — the core of Layer 7 routing.

For the Layer 4 counterpart in Azure — Azure Load Balancer, public vs internal load balancers, and session persistence — see the companion note Load Balancers.

Components of an Application Gateway

Application Gateway has a series of components that combine to securely route and load balance requests across a pool of web servers.

Front-end IP address

Client requests are received through a front-end IP address. You can configure Application Gateway with a public IP address, a private IP address, or both — but no more than one of each. An internet-facing gateway uses a public IP whose DNS name is publicly resolvable; an internal-only gateway uses just a private IP and can route requests only from clients with access to its virtual network.

Listeners

Application Gateway uses one or more listeners to receive incoming requests. A listener accepts traffic arriving on a specified combination of protocol, port, host, and IP address, and also handles the TLS/SSL certificate securing the connection between the user and the gateway.

Listeners come in two types. A basic listener accepts every request arriving on its IP address and port and hands them all to a single routing rule — it's used when the gateway serves a single site. A multi-site listener distinguishes requests by their host header, so one gateway can serve many domains, each routed to its own backend pool. Note that this is a different distinction from how a rule routes: whether traffic is sent straight to one pool or split by URL path is a property of the routing rule (basic vs path-based), not of the listener type.

Routing rules and HTTP settings

A routing rule binds a listener to one or more backend pools. It specifies how to interpret the host name and path in a request's URL and directs the request to the appropriate pool. Each rule carries an associated set of HTTP settings (also called backend settings) that indicate whether — and how — traffic is encrypted between the gateway and the backend servers, along with the protocol, session stickiness, connection draining, request timeout, and health probes.

When a rule selects a backend pool with multiple healthy servers, the gateway distributes requests across them using a round-robin algorithm, with health probes continuously determining which servers are eligible. Before forwarding a request, the gateway also inserts a set of X-Forwarded-* headers — including x-forwarded-for, x-forwarded-proto, and x-original-host — so the backend can still see the original client details that TLS termination would otherwise hide.

Request routing: path-based and multi-site

There are two primary methods of routing client request traffic: path-based routing and multi-site routing.

Path-based routing sends requests with different URL paths to different pools of backend servers. For example, you could direct requests with the path /video/* to a pool of servers optimised for video streaming, and /images/* requests to a pool that handles image retrieval.

Multi-site routing configures more than one web application on the same Application Gateway instance. You register multiple DNS names (CNAMEs) for the gateway's IP address, one per site, and the gateway uses a separate listener per site. Each listener passes requests to a different rule, which routes them to a different backend pool — so all requests for http://contoso.com go to one pool and requests for http://fabrikam.com go to another. This is useful for multi-tenant applications where each tenant has its own set of resources.

A single gateway can host more than 100 websites this way. Multi-site listeners also support wildcard host names (for example *.contoso.com) and up to five host names per listener, so a small number of listeners can cover many subdomains. One limit worth remembering: when the web application firewall is enabled, a single gateway can host up to 40 WAF-protected websites rather than 100.

TLS/SSL termination and end-to-end TLS

TLS termination (also called SSL offloading; TLS is the modern name for what used to be called SSL) is the process of decrypting encrypted traffic at a network endpoint — such as a load balancer or reverse proxy — before it reaches the backend web servers. The primary purpose is to offload the computationally intensive task of encryption and decryption from the backend servers, freeing them to focus on running applications and serving content.

How TLS termination works

Client connection: a user's browser initiates an HTTPS connection, sending encrypted traffic to the gateway.
Termination point processing: the gateway holds the TLS/SSL certificate and private key. The certificate is added to the listener and must be in PFX format (containing both the private and public keys).
Traffic decryption: the gateway performs the TLS handshake and decrypts the incoming traffic, converting it to plain HTTP.
Backend communication: the decrypted traffic is forwarded to the backend web servers over the internal network.
Response processing: backend servers return a plain HTTP response, which the gateway re-encrypts with TLS before sending the final encrypted response back to the client.

Benefits

Terminating TLS at the gateway delivers several benefits:

Improved performance. Offloading the CPU-intensive encryption and decryption lets backend servers handle more concurrent connections and focus on application logic. The gateway also caches TLS session information, so repeat requests from the same client avoid a fresh handshake — something that's hard to achieve if decryption happens on the backend and requests land on different servers.
Centralised certificate management. Certificates and their private keys are installed and managed only on the gateway rather than on every backend server, simplifying administration, updates, and renewals.
Enhanced security inspection. Decrypting at the gateway lets security devices like the WAF inspect the traffic for malicious content before it reaches the application servers. This is also what makes intelligent, content-based routing possible.

Security considerations and end-to-end TLS

TLS termination introduces one trade-off: the traffic between the gateway and the backend servers is unencrypted. That internal segment must be treated as a trusted environment and secured with appropriate network segmentation and access controls.

For environments that require encryption all the way to the backend — handling sensitive personal or health data, for example — Azure supports end-to-end TLS encryption (the general industry term for this is SSL bridging). The gateway still terminates the client's TLS session and decrypts the request so it can apply its routing rules and WAF, then opens a new TLS connection and re-encrypts the traffic using the backend server's certificate before forwarding it. You enable this by setting the backend HTTP settings protocol to HTTPS. On the Standard_v2 SKU the backend connection is negotiated with TLS 1.3, falling back to TLS 1.2.

One current requirement to be aware of: since 31 August 2025, all clients and backend servers interacting with Application Gateway must use TLS 1.2 or higher — support for TLS 1.0 and 1.1 has ended.

Web Application Firewall (WAF)

The most direct way to protect web servers at the network edge from common threats like SQL injection is to deploy an Azure Web Application Firewall (WAF). The WAF sits in front of your web servers and inspects incoming HTTP/HTTPS traffic, using managed rule sets based on the OWASP Core Rule Set (CRS) to identify and block malicious requests — including SQL injection and cross-site scripting patterns — before they reach the application. On the newer WAF engine the current managed rule set is CRS 3.2.

There are two main places to deploy it:

Application Gateway WAF — ideal when your web servers sit inside a virtual network, or when you need application-level load balancing and centralised WAF management alongside the firewall. As a regional resource, it protects backends within a single Azure region.

Azure Front Door WAF — best for global deployments needing low latency, content delivery network (CDN) capabilities, and protection at the Azure network edge, closer to the user.

A WAF runs in one of two modes. Detection mode monitors and logs threats without blocking anything; Prevention mode actively blocks detected attacks, returning a 403 to the attacker and closing the connection. The recommended approach is to run a newly deployed WAF in Detection mode first to surface false positives and tune exclusions, then switch to Prevention mode. Under the hood, CRS 3.x defaults to anomaly scoring: rather than any single rule match blocking a request outright, each matched rule adds to a score, and the request is blocked once the score crosses the threshold.

Scaling and availability

Autoscaling, zone redundancy, and a static VIP are all features of the Standard_v2 SKU. The v2 gateway scales in and out automatically with changing traffic load, which also removes the need to choose a deployment size or instance count during provisioning. It can span multiple availability zones for fault resilience, and it keeps a static public IP for the lifetime of the gateway. (The older v1 SKU, with its fixed Small/Medium/Large sizes, has since been retired.)

Connection draining complements this: it allows graceful removal of backend pool members during planned service updates, rolling deployments, and scale-in events, letting in-flight requests finish while no new requests are sent to a draining instance — which reduces the intermittent 502 errors that would otherwise occur when a backend is pulled from the pool.