Azure Application Gateway is a load balancer and Web Application Firewall (WAF). It operates at Layer-7 of the OSI model, which means it works only with web traffic. It supports the following protocols: HTTP, HTTPS, WebSockets, and HTTP/2.
Application Gateway has multiple different SKUs. This includes the original SKUs, as well as the newer v2 SKUs. While the original SKUs are still fully supported, Microsoft “strongly recommends” that you move to the v2 SKUs. The original SKUs will be fully retired in April 2026.
Within the v2 SKUs there are 2 options. You have the Standard v2, or the WAF v2 which adds on Web Application Firewall features.
Some notes about this blog post:
This is Part 1 of the series and will focus on everything on the left side of the diagram, or everything in the "Accepting Requests" section
This post is going to focus solely on the v2 SKUs
To save time and space, from here on I will be referring to Application Gateway as AppGW.
Application Gateway Networking
AppGW must be installed into a Subnet inside one of your Azure Virtual Networks. This Subnet is dedicated to AppGW and can only contain AppGW resources. If you want, you can put multiple AppGWs into the same Subnet, but they must all be the same version. In other words, the Subnet cannot contain a mix of AppGW v1 and AppGW v2.
Since AppGW lives inside one of your Azure Subnets, it can communicate with any backend resources that your Virtual Network has access to. So, if the Virtual Network has any Peerings, VPN Gateways, or ExpressRoute connections, then your AppGW can leverage those to privately communicate to backend resources.
How big should this Subnet be? Well, let’s try to calculate the maximum amount of IP addresses that could be used. A single AppGW v2 can scale up to a maximum of 125 instances, each taking up an IP address, for a total of 125 IP addresses. Plus, Azure automatically reserves 5 IP addresses in every Subnet. Lastly, if you decide to assign a Private IP to your AppGW, then that’s 1 more IP address needed. This comes to a total of 131 IP Addresses. That means a /25 subnet (128 addresses), or smaller, might not be enough. Microsoft recommends that you use a /24 subnet (256 addresses). In my opinion, a /24 may be overkill, but it will all come down to your individual needs. Don’t forget that you can put multiple AppGWs in the same subnet, so keep that in mind too.
Application Gateway Components
Frontend IP Addresses
Frontend IP Addresses are attached to the frontend of AppGW. When clients talk to AppGW, they are talking to it over one of these frontend IP addresses. AppGW v2 must always have a Public IP Address. Optionally, you can also add a Private IP Address, which is taken from the Azure Subnet that AppGW is installed into. Only 1 of each is supported per AppGW. That means the supported scenarios are either Public IP only, or Public IP + Private IP. The scenario of Private IP only is not supported.
Update: fully private deployments of AppGW v2 (with no Public IP) are now supported in Private Preview.
Listeners
A Listener defines how AppGW listens for incoming connection requests from clients. A Listener is a logical entity that defines four things: IP Address, Port, Protocol, and Hostname. When AppGW receives a connection request, it will look at these four things, and will try to match it to an associated Listener. When the request is matched to a Listener, then AppGW processes it via the Routing Rule that is attached to the Listener. Each Listener is attached to one, and only one, Routing Rule. More on Routing Rules in a later article, back to Listeners for now.
Let’s briefly discuss the 4 things that a Listener looks for:
IP Address: this can be either the AppGW’s Public IP Address, or the AppGW’s Private IP Address
Protocol: supported options are HTTP, HTTPS, WebSockets, or HTTP/2
Port: For AppGW v2, this can be from 1 to 65199
Hostname: this can be set to all hostnames, specific hostnames (example.com), or hostnames that match a wildcard pattern (like *.org)
An AppGW can have multiple different Listeners configured. However, there are a couple things to watch out for:
A single port number cannot be shared by both a Private Listener and a Public Listener. For example, a single AppGW cannot be listening for port 443 on its Public IP and Private IP at the same time. To support this scenario, you would have to create 2 separate AppGWs.
Update: using the same port for both Private & Public Listeners is now generally available.
Now, if you stay within the same category (either Private Listeners or Public Listeners) you can have multiple Listeners share the same port. However, the Listeners sharing the same port must have unique Hostnames. For Example, you could do the following:
Private Listener, Port 80, Hostname: www.mywebsite.com
Private Listener, Port 80, Hostname: www.example.com
Basic Listener vs. Multi-Site Listener
There are two types of Listeners, and they differ in the options that are available for the Hostname setting. The first type of Listener is a “Basic” Listener. A Basic Listener doesn’t even let you set a Hostname, as it accepts ALL Hostnames. The second type of Listener is a “Multi-site” Listener, and a Multi-Site Listener comes in 2 flavors. First, there is a Multi-Site “Single” Listener. As the name suggests, you can only specify one Hostname and you are not allowed to use wildcards. Secondly, there is the Multi-Site “Multiple” Listener. This lets you specify anywhere from 1 to 5 different Hostnames, and wildcards are allowed.
Listener Priority
What happens when an incoming request matches multiple Listeners, which Listener is picked in that case? With v2 AppGW, the first thing to know is that Multi-Site Listeners are processed first, and then Basic Listeners are processed second. Okay, then what happens if you have 2 Multi-Site Listeners that match the request? Well, in that case, it’s important to know that the Routing Rules that are attached to each Listener are given a unique Priority value. The Listener whose Routing Rule has the highest Priority wins.
Error Pages
Listeners let you configure error pages. You can configure custom URLs to use for the following types of errors:
403 Forbidden
502 Bad Gateway
Update: more types of custom error pages are now generally available. This includes 400, 405, 408, 500, 503, and 504, as well as the original 403 and 502.
TLS Certificates
Listeners can be configured to use HTTPS which means you must configure the Listener with a TLS Certificate. AppGW supports certificates in the Personal Information Exchange (PFX) format. PFX certificates contain both the public and private key. You can either upload a certificate directly to AppGW, or you can pick an existing certificate that you have stored in Azure KeyVault.
SSL Policy
SSL Policy is used to define which TLS protocol versions are supported, which cipher suites are supported, and the order in which ciphers are used during a TLS handshake. AppGW provides a handful of predefined policies for you to pick from, or you can create your own custom one.
You can configure SSL Policy at two different levels, either globally at the AppGW level, or per-site at the Listener level. If an SSL Policy is applied at both levels, then the Listener’s SSL Policy will take precedence.
Web Application Firewall (WAF) Policy
It’s important to know that there are two different ways to configure WAF settings for your AppGW, either WAF Config or WAF Policy. WAF Config is the old way and is no longer recommended. WAF Config is when you configure the WAF settings directly on the AppGW resource. Nowadays, when you create a brand new AppGW WAF resource in the portal you are not even given this option, you are forced to use the new method which is WAF Policy. WAF Policy is created as a separate resource which contains all of your WAF Settings. The WAF Policy is then associated to your AppGW at one of three different levels: Application Gateway (Global), Listener (per-site), or a Path-based Rule (per-URI). More specific policies override less specific ones.
WAF Policies contain all of your WAF settings and configurations. There are a lot of settings you could configure in a WAF Policy and there is no way I could go over them in this one article, but I will cover some high-level topics. WAF Policies can operate in one of two modes, either Detection or Prevention. In Detection mode, WAF will not block any requests, but anything that matches a rule will be logged into the WAF logs. In Prevention mode any traffic that matches a rule will be blocked. For settings, you can specify which OWASP ruleset you want to apply, as well as configure settings such as max request body size and max file upload size, create your own custom rules, and make custom exclusions.
Wrapping Up
Well that should cover everything related to how Application Gateway accepts requests. The next article in this series will cover how requests are routed and redirected by Application Gateway. Stay tuned.