Azure Application Gateway is a Layer 7 load balancing service for HTTP/S and HTTP2 traffic.


Application Gateways have the following characteristics.

  • Application Gateway is a Regional service.
  • There are 2x versions (SKU's) available: v1 and v2.
  • Supports both Public and/or Private IP addressing for the Frontend.
  • Supports Virtual Machines (VMs), VM Scale Sets (VMSS), App Service, IP Address or FQDNs as Backend pool members.
  • Optionally, can be deployed with Web Application Firewall (WAF) functionality.
  • Can load balance across Availability Zones (AZs) within a Region.
  • Supports both Host and Path based routing.
  • Multi-Site hosting is supported. IE an App Gateway can be the Frontend for multiple different websites.
  • Supports both TLS termination and End-to-End TLS encryption.

v1 v2 Comparison

v2 App Gateways have the same features as v1 App Gateways with some additional functionality.


Parameter Description
HTTP/S/2 Support for HTTP, HTTPS and HTTP2 traffic.
URL path based routing Route to a backend pool based on a URL path such as /images/* or /videos/*.
Multi-site hosting Host multiple web application frontends on a single App Gateway.
Web Application Firewall (WAF) Pre-defined rules to protect web applications from common exploits and malicious attacks.
TLS termination and End-to-End encryption TLS traffic can be terminated on the frontend (Termination) and optionally continue through to the backend host (End-to-End). Note: App Gateway proxies the TLS connection and does not pass it directly through to the backend host.
Session affinity Utilizes a cookie for session stickyness to a Backend server for a flow.
Connection draining Allows for graceful removal of backend pool members.
Custom error pages Use custom error pages instead of displaying default error pages.
Websockets Enabled by default and cannot be disabled.
Static/Dynamic VIP frontend Static or Dynamic VIP address.
Public/Private VIP frontent Support either private and/or public addressing for the frontend


Parameter Description
v1 features With some differences.
Autoscaling Dynamically scale in/out to meet traffic demands.
Zone redundancy Can span multiple Availability Zones (AZs).
AKS Ingress Controller Can be used as an Ingress for Azure Kubernetes Service (AKS) clusters.
Azure Key Vault integration Can access TLS certificates stored in Azure Key Vault without having to load them on the App Gateway.
Rewrite HTTP headers URL Add, remove, or update HTTP request and response headers.
Rewrite URL Rewrite URLs, query string parameters and host name.
Web Application Firewall (WAF) Custom rules to protect web applications from common exploits and malicious attacks.
Static VIP frontend Static VIP address that does not change. Note: There is no option to have a dynmaic IP address.
Public/Private VIP frontent Private only frontend VIP is currently in preview.


Listeners determine which traffic is load balanced using the following parameters.

  • IP Addreess - X.X.X.X
  • Port number - 80/443
  • Protocol - HTTP/S/2
  • Host -

There are 2 types of Listeners: Basic and Multi-Site.


Basic listeners have the following characteristics.

  • Used for hosting a single website.
  • Single domain support.
  • Single DNS mapping to an IP address.


Multi-Site listeners have the following characteristics.

  • Used for hosting a single website.
  • Multiple domains/hostnames support.
  • Can host 100+ sites on a single App Gateway.
  • Limited to 5 hostnames per-listener.
TLS certificates are attached to listeners and use for TLS termination.


Rules determine how to Route traffic to a Backend and have the following characteristics.

  • HTTP settings, such as TLS termination of the Backend connection are defined.
  • Backend Targets are selected.
  • Backend Health Probes are attached to Rules.
  • Host-based, Path-based, Redirection and URL rewrite configuration are defined.

Health Probes

Health Probes are used to monitor Backend health at the application layer and have the following characteristics.

  • Resources considered unhealthy are automatically removed from the pool. Once healthy again, they are automatically added back into the pool.
  • A default health probe is automatically configured to make a HTTP GET request to the IP or FQDN configured in the backend pool.
  • Custom health probes allow you to define granular controls on how health probes operate.


The following diagrams show a command Application Gateway deployment architecture.


The following points summarize the above diagram.

  • A multi-site Application Gateway (AGW) is hosting and
  • Users browse to the domain and DNS resolves to the Public IP address (PIP) of the AGW.
  • The Listener tied to each domain determines if the AGW is load balance the traffic. The Listener also points to the Routing rule used for the Backend pool.
  • Routing rules determine how traffic is routed to the backend pool.
  • Backend Pool members serve traffic for their respective domains.


Application Gateways have the following considerations.

  • Application Gateways are deployed into a dedicated Subnet within a Virtual Network (VNet).
  • Multiple App Gateways can be deployed in the Subnet. However, The Subnet cannot be shared with Non Application Gateway Resources.
  • v1 and v2 App Gateways cannot share the same Subnet.
  • v1 App Gateways require a minimum /26 subnet.
  • It is recommended to install v2 App Gateways in a /24 Subnet to ensure sufficient address space is available for scaling.
  • A maximum of 40 listeners are recommended per Application Gateway.