Azure Application Gateway

Design concepts and deployment considerations

Azure Application Gateway consists of a number of components that come together to filter traffic and provide secure routing services for your web applications. The main components of the Azure Application Gateway service are as follows (see Figure 2-3):

• ■ Front-end IP addresses

• ■ Back-end pools

• ■ Listeners

• ■ Request routing rules

• ■ HTTP settings

• ■ Health probes

It is important to have a solid understanding of each of these components to be able to design and deploy them appropriately based on your environment’s requirements. In addition, you should have a strong grasp of sizing and scaling as well as TLS policy. This section covers all of these topics.

Front-end IP addresses

A front-end IP address is the ingress point for the application gateway to receive web application traffic. It is referenced in the internal and/or public DNS and used to route application traffic. The front-end IP address can be an internal private IP address, a public IP address, or both.

If a private IP address is to be used, the gateway should be deployed in the same region as the vNET with which it is associated. Similarly, you should create any public IP that must be associated as the front-end IP address in the same region as the application gateway.

The application gateway supports both static and dynamic IP addresses for the private and public IP addresses. However, based on the SKU of the gateway, the support varies for each. SKU v1 supports dynamic public IP addresses and static or dynamic private IP addresses; there is no support for static public IP addresses. SKU v2 supports static and dynamic private and public IP addresses. You cannot set up a static private IP address along with a dynamic public IP address, but you can set up a static public IP address with a dynamic private IP address if required.

Back-end pools

Back-end pools are back-end servers or services to which web traffic requests from clients are routed. They serve the client request with the required application response via the application gateway.

Back-end pools support the following types of services:

• ■ Virtual network interfaces

• ■ Virtual machine scale sets (VMSS)

• ■ Public IP addresses associated with Azure virtual machines (VMs) or services

• ■ Internal IP addresses associated with Azure or on-premises servers or services

• ■ Fully qualified domain names (FQDNs)

• ■ Azure services, such as App Service

Back-end pools can be located across Azure regions, across different clusters, or outside Azure in a client’s or third-party datacenter. As long as the application gateway can reach the back-end endpoint over TCP/IP, it can serve as a front-end to that web application.

For communications with on-premises servers, a VPN gateway or Azure ExpressRoute connection is necessary. For communication with Azure VMs and services over their private internal IPs, vNET peering or VPN gateway integration is needed.

Listeners

Every application gateway requires a minimum of one listener and can contain multiple listeners. A listener helps you define the protocol, port, hostname, and source IP address that is allowed to communicate with the back-end pool. Based on the configuration of the listeners defined on the application gateway, traffic is passed through or dropped. If the listener allows traffic through, the gateway evaluates it against routing rules configured to route traffic to the correct back-end pool.

There are two types of listeners:

• ■ Basic A basic listener can listen for requests only for a single domain.

• ■ Multi-site A multi-site listener can listen to requests for multiple host names or domain names. This type of listener can support more than 100 websites, which you can route to their own back-end pool.

Both types of listeners support the following ports:

• ■ SKU V1 Ports 1 – 65502

• ■ SKU V2 Ports 1 – 65199

In addition, they support the following protocols:

• ■ HTTP

• ■ HTTPS

• ■ HTTP/2

• ■ WebSocket

There are a few caveats to be aware of, as follows:

• ■ WebSocket protocol support is enabled by default and cannot be turned off.

• ■ HTTP/2 protocol support is disabled by default and must be turned on manually.

• ■ HTTP/2 protocol support is limited to the client and application gateway communications. Any back-end communications occur over HTTP/1.1.

Request routing rules

A request routing rule defines how traffic received by the application gateway should be routed. It binds the listener to a back-end server pool based on the HTTP settings defined to monitor in the request. One listener can be attached to only one rule.

Routing to the back-end pool depends on the rule configuration that defines which back-end pool binds to which URL or URL path. The routing rule also specifies whether any request must be rewritten before being routed to the back-end pool.

