...
The gateway routes requests to a selected web server in the back-end pool, using a set of rules configured for the gateway to determine where the request should go.
There are two primary methods of routing traffic, path-based routing and multiple site hosting.
Path-based routing enables you to send requests with different paths in the URL to a different pool of back-end servers.
Multiple site hosting enables you to configure more than one web application on the same application gateway instance.
In a multi-site configuration, you register multiple DNS names (CNAMEs) for the IP address of the Application Gateway, specifying the name of each site.
Application Gateway uses separate listeners to wait for requests for each site.
Each listener passes the request to a different rule, which can route the requests to servers in a different back-end pool.
Multi-site configurations are useful for supporting multi-tenant applications, where each tenant has its own set of virtual machines or other resources hosting a web application.
...
MultiSite Hosting
Multiple site hosting enables you to configure more than one web application on the same port of application gateways using public-facing listeners.
...
up to 100+ websites to one application gateway
Each website can be directed to its own backend pool.
For example, three domains, http://contoso.com , http://fabrikam.com , and http://adatum.com , point to the IP address of the application gateway.
You'd create three multi-site listeners and configure each listener for the respective port and protocol setting.
You can also define wildcard host names in a multi-site listener
...
Design Azure Application Gateway
Support for the HTTP, HTTPS, HTTP/2 and WebSocket protocols.
A web application firewall to protect against web application vulnerabilities.
End-to-end request encryption.
Autoscaling, to dynamically adjust capacity as your web traffic load change.
Redirection: Redirection can be used to another site, or from HTTP to HTTPS.
Rewrite HTTP headers: HTTP headers allow the client and server to pass parameter information with the request or the response.
Custom error pages: Application Gateway allows you to create custom error pages instead of displaying default error pages. You can use your own branding and layout using a custom error page.
...
Choosing an Azure Application Gateway SKU
Application Gateway is available under a Standard_v2 SKU. Web Application Firewall (WAF) is available under a WAF_v2 SKU.
The v2 SKU offers performance enhancements and adds support for critical new features like autoscaling, zone redundancy, and support for static VIPs.
Existing features under the Standard and WAF SKU continue to be supported in the new v2 SKU.
The new v2 SKU includes the following enhancements:
Autoscaling: Application Gateway or WAF deployments under the autoscaling SKU can scale out or in based on changing traffic load patterns.
Autoscaling also removes the requirement to choose a deployment size or instance count during provisioning. This SKU offers true elasticity.
Zone redundancy: An Application Gateway or WAF deployment can span multiple Availability Zones, removing the need to provision separate Application Gateway instances in each zone with a Traffic Manager.
You can choose a single zone or multiple zones where Application Gateway instances are deployed, which makes it more resilient to zone failure.
Static VIP: Application Gateway v2 SKU supports the static VIP type exclusively. This ensures that the VIP associated with the application gateway doesn't change for the lifecycle of the deployment, even after a restart.
Header Rewrite: Application Gateway allows you to add, remove, or update HTTP request and response headers with v2 SKU.
Key Vault Integration: Application Gateway v2 supports integration with Key Vault for server certificates that are attached to HTTPS enabled listeners.
Azure Kubernetes Service Ingress Controller: The Application Gateway v2 Ingress Controller allows the Azure Application Gateway to be used as the ingress for an Azure Kubernetes Service (AKS) known as AKS Cluster.
Performance enhancements: The v2 SKU offers up to 5X better TLS offload performance as compared to the Standard/WAF SKU.
Faster deployment and update time: The v2 SKU provides faster deployment and update time as compared to Standard/WAF SKU. This also includes WAF configuration changes.
With the v2 SKU, the pricing model is driven by consumption and is no longer attached to instance counts or sizes.
Each capacity unit is composed of at most: 1 compute unit, 2500 persistent connections, and 2.22-Mbps throughput.
...
Configure Azure Application Gateway
Application Gateway has a series of components that combine to route requests to a pool of web servers and to check the health of these web servers.
...
You can configure the application gateway to have a public IP address, a private IP address, or both.
A public IP address is required when you host a back end that clients must access over the Internet via an Internet-facing virtual IP (VIP).
Backend pools can be composed of NICs, virtual machine scale sets, public IP addresses, internal IP addresses, fully qualified domain names (FQDN), and multi-tenant back-ends like Azure App Service.
Azure Application Gateway by default monitors the health of all resources in its back-end pool and automatically removes any resource considered unhealthy from the pool.
Application Gateway continues to monitor the unhealthy instances and adds them back to the healthy back-end pool once they become available and respond to health probes.
The source IP address Application Gateway uses for health probes depends on the backend pool:
If the server address in the backend pool is a public endpoint, then the source address is the application gateway's frontend public IP address.
If the server address in the backend pool is a private endpoint, then the source IP address is from the application gateway subnet's private IP address space.
...
Default health probe
An application gateway automatically configures a default health probe when you don't set up any custom probe configurations.
The monitoring behavior works by making an HTTP GET request to the IP addresses or FQDN configured in the back-end pool.
The following table lists the default health probe settings:
Probe property | Value | Description |
|---|---|---|
Probe URL |
| The protocol and port are inherited from the backend HTTP settings to which the probe is associated |
Interval | 30 | The amount of time in seconds to wait before the next health probe is sent. |
Time-out | 30 | The amount of time in seconds the application gateway waits for a probe response before marking the probe as unhealthy. If a probe returns as healthy, the corresponding backend is immediately marked as healthy. |
Unhealthy threshold | 3 | Governs how many probes to send in case there's a failure of the regular health probe. In v1 SKU, these additional health probes are sent in quick succession to determine the health of the backend quickly and don't wait for the probe interval. In the case of v2 SKU, the health probes wait the interval. The back-end server is marked down after the consecutive probe failure count reaches the unhealthy threshold. |
All instances of Application Gateway probe the backend independent of each other.
The same probe configuration applies to each Application Gateway instance.
If there are multiple listeners, then each listener probes the backend independent of each other.
Custom probes give you more granular control over the health monitoring.
When using custom probes, you can configure a custom hostname, URL path, probe interval, and how many failed responses to accept before marking the back-end pool instance as unhealthy
By default, an HTTP(S) response with status code between 200 and 399 is considered healthy.
Custom health probes additionally support two matching criteria.
HTTP response status code match - Probe matching criterion for accepting user specified http response code or response code ranges.
Individual comma-separated response status codes or a range of status code is supported.
HTTP response body match - Probe matching criterion that looks at HTTP response body and matches with a user specified string.
The match only looks for presence of user specified string in response body and isn't a full regular expression match.
Match criteria can be specified using the New-AzApplicationGatewayProbeHealthResponseMatch cmdlet.