Intro
My notes on this service
Documentation
Tips and Tidbits
Azure Application Gateway is a REGIONAL web traffic load balancer that enables you to manage traffic to your web applications.
Application Gateway routes traffic to a pool of web servers based on the URL of a request
Traditional load balancers operate at the transport layer (OSI layer 4 - TCP and UDP) and route traffic based on source IP address and port, to a destination IP address and port.
Application Gateway can make routing decisions based on additional attributes of an HTTP request, for example URI path or host headers.
This type of routing is known as application layer (OSI layer 7) load balancing
Azure provides a suite of fully managed load-balancing solutions for your scenarios.
If you are looking to do DNS based global routing and do not have requirements for Transport Layer Security (TLS) protocol termination ("SSL offload"), per-HTTP/HTTPS request or application-layer processing, review Traffic Manager.
If you need to optimize global routing of your web traffic and optimize top-tier end-user performance and reliability through quick global failover, see Front Door.
To do network layer load balancing, review Load Balancer.
Deployment of an Azure Application Gateway requires a dedicated subnet
Azure Application Gateway offers a web application firewall (WAF) that provides centralized protection of your web applications from common exploits and vulnerabilities.
Web applications are increasingly targeted by malicious attacks that exploit commonly known vulnerabilities.
SQL injection and cross-site scripting are among the most common attacks.
Application Gateway operates as an application delivery controller (ADC).
It offers Secure Sockets Layer (SSL) termination, cookie-based session affinity, round- robin load distribution, content-based routing, ability to host multiple websites, and security enhancements.
Load Balancing
Understand Azure load balancing - Pay attention to the global vs regional use and the type of traffic.
The following table summarizes the Azure load balancing services by these categories:
Service | Global/regional | Recommended traffic |
|---|---|---|
Azure Front Door | Global | HTTP(S) |
Traffic Manager | Global | non-HTTP(S) |
Application Gateway | Regional | HTTP(S) |
Azure Load Balancer | Regional | non-HTTP(S) |
SSL Termination
Tutorial: Configure an application gateway with TLS termination using the Azure portal
The following image shows how incoming traffic from a client to Application Gateway over SSL is decrypted and then re-encrypted when it's sent to a server in the backend pool.
The listener can use an SSL certificate to decrypt the traffic that enters the gateway.
The listener then uses a rule that you define to direct the incoming requests to a backend pool.
The backend pool has an HTTP setting that references a certificate used to authenticate the backend servers.
The gateway re-encrypts the traffic by using this certificate before sending it to one of your servers in the backend pool.
If you're using Azure App Service to host the backend application, you don't need to install any certificates in Application Gateway to connect to the backend pool.
All communications are automatically encrypted
Application Gateway configuration overview
A public IP is required when you host a back end that clients must access over the Internet via an Internet-facing virtual IP (VIP).
A listener is a logical entity that checks for incoming connection requests by using the port, protocol, host, and IP address.
When you configure the listener, you must enter values for these that match the corresponding values in the incoming request on the gateway.
After you create the gateway, you can edit the settings of the default rule or create new rules.
After you create an HTTP setting, you must associate it with one or more request-routing rules.
After you create a back-end pool, you must associate it with one or more request-routing rules.
You must also configure health probes for each back-end pool on your application gateway.
Application Gateway HTTP settings configuration
The application gateway routes traffic to the back-end servers by using the configuration that you specify here.
After you create an HTTP setting, you must associate it with one or more request-routing rules.
Host name override
This capability replaces the host header in the incoming request on the application gateway with the host name that you specify.
For example, if www.contoso.com is specified in the Host name setting, the original request *
https://appgw.eastus.cloudapp.azure.com/path1is changed to *https://www.contoso.com/path1when the request is forwarded to the back-end server.
Application Gateway support for multi-tenant back ends such as App service
In multi-tenant architectural designs in web servers, multiple websites are running on the same web server instance.
Hostnames are used to differentiate between the different applications which are hosted.
By default, application gateway does not change the incoming HTTP host header from the client and sends the header unaltered to the back end.
This setting lets you configure an optional custom forwarding path to use when the request is forwarded to the back end.
Any part of the incoming path that matches the custom path in the override backend path field is copied to the forwarded path.
TLS termination and end to end TLS with multi-tenant services
TLS termination and end to end TLS with multi-tenant services
Both TLS termination and end to end TLS encryption is supported with multi-tenant services.
For TLS termination at the application gateway, TLS certificate continues to be required to be added to the application gateway listener.
However, in case of end to end TLS, trusted Azure services such as Azure App service web apps do not require allowing the backends in the application gateway.
Therefore, there is no need to add any authentication certificates.
Notice that in the above image, there is no requirement to add authentication certificates when App service is selected as backend.
Application Gateway Routing
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.
Configure listeners
A listener is a logical entity that checks for incoming connection requests by using the port, protocol, host, and IP address.
When you configure a listener, you must enter values that match the corresponding values in the incoming request on the gateway.
After you create the application gateway, you can edit the settings of that default listener (appGatewayHttpListener) or create new listeners.
Basic: All requests for any domain will be accepted and forwarded to backend pools.
Multi-site: Forward requests to different backend pools based on the host header or host names.
You must specify a host name that matches with the incoming request.
This is because Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port.
For the v2 SKU, multi-site listeners are processed before basic listeners.
Choose the front-end IP address that you plan to associate with this listener
Choose the front-end port.
HTTPS: enables TLS termination or end-to-end TLS encryption.
The TLS connection terminates at the application gateway.
Traffic between the client and the application gateway is encrypted.
If you want end-to-end TLS encryption, you must choose HTTPS and configure the back-end HTTP setting.
This ensures that traffic is re-encrypted when it travels from the application gateway to the back end.
To configure TLS termination and end-to-end TLS encryption, you must add a certificate to the listener to enable the application gateway to derive a symmetric key.
This is dictated by the TLS protocol specification.
The symmetric key is used to encrypt and decrypt the traffic that's sent to the gateway.
The gateway certificate must be in Personal Information Exchange (PFX) format.
This format lets you export the private key that the gateway uses to encrypt and decrypt traffic.
Redirection overview
You can use application gateway to redirect traffic.
It has a generic redirection mechanism which allows for redirecting traffic received at one listener to another listener or to an external site.
A common redirection scenario for many web applications is to support automatic HTTP to HTTPS redirection to ensure all communication between application and its users occurs over an encrypted path.
The following types of redirection are supported:
301 Permanent Redirect
302 Found
303 See Other
307 Temporary Redirect
see URL path-based redirection using PowerShell - Azure Application Gateway | Microsoft Docs.
Application Gateway request routing rules
When you create an application gateway using the Azure portal, you create a default rule (rule1).
This rule binds the default listener (appGatewayHttpListener) with the default back-end pool (appGatewayBackendPool) and the default back-end HTTP settings (appGatewayBackendHttpSettings).
For a basic rule, only one back-end pool is allowed.
All requests on the associated listener are forwarded to that back-end pool.
For a path-based rule, add multiple back-end pools that correspond to each URL path.
The requests that match the URL path that's entered are forwarded to the corresponding back-end pool.
Add a back-end HTTP setting for each rule.
Requests are routed from the application gateway to the back-end targets by using the port number, protocol, and other information that's specified in this setting.
Rewrite HTTP headers and URL
By using rewrite rules, you can add, remove, or update HTTP(S) request and response headers as well as URL path and query string parameters as the request and response packets move between the client and backend pools via the application gateway.
The headers and URL parameters can be set to static values or to other headers and server variables.
HTTP header and URL rewrite features are only available for the Application Gateway v2 SKU.
By rewriting these headers, you can accomplish important tasks, such as adding security-related header fields like HSTS/ X-XSS-Protection, removing response header fields that might reveal sensitive information, and removing port information from X-Forwarded-For headers.
Rewrite the host name, path, and query string of the request URL
The value of a URL or a new or existing header can be set to these types of values:
Text
Request header. To specify a request header, you need to use the syntax {http_req_headerName}
Response header. To specify a response header, you need to use the syntax {http_resp_headerName}
Server variable. To specify a server variable, you need to use the syntax {var_serverVariable}. See the list of supported server variables
UrlPathMap configuration element
"urlPathMaps": [{
"name": "{urlpathMapName}",
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/urlPathMaps/{urlpathMapName}",
"properties": {
"defaultBackendAddressPool": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName1}"
},
"defaultBackendHttpSettings": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpSettingsList/{settingname1}"
},
"pathRules": [{
"name": "{pathRuleName}",
"properties": {
"paths": [
"{pathPattern}"
],
"backendAddressPool": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName2}"
},
"backendHttpsettings": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpsettingsList/{settingName2}"
}
}
}]
}
}]
PathPattern is a list of path patterns to match. Each must start with / and the only place a "*" is allowed is at the end following a "/."
Add Comment