There are two types of request routing rules:

• ■ Basic A basic request routing rule forwards all traffic to the associated back-end pool based on the HTTP settings associated with the rule.

• ■ Path-based A path-based request routing rule analyzes the URL path in the request to identify the back-end pool to which to route the request. The rule contains different URL paths, set up to route to different back-end pools. If the incoming request does not match any of the rules, the traffic is routed to the default back-end pool based on associated HTTP settings.

A request routing rule is evaluated based on the priority assigned to that rule. By default, the priority is automatically assigned based on the order of rule creation (unless a specific priority is provided at the time of rule creation or set later on).

It is important to take priority into consideration in case there are rules that contain domains that overlap—for example, *.fabrikam.com and blogs.fabrikam.com. In such cases, wildcard rules should be lower in priority to ensure the individual domain rules are evaluated before the wildcard rules. Otherwise, requests will be routed to the back-end pools associated with the wildcard domains only.

Redirection support

In addition to routing traffic to back-end pools, request routing rules can be set up to redirect traffic to and from any port to a redirection target. The redirection could be to another listener or an external site. Redirection routing helps redirect HTTP traffic to HTTPS, or traffic from a standard web port (such as 80) to a non-standard port.

Azure Application Gateway supports different types of redirection:

• ■ 310 Permanent Redirect

• ■ 302 Found

• ■ 303 See Other

• ■ 307 Temporary Redirect

Rewriting of HTTP headers and URLs

Azure Application Gateway allows HTTP request and response headers to be modified before the packet is sent to the back-end pool. So, the URL can be rewritten with custom security header fields, removing sensitive header information such as port information on X-Forwarded-For (XFF) headers. This feature can apply these changes only when certain conditions are met, so you can target rewrites to address any complex scenario as required.

HTTP settings

HTTP settings define the back-end servers’ port number, protocol, encryption settings, and other details. The application gateway uses these settings to route traffic to back-end servers when it receives a matching request.

HTTP settings are also used to define other settings, such as the following:

• ■ Cookie-Based Session Affinity This setting instructs the gateway to use affinity to always route requests from the same client to the same hosts (assuming the host is online).

• ■ Connection Draining This setting instructs the application gateway to gracefully drain connections on back-end servers, as they may be taken down for maintenance.

• ■ Custom Health Probe This setting helps the gateway understand how it should validate the health of the back-end pool.

Health probes

Monitoring the health of back-end pool instances is a critical function. It helps the service decide which back-end pool instances are healthy and usable for request routing and which ones need to be taken out of service to avoid application outages. Health probes provide the application gateway with the hostname, URL path, probe interval, and failed response limits to help it identify unhealthy back-end pool instances. The application gateway performs health monitoring by default. However, custom health probes help the gateway target the right parameters to evaluate instance health. Therefore, it is highly recommended to define custom health probes for each individual back-end pool.

Sizing and scaling

The v1 SKU offers different gateway sizes:

• ■ Small Appropriate for test and dev scenarios.

• ■ Medium Appropriate for small environments with a few hundred users accessing a web application.

• ■ Large Recommended for most enterprise or multi-site scenarios, to handle higher loads.

With the v2 SKU, autoscaling is available, eliminating the need for different gateway sizes. In this case, you use manual scaling or auto-scaling configurations to handle load instead of attempting to determine the right instance size at the outset.

TLS policy

With Azure Application Gateway, you can offload SSL/TLS. This way, SSL connections from clients are terminated on the application gateway, and internal communications with the application back-end can be encrypted or unencrypted (thereby reducing overhead on instances of the application). If the back-end instances are set up to communicate with the application gateway in an unencrypted manner, application certificates can be deployed and managed only on the application gateway. This makes it easier to track, maintain, and update them.

