Intro

My notes on this service

Documentation

• What is Azure Application Gateway?

• Tutorial: Configure an application gateway with TLS termination using the Azure portal

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:

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 HTTP settings configuration

• 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/path1 is changed to *https://www.contoso.com/path1 when 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.

• Override back-end path

• 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.

• Tutorial: Create an application gateway with a Web Application Firewall using the Azure portal

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

• Application Gateway multiple site 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

• 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

• 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

• 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:

• 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.