A TLS policy defines the different TLS protocol versions and cipher suites to be used during a TLS handshake. The order of the ciphers specifies the order in which they are evaluated at the time of the handshake. There are two mechanisms to control this, as follows:

• ■ Using a predefined TLS policy Every application gateway interface includes three predefined TLS policies—each one defined to support different TLS protocol versions and cipher suites. The names of the policies indicate the dates on which they were introduced; it’s recommended that you use the newer ones.

• ■ Using a custom TLS policy If a predefined policy does not meet your requirements, you can customize a policy to include the TLS protocols and cipher suites (and their priority) based on your needs.

With both predefined and custom TLS policies, SSL 2.0 and 3.0 are set to disabled, and you cannot override this. However, with a custom policy, you can set up any of the three TLS protocol versions (v1_0, v1_1, or v1_2) as the minimum required version. You can also set up all three of these with no minimum requirement if needed.

Application gateway walkthrough

The following sections walk you through the process of creating an application gateway using the Azure Portal, Azure PowerShell, and the Azure CLI. If you are following along, be sure to select resources and resource names based on your environment, including a unique application gateway name for each of your deployments. Also be sure to delete any unwanted resources after you have completed testing to reduce charges levied by Microsoft for these resources. Finally, to complete this walkthrough, you need to have created at least two back-end VMs with IIS web services to integrate with the Application Gateway. Microsoft provides Windows Server templates in the Azure Marketplace that install and set up IIS with the default configuration; alternatively, you can create a custom configuration based on your requirements.

Using the Azure Portal

To create an application gateway using the Azure Portal, follow these steps:

1. Log into the Azure Portal, type application gateway in the search box to locate the service, and select it from the list that appears.

2. Click Create or Create Application Gateway to start the Create Application Gateway wizard. (See Figure 2-4.)

   

   FIGURE 2-4 Click Create Application Gateway.

3. In the Basics tab of the Create Application Gateway wizard (see Figure 2-5), enter the following information and click Next: Frontends:

   • ■ Subscription Select the subscription to host the application gateway.

   • ■ Resource Group Select the resource group you want to host the application gateway. Alternatively, click the Create New link and follow the prompts to create a new resource group.

   • ■ Name Type a name for the application gateway. If the name you type is already in use, the wizard will prompt you to enter another name.

   • ■ Region Select the Azure region in which you want to create the application gateway.

   • ■ Tier Choose Standard V2.

   • ■ Enable Autoscaling Select the Yes option button.

   • ■ Minimum Instance Count Enter the minimum number of hosts to set up.

   • ■ Maximum Instance Count Enter the maximum number of hosts to which the gateway should scale.

   • ■ Availability Zone Leave this set to None.

   • ■ HTTP2 Leave this set to Disabled.

   • ■ Virtual Network Select an existing vNET for which you have created back-end VMs.

   • ■ Subnet Select a subnet for the application gateway.

   

   FIGURE 2-5 The Basics tab of the Create Application Gateway wizard.

4. In the Frontends tab of the Create Application Gateway wizard (see Figure 2-6), for Frontend IP Address Type, select the Public option button.

   

   FIGURE 2-6 The Frontends tab of the Create Application Gateway wizard.

5. Under the Public IP Address box, click the Add New link.

6. On the Add a Public IP page, in the Name box, type a name for the public IP address. (See Figure 2-7.) Then click OK.

   

   FIGURE 2-7 The Add a Public IP dialog box.

7. In the Frontends tab of the Create Application Gateway wizard, click Next: Backends.

8. In the Backends tab of the Create Application Gateway wizard (see Figure 2-8), click the Add a Backend Pool link.

   

   FIGURE 2-8 The Backends tab of the Create Application Gateway wizard.

9. In the Add a Backend Pool dialog box (see Figure 2-9), enter the following information and click Add:

   • ■ Name Type a name for the back-end pool.

   • ■ Add Backend Pool Without Targets Click No.

   • ■ Target Type Select Virtual Machine.

   • ■ Target Select one of the VMs you created for this walkthrough.

   

   FIGURE 2-9 The Add a Backend Pool dialog box.

10. In the Backends tab of the Create Application Gateway wizard (see Figure 2-10), verify that the back-end pool configuration is correct and click Next: Configuration.

    

    FIGURE 2-10 The updated Backends tab of the Create Application Gateway wizard.

11. In the Configuration tab of the Create Application Gateway wizard (see Figure 2-11), click Add a Routing Rule to create a routing rule for incoming traffic.

    

    FIGURE 2-11 The Configuration tab of the Create Application Gateway wizard.

12. In the Listener tab of the Add a Routing Rule settings (see Figure 2-12), enter the following information:

    • ■ Rule Name Type a name for the rule.

    • ■ Listener Name Type a name for the listener.

    • ■ Frontend IP Select Public.

    • ■ Protocol Select the protocol used by your application.

    • ■ Port Type the port used by your application.

    • ■ Listener Type Select the Basic option button.

    • ■ Error Page URL Select the No option button.

    

    FIGURE 2-12 The Listener tab in the Add a Routing Rule settings.

13. Click the Backend Targets tab (look ahead to Figure 2-13).

14. For Target Type, select the Backend Pool option button.

15. Open the Backend Target drop-down list and select the back-end pool target.

16. Under HTTP Settings, click the Add New link.

17. In the Add a HTTP Setting settings (see Figure 2-14), enter the following information and click Add. (Leave the other settings as is.)

    • ■ HTTP Settings Name Enter a name for the HTTP settings.

    • ■ Backend Protocol Select the back-end protocol used by the application.

    • ■ Backend Port Type the back-end port used by your application.

    • ■ Cookie-Based Affinity Select the Disable option button.

    • ■ Connection Draining Select the Disable option button.

    • ■ Request Time-Out (Seconds) Enter a request time-out value (in seconds) that reflects the responsiveness of your application.

    

    FIGURE 2-13 The Backend Targets tab of the Add a Routing Rule settings.

    

    FIGURE 2-14 The Add a HTTP Setting settings.

18. In the Configurations tab (see Figure 2-15), confirm that the configuration is correct and click Next: Tags.

    

    FIGURE 2-15 The updated Configuration tab of the Create Application Gateway wizard.

19. In the Tags tab, enter any tags required for the application gateway or leave the fields blank (see Figure 2-16) and click Next: Review + Create.

    

    FIGURE 2-16 The Tags tab of the Create Application Gateway wizard.

20. On the Review + Create tab (see Figure 2-17), review your settings, and click Create. You can now test whether your application is accessible by accessing the application gateway URL. (The URL will be visible in the application gateway’s Overview tab.)

Using Azure PowerShell

You can create an application gateway using Azure PowerShell with the New-AzVirtualNetworkGateway and New-AzVirtualNetworkGatewayConnection commands and various switches to set the application gateway’s parameters. The following code shows you how. Use this snippet to create the same application gateway as you did in the Azure Portal. (Replace all the variables and on-premises firewall configuration as per your environment.) When you do, be sure to either delete the previous application gateway or give this new application gateway a different name:

#Define variables
$agSubnetConfig = New-AzVirtualNetworkSubnetConfig `
  -Name myAGSubnet `
  -AddressPrefix 10.21.0.0/24
$backendSubnetConfig = New-AzVirtualNetworkSubnetConfig `
  -Name myBackendSubnet `
  -AddressPrefix 10.21.1.0/24
New-AzVirtualNetwork `
  -ResourceGroupName myResourceGroupAG `
  -Location eastus `
  -Name myVNet `
  -AddressPrefix 10.21.0.0/16 `
  -Subnet $agSubnetConfig, $backendSubnetConfig
New-AzPublicIpAddress `
  -ResourceGroupName myResourceGroupAG `
  -Location eastus `
  -Name myAGPublicIPAddress `
  -AllocationMethod Static `
  -Sku Standard
#Create IP Config and front-end port
$vnet   = Get-AzVirtualNetwork -ResourceGroupName myResourceGroupAG -Name myVNet
$subnet = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name myAGSubnet
$pip    = Get-AzPublicIPAddress -ResourceGroupName myResourceGroupAG -Name myAGPublicIPAddress 
$gipconfig = New-AzApplicationGatewayIPConfiguration `
  -Name myAGIPConfig `
  -Subnet $subnet
$fipconfig = New-AzApplicationGatewayFrontendIPConfig `
  -Name myAGFrontendIPConfig `
  -PublicIPAddress $pip
$frontendport = New-AzApplicationGatewayFrontendPort `
  -Name myFrontendPort `
  -Port 80
#Create backend pool
$backendPool = New-AzApplicationGatewayBackendAddressPool `
  -Name myAGBackendPool
$poolSettings = New-AzApplicationGatewayBackendHttpSetting `
  -Name myPoolSettings `
  -Port 80 `
  -Protocol Http `
  -CookieBasedAffinity Enabled `
  -RequestTimeout 30
#Create listener and add rule
$defaultlistener = New-AzApplicationGatewayHttpListener `
  -Name myAGListener `
  -Protocol Http `
  -FrontendIPConfiguration $fipconfig `
  -FrontendPort $frontendport
$frontendRule = New-AzApplicationGatewayRequestRoutingRule `
  -Name rule1 `
  -RuleType Basic `
  -HttpListener $defaultlistener `
  -BackendAddressPool $backendPool `
  -BackendHttpSettings $poolSettings
#Create application gateway
$sku = New-AzApplicationGatewaySku `
  -Name Standard_v2 `
  -Tier Standard_v2 `
  -Capacity 2
New-AzApplicationGateway `
  -Name myAppGateway `
  -ResourceGroupName myResourceGroupAG `
  -Location eastus `
  -BackendAddressPools $backendPool `
  -BackendHttpSettingsCollection $poolSettings `
  -FrontendIpConfigurations $fipconfig `
  -GatewayIpConfigurations $gipconfig `
  -FrontendPorts $frontendport `
  -HttpListeners $defaultlistener `
  -RequestRoutingRules $frontendRule `
  -Sku $sku

Using the Azure CLI

You can create an application gateway using the Azure CLI with the az network vnet-gateway create command and various switches to set the application gateway’s parameters. The following Bash script shows you how. Use this snippet to create the same application gateway as you did in the Azure Portal. (Replace all the variables and on-premises firewall configuration as per your environment.) When you do, be sure to either delete the previous application gateway or give this new application gateway a different name:

#Define variables
#Create network
az network vnet create   --name myVNet   --resource-group myResourceGroupAG   --location eastus   --address-prefix 10.21.0.0/16   --subnet-name myAGSubnet   --subnet-prefix 10.21.0.0/24
az network vnet subnet create   --name myBackendSubnet   --resource-group myResourceGroupAG   --vnet-name myVNet     --address-prefix 10.21.1.0/24
az network public-ip create   --resource-group myResourceGroupAG   --name myAGPublicIPAddress   --allocation-method Static   --sku Standard
#Create application gateway
address1=$(az network nic show --name myNic1 --resource-group myResourceGroupAG | grep
"\"privateIpAddress\":" | grep -oE '[^ ]+$' | tr -d '",')
address2=$(az network nic show --name myNic2 --resource-group myResourceGroupAG | grep
"\"privateIpAddress\":" | grep -oE '[^ ]+$' | tr -d '",')
az network application-gateway create   --name myAppGateway   --location eastus   --resource-group myResourceGroupAG   --capacity 2   --sku Standard_v2   --public-ip-address myAGPublicIPAddress   --vnet-name myVNet   --subnet myAGSubnet   --servers "$address1" "$address2"