App Gateway PDF

Contents
Application Gateway Documentation

Overview
About application gateways
Quickstarts
Manage web traffic - Portal
Manage web traffic - PowerShell
Manage web traffic - Azure CLI
Tutorials
Manage web traffic
Enable web application firewall
Secure with SSL
Host multiple sites
Route by URL
Redirect web traffic
Samples
Azure PowerShell
Azure CLI
Concepts
SSL termination
SSL policy overview
Web application firewall
URL routing
Multiple site hosting
Redirection support
Multi-tenant support
Health monitoring
WebSocket support
How-to guides
Manage web traffic
Azure PowerShell
Template
Configure internal load balancer
Azure PowerShell
Configure SSL termination
SSL termination using the Azure portal
SSL termination using Azure PowerShell
Renew certificates
Configure SSL policy
Configure Web Application Firewall
Azure portal
Azure PowerShell
Customize WAF rules
Azure portal
Azure PowerShell
Azure CLI
Route by URL
Azure portal
Azure PowerShell
Host multiple sites
Azure portal
Azure PowerShell
Redirect traffic
HTTP to HTTPS
Azure PowerShell
Azure CLI
Redirect internal traffic
Azure PowerShell
Azure CLI
Multi-tenant support
Configure multi-tenat support
Redirect web traffic using Azure PowerShell
Create a zone redundant application gateway
Custom probes
Portal
Classic PowerShell
Resource Manager PowerShell
Troubleshoot
Troubleshoot Bad Gateway (502) errors
Diagnostics
Reference
CRS rules
Azure CLI
Azure PowerShell
.NET
Java
Node.js
Python
REST
Azure Resource Manager
Resources
Author templates
Azure Roadmap
Community templates
Pricing
Regional availability
Stack Overflow
FAQ
What is Azure Application Gateway?
5/21/2018 • 4 minutes to read • Edit Online
Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web
applications.
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. But with the Application Gateway you can be
even more specific. For example, you can route traffic based on the incoming URL. So if /images is in the
incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If
/video is in the URL, that traffic is routed to another pool optimized for videos.
This type of routing is known as application layer (OSI layer 7) load balancing. Azure Application Gateway can
do URL -based routing and more.
The following features are included with Azure Application Gateway:
Secure Sockets Layer (SSL) termination

Application gateway supports SSL termination at the gateway, after which traffic typically flows unencrypted to
the backend servers. This feature allows web servers to be unburdened from costly encryption and decryption
overhead. However, sometimes unencrypted communication to the servers is not an acceptable option. This
could be due to security requirements, compliance requirements, or the application may only accept a secure
connection. For such applications, application gateway supports end to end SSL encryption.
Web application firewall

Web application firewall (WAF ) is a feature of Application Gateway that provides centralized protection of your
web applications from common exploits and vulnerabilities. WAF is based on rules from the OWASP (Open
Web Application Security Project) core rule sets 3.0 or 2.2.9.
Web applications are increasingly targets of malicious attacks that exploit common known vulnerabilities.
Common among these exploits are SQL injection attacks, cross site scripting attacks to name a few. Preventing
such attacks in application code can be challenging and may require rigorous maintenance, patching and
monitoring at many layers of the application topology. A centralized web application firewall helps make security
management much simpler and gives better assurance to application administrators against threats or
intrusions. A WAF solution can also react to a security threat faster by patching a known vulnerability at a central
location versus securing each of individual web applications. Existing application gateways can be converted to a
web application firewall enabled application gateway easily.
URL-based routing
URL Path Based Routing allows you to route traffic to back-end server pools based on URL Paths of the request.
One of the scenarios is to route requests for different content types to different pool.
For example, requests for are routed to VideoServerPool, and
http://contoso.com/video/*
http://contoso.com/images/* are routed to ImageServerPool. DefaultServerPool is selected if none of the path
patterns match.
Multiple-site hosting
Multiple-site hosting enables you to configure more than one web site on the same application gateway
instance. This feature allows you to configure a more efficient topology for your deployments by adding up to 20
web sites to one application gateway. Each web site can be directed to its own pool. For example, application
gateway can serve traffic for contoso.com and fabrikam.com from two server pools called ContosoServerPool
and FabrikamServerPool.
Requests for http://contoso.com are routed to ContosoServerPool, and http://fabrikam.com are routed to
FabrikamServerPool.
Similarly, two subdomains of the same parent domain can be hosted on the same application gateway
deployment. Examples of using subdomains could include http://blog.contoso.com and http://app.contoso.com
hosted on a single application gateway deployment.
Redirection
A common scenario for many web applications is to support automatic HTTP to HTTPS redirection to ensure all
communication between an application and its users occurs over an encrypted path.
In the past, you may have used techniques such as creating a dedicated pool whose sole purpose is to redirect
requests it receives on HTTP to HTTPS. Application gateway supports the ability to redirect traffic on the
Application Gateway. This simplifies application configuration, optimizes the resource usage, and supports new
redirection scenarios, including global and path-based redirection. Application Gateway redirection support is
not limited to HTTP to HTTPS redirection alone. This is a generic redirection mechanism, so you can redirect
from and to any port you define using rules. It also supports redirection to an external site as well.
Application Gateway redirection support offers the following capabilities:
Global redirection from one port to another port on the Gateway. This enables HTTP to HTTPS redirection
on a site.
Path-based redirection. This type of redirection enables HTTP to HTTPS redirection only on a specific site
area, for example a shopping cart area denoted by /cart/* .
Redirect to an external site.
Session affinity
The cookie-based session affinity feature is useful when you want to keep a user session on the same server. By
using gateway-managed cookies, the Application Gateway can direct subsequent traffic from a user session to
the same server for processing. This is important in cases where session state is saved locally on the server for a
user session.
Websocket and HTTP/2 traffic

Application Gateway provides native support for the WebSocket and HTTP/2 protocols. There's no user-
configurable setting to selectively enable or disable WebSocket support. HTTP/2 support can be enabled using
Azure PowerShell.
The WebSocket and HTTP/2 protocols enable full duplex communication between a server and a client over a
long running TCP connection. This allows for a more interactive communication between the web server and the
client, which can be bidirectional without the need for polling as required in HTTP -based implementations. These
protocols have low overhead, unlike HTTP, and can reuse the same TCP connection for multiple
request/responses resulting in a more efficient utilization of resources. These protocols are designed to work
over traditional HTTP ports of 80 and 443.
Next steps
Depending on your requirements and environment, you can create a test Application Gateway using either the
Azure portal, Azure PowerShell, or Azure CLI:
Quickstart: Direct web traffic with Azure Application Gateway - Azure portal.
Quickstart: Direct web traffic with Azure Application Gateway - Azure PowerShell
Quickstart: Direct web traffic with Azure Application Gateway - Azure CLI
Quickstart: Direct web traffic with Azure Application
Gateway - Azure portal
With Azure Application Gateway, you can direct your application web traffic to specific resources by assigning
listeners to ports, creating rules, and adding resources to a backend pool.
This quickstart shows you how to use the Azure portal to quickly create the application gateway with two virtual
machines in its backend pool. You then test it to make sure it's working correctly.
If you don't have an Azure subscription, create a free account before you begin.
Log in to Azure
Log in to the Azure portal at http://portal.azure.com
Create an application gateway

You need to create a virtual network for the application gateway to be able to communicate with other resources.
You can create a virtual network at the same time that you create the application gateway. Two subnets are created
in this example: one for the application gateway, and the other for the virtual machines.
1. Click Create a resource found on the upper left-hand corner of the Azure portal.
2. Select Networking and then select Application Gateway in the Featured list.
3. Enter these values for the application gateway:
myAppGateway - for the name of the application gateway.
myResourceGroupAG - for the new resource group.
4. Accept the default values for the other settings and then click OK.
5. Click Choose a virtual network > Create new, and then enter these values for the virtual network:
myVNet - for the name of the virtual network.
10.0.0.0/16 - for the virtual network address space.
myAGSubnet - for the subnet name.
10.0.0.0/24 - for the subnet address space.
6. Click OK to create the virtual network and subnet.

7. Click Choose a public IP address > Create new, and then enter the name of the public IP address. In this
example, the public IP address is named myAGPublicIPAddress. Accept the default values for the other settings
and then click OK.
8. Accept the default values for the listener configuration, leave the web application firewall disabled, and then
click OK.
9. Review the settings on the summary page, and then click OK to create the virtual network, the public IP
address, and the application gateway. It may take up to 30 minutes for the application gateway to be created,
wait until the deployment finishes successfully before moving on to the next section.
Add a subnet
1. Click All resources in the left-hand menu, and then click myVNet from the resources list.
2. Click Subnets > Subnet.
3. Enter myBackendSubnet for the name of the subnet and then click OK.
Create backend servers

In this example, you create two virtual machines to be used as backend servers for the application gateway.
Create a virtual machine
1. Click New.
2. Select Compute and then select Windows Server 2016 Datacenter in the Featured list.
3. Enter these values for the virtual machine:
myVM - for the name of the virtual machine.
azureuser - for the administrator user name.
Azure123456! for the password.
Select Use existing, and then select myResourceGroupAG.
4. Click OK.
5. Select DS1_V2 for the size of the virtual machine and then click Select.
6. Make sure that myVNet is selected for the virtual network and the subnet is myBackendSubnet.
7. Click Disabled to disable boot diagnostics.
8. Click OK, review the settings on the summary page, and then click Create.
Install IIS
You install IIS on the virtual machines to verify that the application gateway was successfully created.
1. Open the interactive shell and make sure that it is set to PowerShell.
2. Run the following command to install IIS on the virtual machine:
Set-AzureRmVMExtension `
-ResourceGroupName myResourceGroupAG `
-ExtensionName IIS `
-VMName myVM `
-Publisher Microsoft.Compute `
-ExtensionType CustomScriptExtension `
-TypeHandlerVersion 1.4 `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell Add-Content
-Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}' `
-Location EastUS
3. Create a second virtual machine and install IIS using the steps that you just finished. Enter myVM2 for its
name and for VMName in Set-AzureRmVMExtension.
Add backend servers
After you create the virtual machines, you need to add them to the backend pool in the application gateway.
1. Click All resources > myAppGateway.
2. Click Backend pools. A default pool was automatically created with the application gateway. Click
appGatewayBackendPool.
3. Click Add target > Virtual machine, and then select myVM. Select Add target > Virtual machine, and
then select myVM2.
4. Click Save.
Test the application gateway

Installing IIS is not required to create the application gateway, but you installed it in this quickstart to verify
whether the application gateway was successfully created.
1. Find the public IP address for the application gateway on the Overview screen. Click All resources >
myAGPublicIPAddress.
2. Copy the public IP address, and then paste it into the address bar of your browser.
When you refresh the browser, you should see the name of the other VM appear.
Clean up resources
First explore the resources that were created with the application gateway, and then when no longer needed, you
can delete the resource group, application gateway, and all related resources. To do so, select the resource group
that contains the application gateway and click Delete.
Next steps
Manage web traffic with an application gateway using the Azure CLI
Gateway - Azure PowerShell
This quickstart shows you how to use the Azure portal to quickly create the application gateway with two virtual
Launch Azure Cloud Shell

The Azure Cloud Shell is a free interactive shell that you can use to run the steps in this article. It has common
Azure tools preinstalled and configured to use with your account. Just click the Copy to copy the code, paste it into
the Cloud Shell, and then press enter to run it. There are a few ways to launch the Cloud Shell:
Click Try It in the upper right corner of a code block.
Open Cloud Shell in your browser.
Click the Cloud Shell button on the menu in the upper right
of the Azure portal.
If you choose to install and use the PowerShell locally, this tutorial requires the Azure PowerShell module version
3.6 or later. To find the version, run Get-Module -ListAvailable AzureRM . If you need to upgrade, see Install Azure
PowerShell module. If you are running PowerShell locally, you also need to run Login-AzureRmAccount to create a
connection with Azure.
Create a resource group

You need to always create resources in a resource group. Create an Azure resource group using New -
AzureRmResourceGroup.
New-AzureRmResourceGroup -Name myResourceGroupAG -Location eastus
Create network resources

Two subnets are created in this example: one for the application gateway, and the other for the backend servers.
Create the subnet configurations using New -AzureRmVirtualNetworkSubnetConfig. Create the virtual network
using New -AzureRmVirtualNetwork with the subnet configurations. And finally, create the public IP address using
New -AzureRmPublicIpAddress.
$backendSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myAGSubnet `
-AddressPrefix 10.0.1.0/24
$agSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
New-AzureRmVirtualNetwork `
-Location eastus `
-Name myVNet `
-AddressPrefix 10.0.0.0/16 `
-Subnet $backendSubnetConfig, $agSubnetConfig
New-AzureRmPublicIpAddress `
-Location eastus `
-Name myAGPublicIPAddress `
-AllocationMethod Dynamic

You also install IIS on the virtual machines to verify that the application gateway was successfully created.
Create two virtual machines
Create a network interface with New -AzureRmNetworkInterface. Create a virtual machine configuration with
New -AzureRmVMConfig. When you run the following commands, you are prompted for credentials. Enter
azureuser for the user name and Azure123456! for the password. Create the virtual machine with New -
AzureRmVM.
$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName myResourceGroupAG -Name myVNet
$cred = Get-Credential
for ($i=1; $i -le 2; $i++)
{
$nic = New-AzureRmNetworkInterface `
-Name myNic$i `
-Location EastUS `
-SubnetId $vnet.Subnets[1].Id
$vm = New-AzureRmVMConfig `
-VMName myVM$i `
-VMSize Standard_DS2
$vm = Set-AzureRmVMOperatingSystem `
-VM $vm `
-Windows `
-ComputerName myVM$i `
-Credential $cred
$vm = Set-AzureRmVMSourceImage `
-VM $vm `
-PublisherName MicrosoftWindowsServer `
-Offer WindowsServer `
-Skus 2016-Datacenter `
-Version latest
$vm = Add-AzureRmVMNetworkInterface `
-VM $vm `
-Id $nic.Id
$vm = Set-AzureRmVMBootDiagnostics `
-VM $vm `
-Disable
New-AzureRmVM -ResourceGroupName myResourceGroupAG -Location EastUS -VM $vm
-VMName myVM$i `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell Add-Content -
Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}' `
-Location EastUS
}

Create the IP configurations and frontend port
Use New -AzureRmApplicationGatewayIPConfiguration to create the configuration that associates the subnet that
you previously created with the application gateway. Use New -AzureRmApplicationGatewayFrontendIPConfig to
create the configuration that assigns the public IP address that you also previously created to the application
gateway. Use New -AzureRmApplicationGatewayFrontendPort to assign port 80 to be used to access the
application gateway.
$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName myResourceGroupAG -Name myVNet
$pip = Get-AzureRmPublicIPAddress -ResourceGroupName myResourceGroupAG -Name myAGPublicIPAddress
$subnet=$vnet.Subnets[0]
$gipconfig = New-AzureRmApplicationGatewayIPConfiguration `
-Name myAGIPConfig `
-Subnet $subnet
$fipconfig = New-AzureRmApplicationGatewayFrontendIPConfig `
-Name myAGFrontendIPConfig `
-PublicIPAddress $pip
$frontendport = New-AzureRmApplicationGatewayFrontendPort `
-Name myFrontendPort `
-Port 80
Create the backend pool

Use New -AzureRmApplicationGatewayBackendAddressPool to create the backend pool for the application
gateway. Configure the settings for the backend pool using New -
AzureRmApplicationGatewayBackendHttpSettings.
$address1 = Get-AzureRmNetworkInterface -ResourceGroupName myResourceGroupAG -Name myNic1

$address2 = Get-AzureRmNetworkInterface -ResourceGroupName myResourceGroupAG -Name myNic2
$backendPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name myAGBackendPool `
-BackendIPAddresses $address1.ipconfigurations[0].privateipaddress,
$address2.ipconfigurations[0].privateipaddress
$poolSettings = New-AzureRmApplicationGatewayBackendHttpSettings `
-Name myPoolSettings `
-Port 80 `
-Protocol Http `
-CookieBasedAffinity Enabled `
-RequestTimeout 120
Create the listener and add a rule

A listener is required to enable the application gateway to route traffic appropriately to the backend pool. Create a
listener using New -AzureRmApplicationGatewayHttpListener with the frontend configuration and frontend port
that you previously created. A rule is required for the listener to know which backend pool to use for incoming
traffic. Use New -AzureRmApplicationGatewayRequestRoutingRule to create a rule named rule1.
$defaultlistener = New-AzureRmApplicationGatewayHttpListener `
-Name myAGListener `
-Protocol Http `
-FrontendIPConfiguration $fipconfig `
-FrontendPort $frontendport
$frontendRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name rule1 `
-RuleType Basic `
-HttpListener $defaultlistener `
-BackendAddressPool $backendPool `
-BackendHttpSettings $poolSettings
Create the application gateway

Now that you created the necessary supporting resources, use New -AzureRmApplicationGatewaySku to specify
parameters for the application gateway, and then use New -AzureRmApplicationGateway to create it.
$sku = New-AzureRmApplicationGatewaySku `
-Name Standard_Medium `
-Tier Standard `
-Capacity 2
New-AzureRmApplicationGateway `
-Name myAppGateway `
-Location eastus `
-BackendAddressPools $backendPool `
-BackendHttpSettingsCollection $poolSettings `
-FrontendIpConfigurations $fipconfig `
-GatewayIpConfigurations $gipconfig `
-FrontendPorts $frontendport `
-HttpListeners $defaultlistener `
-RequestRoutingRules $frontendRule `
-Sku $sku

Installing IIS is not required to create the application gateway, but you installed it in this quickstart to verify
whether the application gateway was successfully created. Use Get-AzureRmPublicIPAddress to get the public IP
address of the application gateway. Copy the public IP address, and then paste it into the address bar of your
browser.
Get-AzureRmPublicIPAddress -ResourceGroupName myResourceGroupAG -Name myAGPublicIPAddress
Clean up resources
can use the Remove-AzureRmResourceGroup command to remove the resource group, application gateway, and
all related resources.
Remove-AzureRmResourceGroup -Name myResourceGroupAG
Next steps
Manage web traffic with an application gateway using Azure PowerShell
Gateway - Azure CLI
This quickstart shows you how to use the Azure CLI to quickly create the application gateway with two virtual
Open Azure Cloud Shell

Azure Cloud Shell is a free, interactive shell that you can use to run the steps in this article. Common Azure tools
are preinstalled and configured in Cloud Shell for you to use with your account. Just select the Copy button to
copy the code, paste it in Cloud Shell, and then press Enter to run it. There are a few ways to open Cloud Shell:
Select Try It in the upper-right corner of a code block.
Select the Cloud Shell button on the menu in the upper-right

corner of the Azure portal.
If you choose to install and use the CLI locally, this quickstart requires that you run the Azure CLI version 2.0.4 or
later. To find the version, run az --version . If you need to install or upgrade, see Install Azure CLI 2.0.

You need to always create resources in a resource group. Create a resource group using az group create.
The following example creates a resource group named myResourceGroupAG in the eastus location.
az group create --name myResourceGroupAG --location eastus

You can create a virtual network at the same time that you create the application gateway. Two subnets are created
in this example: one for the application gateway, and the other for the virtual machines.
Create the virtual network and subnet using az network vnet create. Create the public IP address using az network
public-ip create.
az network vnet create \
--name myVNet \
--resource-group myResourceGroupAG \
--location eastus \
--address-prefix 10.0.0.0/16 \
--subnet-name myAGSubnet \
--subnet-prefix 10.0.1.0/24
az network vnet subnet create \
--name myBackendSubnet \
--vnet-name myVNet \
--address-prefix 10.0.2.0/24
az network public-ip create \
--name myAGPublicIPAddress

Create two virtual machines
You also install NGINX on the virtual machines to verify that the application gateway was successfully created. You
can use a cloud-init configuration file to install NGINX and run a 'Hello World' Node.js app on a Linux virtual
machine.
In your current shell, create a file named cloud-init.txt and copy and paste the following configuration into the shell.
Make sure that you copy the whole cloud-init file correctly, especially the first line:
#cloud-config
package_upgrade: true
packages:
- nginx
- nodejs
- npm
write_files:
- owner: www-data:www-data
- path: /etc/nginx/sites-available/default
content: |
server {
listen 80;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
- owner: azureuser:azureuser
- path: /home/azureuser/myapp/index.js
content: |
var express = require('express')
var app = express()
var os = require('os');
app.get('/', function (req, res) {
res.send('Hello World from host ' + os.hostname() + '!')
})
app.listen(3000, function () {
console.log('Hello world app listening on port 3000!')
})
runcmd:
- service nginx restart
- cd "/home/azureuser/myapp"
- npm init
- npm install express -y
- nodejs index.js
Create the network interfaces with az network nic create. Create the virtual machines with az vm create.
for i in `seq 1 2`; do

az network nic create \
--name myNic$i \
--subnet myBackendSubnet
az vm create \
--name myVM$i \
--nics myNic$i \
--image UbuntuLTS \
--admin-username azureuser \
--generate-ssh-keys \
--custom-data cloud-init.txt
done

Create an application gateway using az network application-gateway create. When you create an application
gateway using the Azure CLI, you specify configuration information, such as capacity, sku, and HTTP settings. The
private IP addresses of the network interfaces are added as servers in the backend pool of the 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 \
--capacity 2 \
--sku Standard_Medium \
--http-settings-cookie-based-affinity Enabled \
--public-ip-address myAGPublicIPAddress \
--subnet myAGSubnet \
--servers "$address1" "$address2"
It may take up to 30 minutes for the application gateway to be created. After the application gateway is created,
you can see these features of it:
appGatewayBackendPool - An application gateway must have at least one backend address pool.
appGatewayBackendHttpSettings - Specifies that port 80 and an HTTP protocol is used for communication.
appGatewayHttpListener - The default listener associated with appGatewayBackendPool.
appGatewayFrontendIP - Assigns myAGPublicIPAddress to appGatewayHttpListener.
rule1 - The default routing rule that is associated with appGatewayHttpListener.

Installing NGINX is not required to create the application gateway, but you installed it in this quickstart to verify
whether the application gateway was successfully created. To get the public IP address of the application gateway,
use az network public-ip show. Copy the public IP address, and then paste it into the address bar of your browser.
az network public-ip show \

--name myAGPublicIPAddress \
--query [ipAddress] \
--output tsv
Clean up resources
can use the az group delete command to remove the resource group, application gateway, and all related
resources.
az group delete --name myResourceGroupAG
Next steps
Manage web traffic with an application gateway using the Azure CLI
Tutorial: Manage web traffic with an application
gateway using the Azure CLI
Application gateway is used to manage and secure web traffic to servers that you maintain. You can use the Azure
CLI to create an application gateway that uses a virtual machine scale set for backend servers to manage web
traffic. In this example, the scale set contains two virtual machine instances that are added to the default backend
pool of the application gateway.
In this tutorial, you learn how to:
Set up the network
Create a virtual machine scale set with the default backend pool
If you prefer, you can complete this tutorial using Azure PowerShell.


If you choose to install and use the CLI locally, this quickstart requires that you are running the Azure CLI version
2.0.4 or later. To find the version, run az --version . If you need to install or upgrade, see Install Azure CLI 2.0.

A resource group is a logical container into which Azure resources are deployed and managed. Create a resource
group using az group create.

Create the virtual network named myVNet and the subnet named myAGSubnet using az network vnet create. You
can then add the subnet named myBackendSubnet that's needed by the backend servers using az network vnet
subnet create. Create the public IP address named myAGPublicIPAddress using az network public-ip create.

--name myVNet \
--location eastus \



Use az network application-gateway create to create the application gateway named myAppGateway. When you
create an application gateway using the Azure CLI, you specify configuration information, such as capacity, sku,
and HTTP settings. The application gateway is assigned to myAGSubnet and myPublicIPSddress that you
previously created.

--location eastus \
--subnet myAGsubnet \
--capacity 2 \
--http-settings-cookie-based-affinity Disabled \
--frontend-port 80 \
--http-settings-port 80 \
--http-settings-protocol Http \
--public-ip-address myAGPublicIPAddress
It may take several minutes for the application gateway to be created. After the application gateway is created, you
will see these new features:
Create a Virtual Machine Scale Set

In this example, you create a virtual machine scale set that provides servers for the backend pool in the application
gateway. The virtual machines in the scale set are associated with myBackendSubnet and
appGatewayBackendPool. To create the scale set, use az vmss create.
az vmss create \
--name myvmss \
--image UbuntuLTS \
--admin-password Azure123456! \
--instance-count 2 \
--subnet myBackendSubnet \
--vm-sku Standard_DS2 \
--upgrade-policy-mode Automatic \
--app-gateway myAppGateway \
--backend-pool-name appGatewayBackendPool
Install NGINX
Now you can install NGINX on the virtual machine scale set so you can test HTTP connectivity to the backend
pool.
az vmss extension set \

--publisher Microsoft.Azure.Extensions \
--version 2.0 \
--name CustomScript \
--vmss-name myvmss \
--settings '{ "fileUris": ["https://raw.githubusercontent.com/Azure/azure-docs-powershell-
samples/master/application-gateway/iis/install_nginx.sh"], "commandToExecute": "./install_nginx.sh" }'

To get the public IP address of the application gateway, use az network public-ip show. Copy the public IP address,
and then paste it into the address bar of your browser.

--output tsv
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources.
az group delete --name myResourceGroupAG --location eastus
Next steps
In this tutorial, you learned how to:
Set up the network
Restrict web traffic with a web application firewall
Tutorial: Enable web application firewall using the
Azure CLI
You can restrict traffic on an application gateway with a web application firewall (WAF ). The WAF uses OWASP
rules to protect your application. These rules include protection against attacks such as SQL injection, cross-site
scripting attacks, and session hijacks.
Set up the network
Create an application gateway with WAF enabled
Create a virtual machine scale set
Create a storage account and configure diagnostics


If you choose to install and use the CLI locally, this tutorial requires that you are running the Azure CLI version

A resource group is a logical container into which Azure resources are deployed and managed. Create an Azure
resource group named myResourceGroupAG with az group create.

The virtual network and subnets are used to provide network connectivity to the application gateway and its
associated resources. Create the virtual network named myVNet and subnet named myAGSubnet with az network
vnet create and az network vnet subnet create. Create a public IP address named myAGPublicIPAddress with az
network public-ip create.

--name myVNet \
--location eastus \
--subnet-name myBackendSubnet \

--name myAGSubnet \

Create an application gateway with a WAF

You can use az network application-gateway create to create the application gateway named myAppGateway.
When you create an application gateway using the Azure CLI, you specify configuration information, such as
capacity, sku, and HTTP settings. The application gateway is assigned to myAGSubnet and myPublicIPSddress that
you previously created.

--location eastus \
--subnet myAGSubnet \
--capacity 2 \
--sku WAF_Medium \
az network application-gateway waf-config set \

--enabled true \
--gateway-name myAppGateway \
--firewall-mode Detection \
--rule-set-version 3.0
can see these new features of it:

In this example, you create a virtual machine scale set that provides two servers for the backend pool in the
application gateway. The virtual machines in the scale set are associated with the myBackendSubnet subnet. To
create the scale set, you can use az vmss create.
az vmss create \
--name myvmss \
--image UbuntuLTS \
Install NGINX

--version 2.0 \
samples/master/application-gateway/iis/install_nginx.sh"],"commandToExecute": "./install_nginx.sh" }'

In this tutorial, the application gateway uses a storage account to store data for detection and prevention purposes.
You could also use Log Analytics or Event Hub to record data.
Create a storage account
Create a storage account named myagstore1 with az storage account create.
az storage account create \

--name myagstore1 \
--location eastus \
--sku Standard_LRS \
--encryption blob
Configure diagnostics
Configure diagnostics to record data into the ApplicationGatewayAccessLog, ApplicationGatewayPerformanceLog,
and ApplicationGatewayFirewallLog logs. Substitute <subscriptionId> with your subscription identifier and then
configure diagnostics with az monitor diagnostic-settings create.
appgwid=$(az network application-gateway show --name myAppGateway --resource-group myResourceGroupAG --query

id -o tsv)
storeid=$(az storage account show --name myagstore1 --resource-group myResourceGroupAG --query id -o tsv)
az monitor diagnostic-settings create --name appgwdiag --resource $appgwid \

--logs '[ { "category": "ApplicationGatewayAccessLog", "enabled": true, "retentionPolicy": { "days": 30,
"enabled": true } }, { "category": "ApplicationGatewayPerformanceLog", "enabled": true, "retentionPolicy": {
"days": 30, "enabled": true } }, { "category": "ApplicationGatewayFirewallLog", "enabled": true,
"retentionPolicy": { "days": 30, "enabled": true } } ]' \
--storage-account $storeid

and then paste it into the address bar of your browser.

--output tsv
Clean up resources
Next steps
Set up the network
Create an application gateway with SSL termination
Tutorial: Create an application gateway with SSL
termination using the Azure CLI
You can use the Azure CLI to create an application gateway with a certificate for SSL termination that uses a
virtual machine scale set for backend servers. In this example, the scale set contains two virtual machine instances
that are added to the default backend pool of the application gateway.
Create a self-signed certificate
Set up a network
Create an application gateway with the certificate


If you choose to install and use the CLI locally, this tutorial requires you to run the Azure CLI version 2.0.4 or later.
To find the version, run az --version . If you need to install or upgrade, see Install Azure CLI 2.0.

For production use, you should import a valid certificate signed by trusted provider. For this tutorial, you create a
self-signed certificate and pfx file using the openssl command.
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out appgwcert.crt
Enter values that make sense for your certificate. You can accept the default values.
openssl pkcs12 -export -out appgwcert.pfx -inkey privateKey.key -in appgwcert.crt

Enter the password for the certificate. In this example, Azure123456! is being used.



--name myVNet \
--location eastus \



You can use az network application-gateway create to create the application gateway. When you create an
application gateway using the Azure CLI, you specify configuration information, such as capacity, sku, and HTTP
settings.
The application gateway is assigned to myAGSubnet and myAGPublicIPAddress that you previously created. In
this example, you associate the certificate that you created and its password when you create the application
gateway.
--location eastus \
--capacity 2 \
--cert-file appgwcert.pfx \
--cert-password "Azure123456!"

In this example, you create a virtual machine scale set that provides servers for the default backend pool in the
application gateway. The virtual machines in the scale set are associated with myBackendSubnet and
appGatewayBackendPool. To create the scale set, you can use az vmss create.
az vmss create \
--name myvmss \
--image UbuntuLTS \
Install NGINX

--version 2.0 \
samples/master/application-gateway/iis/install_nginx.sh"],
"commandToExecute": "./install_nginx.sh" }'

To get the public IP address of the application gateway, you can use az network public-ip show. Copy the public IP
address, and then paste it into the address bar of your browser.

--output tsv
To accept the security warning if you used a self-signed certificate, select Details and then Go on to the
webpage. Your secured NGINX site is then displayed as in the following example:
Clean up resources
Next steps
Set up a network
Create an application gateway that hosts multiple web sites
Tutorial: Create an application gateway that hosts
multiple web sites using the Azure CLI
You can use the Azure CLI to configure the hosting of multiple web sites when you create an application gateway.
In this tutorial, you define backend address pools using virtual machines scale sets. You then configure listeners
and rules based on domains that you own to make sure web traffic arrives at the appropriate servers in the pools.
This tutorial assumes that you own multiple domains and uses examples of www.contoso.com and
www.fabrikam.com.
Set up the network
Create backend listeners
Create routing rules
Create virtual machine scale sets with the backend pools
Create a CNAME record in your domain




Create the virtual network and the subnet named myAGSubnet using az network vnet create. You can then add the
subnet that's needed by the backend servers using az network vnet subnet create. Create the public IP address
named myAGPublicIPAddress using az network public-ip create.

--name myVNet \
--location eastus \



You can use az network application-gateway create to create the application gateway. When you create an
application gateway using the Azure CLI, you specify configuration information, such as capacity, sku, and HTTP
settings. The application gateway is assigned to myAGSubnet and myAGPublicIPAddress that you previously
created.

--location eastus \
--capacity 2 \
Add the backend pools
Add the backend pools that are needed to contain the backend servers using az network application-gateway
address-pool create.
az network application-gateway address-pool create \

--name contosoPool

--name fabrikamPool
Add backend listeners

Add the backend listeners that are needed to route traffic using az network application-gateway http-listener
create.
az network application-gateway http-listener create \

--name contosoListener \
--frontend-ip appGatewayFrontendIP \
--frontend-port appGatewayFrontendPort \
--host-name www.contoso.com

--name fabrikamListener \
--host-name www.fabrikam.com
Add routing rules

Rules are processed in the order they are listed, and traffic is directed using the first rule that matches regardless of
specificity. For example, if you have a rule using a basic listener and a rule using a multi-site listener both on the
same port, the rule with the multi-site listener must be listed before the rule with the basic listener in order for the
multi-site rule to function as expected.
In this example, you create two new rules and delete the default rule that was created when you created the
application gateway. You can add the rule using az network application-gateway rule create.
az network application-gateway rule create \
--name contosoRule \
--http-listener contosoListener \
--rule-type Basic \
--address-pool contosoPool

--name fabrikamRule \
--http-listener fabrikamListener \
--rule-type Basic \
--address-pool fabrikamPool
az network application-gateway rule delete \

--name rule1 \
--resource-group myResourceGroupAG
Create virtual machine scale sets

In this example, you create three virtual machine scale sets that support the three backend pools in the application
gateway. The scale sets that you create are named myvmss1, myvmss2, and myvmss3. Each scale set contains two
virtual machine instances on which you install IIS.
if [ $i -eq 1 ]
then
poolName="contosoPool"
fi
if [ $i -eq 2 ]
then
poolName="fabrikamPool"
fi
az vmss create \
--name myvmss$i \
--image UbuntuLTS \
--backend-pool-name $poolName
done
Install NGINX

--version 2.0 \
--vmss-name myvmss$i \
done

After the application gateway is created with its public IP address, you can get the DNS address and use it to create
a CNAME record in your domain. You can use az network public-ip show to get the DNS address of the
application gateway. Copy the fqdn value of the DNSSettings and use it as the value of the CNAME record that
you create.

--query [dnsSettings.fqdn] \
--output tsv
The use of A-records is not recommended because the VIP may change when the application gateway is restarted.

Enter your domain name into the address bar of your browser. Such as, http://www.contoso.com.
Change the address to your other domain and you should see something like the following example:
Clean up resources

Next steps
Set up the network
Create an application gateway with URL path-based routing rules
Tutorial: Route web traffic based on the URL using
the Azure CLI
You can use Azure CLI to configure web traffic routing to specific scalable server pools based on the URL that is
used to access your application. In this tutorial, you create an Azure Application Gateway with three backend pools
using Virtual Machine Scale Sets. Each of the backend pools serves a specific purpose such as, common data,
images, and video. Routing traffic to separate pools ensures that your customers get the information that they
need when they need it.
To enable traffic routing, you create routing rules assigned to listeners that listen on specific ports to ensure web
traffic arrives at the appropriate servers in the pools.
Set up the network
Create listeners, URL path map, and rules
Create scalable backend pools


If you choose to install and use the CLI locally, this tutorial requires you to run the Azure CLI version 2.0.4 or later.
To find the version, run az --version . If you need to install or upgrade, see Install Azure CLI 2.0.

A resource group is a logical container where Azure resources are deployed and managed. Create a resource

Create the virtual network named myVNet and the subnet named myAGSubnet using az network vnet create.
Then add a subnet named myBackendSubnet that's needed by the backend servers using az network vnet subnet
create. Create the public IP address named myAGPublicIPAddress using az network public-ip create.

--name myVNet \
--location eastus \


Create the application gateway with URL map

Use az network application-gateway create to create an application gateway named myAppGateway. When you
and HTTP settings. The application gateway is assigned to myAGSubnet and myAGPublicIPAddress that you
previously created.

--location eastus \
--capacity 2 \
It may take several minutes to create the application gateway. After the application gateway is created, you can see
these new features:
Add image and video backend pools and port
Add backend pools named imagesBackendPool and videoBackendPool to your application gateway by using az
network application-gateway address-pool create. You add the frontend port for the pools using az network
application-gateway frontend-port create.

--name imagesBackendPool

--name videoBackendPool
az network application-gateway frontend-port create \

--port 8080 \
--name port8080
Add backend listener

Add the backend listener named backendListener that's needed to route traffic using az network application-
gateway http-listener create.

--name backendListener \
--frontend-port port8080 \
--gateway-name myAppGateway
Add URL path map

URL path maps ensure that specific URLs are routed to specific backend pools. Create URL path maps named
imagePathRule and videoPathRule using az network application-gateway url-path-map create and az network
application-gateway url-path-map rule create
az network application-gateway url-path-map create \
--name myPathMap \
--paths /images/* \
--address-pool imagesBackendPool \
--default-address-pool appGatewayBackendPool \
--default-http-settings appGatewayBackendHttpSettings \
--http-settings appGatewayBackendHttpSettings \
--rule-name imagePathRule
az network application-gateway url-path-map rule create \

--name videoPathRule \
--path-map-name myPathMap \
--paths /video/* \
--address-pool videoBackendPool
Add routing rule

The routing rule associates the URL maps with the listener that you created. Add a rule named rule2 using az
network application-gateway rule create.

--name rule2 \
--http-listener backendListener \
--rule-type PathBasedRouting \
--url-path-map myPathMap \
--address-pool appGatewayBackendPool

In this tutorial, you create three virtual machine scale sets that support the three backend pools you created. You
create scale sets named myvmss1, myvmss2, and myvmss3. Each scale set contains two virtual machine instances
where you install NGINX.
if [ $i -eq 1 ]
then
poolName="appGatewayBackendPool"
fi
if [ $i -eq 2 ]
then
poolName="imagesBackendPool"
fi
if [ $i -eq 3 ]
then
poolName="videoBackendPool"
fi
az vmss create \
--name myvmss$i \
--image UbuntuLTS \
done
Install NGINX

--version 2.0 \
done

and then paste it into the address bar of your browser. Such as, http://40.121.222.19,
http://40.121.222.19:8080/images/test.htm, or http://40.121.222.19:8080/video/test.htm.

--output tsv
Change the URL to http://<ip-address>:8080/images/test.html, substituting your IP address for <ip-address>, and
you should see something like the following example:
Change the URL to http://<ip-address>:8080/video/test.html, substituting your IP address for <ip-address>, and
you should see something like the following example.
Clean up resources
Next steps
Set up the network
Create an application gateway with URL path-based redirection
Tutorial: Create an application gateway with URL
path-based redirection using the Azure CLI
You can use the Azure CLI to configure URL path-based routing rules when you create an application gateway. In
this tutorial, you create backend pools using virtual machine scale sets. You then create URL routing rules that
make sure web traffic is redirected to the appropriate backend pool.
Set up the network
Add listeners and routing rules
Create virtual machine scale sets for backend pools
The following example shows site traffic coming from both ports 8080 and 8081 and being directed to the same
backend pools:





--name myVNet \
--location eastus \



Use az network application-gateway create to create the application gateway named myAppGateway. When you
and HTTP settings. The application gateway is assigned to myAGSubnet and myPublicIPSddress that you
previously created.

--location eastus \
--capacity 2 \
can see these new features:
Add backend pools and ports
You can add backend address pools named imagesBackendPool and videoBackendPool to your application
gateway by using az network application-gateway address-pool create. You add the frontend ports for the pools
using az network application-gateway frontend-port create.

--name imagesBackendPool

--name videoBackendPool

--port 8080 \
--name bport

--port 8081 \
--name rport
Add listeners and rules

Add listeners
Add the backend listeners named backendListener and redirectedListener that are needed to route traffic using az
network application-gateway http-listener create.

--name backendListener \
--frontend-port bport \

--name redirectedListener \
--frontend-port rport \
Add the default URL path map

URL path maps make sure that specific URLs are routed to specific backend pools. You can create URL path maps
named imagePathRule and videoPathRule using az network application-gateway url-path-map create and az
network application-gateway url-path-map rule create

--name urlpathmap \
--paths /images/* \
--address-pool imagesBackendPool \
--default-address-pool appGatewayBackendPool \
--default-http-settings appGatewayBackendHttpSettings \
--http-settings appGatewayBackendHttpSettings \
--rule-name imagePathRule
az network application-gateway url-path-map rule create \

--name videoPathRule \
--path-map-name urlpathmap \
--paths /video/* \
--address-pool videoBackendPool
Add redirection configuration

You can configure redirection for the listener using az network application-gateway redirect-config create.
az network application-gateway redirect-config create \

--name redirectConfig \
--type Found \
--include-path true \
--include-query-string true \
--target-listener backendListener
Add the redirection URL path map

--name redirectpathmap \
--paths /images/* \
--redirect-config redirectConfig \
--rule-name redirectPathRule
Add routing rules

The routing rules associate the URL path maps with the listeners that you created. You can add the rules named
defaultRule and redirectedRule using az network application-gateway rule create.
--name defaultRule \
--http-listener backendListener \
--url-path-map urlpathmap \

--name redirectedRule \
--http-listener redirectedListener \
--url-path-map redirectpathmap \

In this example, you create three virtual machine scale sets that support the three backend pools that you created.
The scale sets that you create are named myvmss1, myvmss2, and myvmss3. Each scale set contains two virtual
machine instances on which you install NGINX.

if [ $i -eq 1 ]
then
poolName="appGatewayBackendPool"
fi
if [ $i -eq 2 ]
then
poolName="imagesBackendPool"
fi
if [ $i -eq 3 ]
then
poolName="videoBackendPool"
fi
az vmss create \
--name myvmss$i \
--image UbuntuLTS \
done
Install NGINX
--version 2.0 \
done

and then paste it into the address bar of your browser. Such as, http://40.121.222.19,
http://40.121.222.19:8080/images/test.htm, http://40.121.222.19:8080/video/test.htm, or
http://40.121.222.19:8081/images/test.htm.

--output tsv
Change the URL to http://<ip-address>:8080/images/test.html, substituting your IP address for <ip-address>, and
Change the URL to http://<ip-address>:8080/video/test.html, substituting your IP address for <ip-address>, and
Now, change the URL to http://<ip-address>:8081/images/test.htm, substituting your IP address for <ip-
address>, and you should see traffic redirected back to the images backend pool at http://<ip-
address>:8080/images.
Clean up resources
Next steps
Set up the network
Learn more about what you can do with application gateway
Azure Application Gateway PowerShell samples
The following table includes links to Azure PowerShell script samples that create application gateways.
Manage web traffic Creates an application gateway and all related resources.
Restrict web traffic Creates an application gateway that restricts traffic using
OWASP rules.
Azure Application Gateway Azure CLI samples
The following table includes links to Azure CLI script samples that create application gateways.
Manage web traffic Creates an application gateway and all related resources.
Restrict web traffic Creates an application gateway that restricts traffic using
OWASP rules.
Overview of end to end SSL with Application
Gateway
Application gateway supports SSL termination at the gateway, after which traffic typically flows unencrypted to
the backend servers. This feature allows web servers to be unburdened from costly encryption and decryption
overhead. However for some customers unencrypted communication to the backend servers is not an acceptable
option. This unencrypted communication could be due to security requirements, compliance requirements, or the
application may only accept a secure connection. For such applications, application gateway supports end to end
SSL encryption.
Overview
End to end SSL allows you to securely transmit sensitive data to the backend encrypted while still taking
advantage of the benefits of Layer 7 load balancing features which application gateway provides. Some of these
features are cookie-based session affinity, URL -based routing, support for routing based on sites, or ability to
inject X-Forwarded-* headers.
When configured with end to end SSL communication mode, application gateway terminates the SSL sessions at
the gateway and decrypts user traffic. It then applies the configured rules to select an appropriate backend pool
instance to route traffic to. Application gateway then initiates a new SSL connection to the backend server and re-
encrypts data using the backend server's public key certificate before transmitting the request to the backend. End
to end SSL is enabled by setting protocol setting in BackendHTTPSetting to HTTPS, which is then applied to a
backend pool. Each backend server in the backend pool with end to end SSL enabled must be configured with a
certificate to allow secure communication.
In this example, requests using TLS1.2 are routed to backend servers in Pool1 using end to end SSL.
End to end SSL and whitelisting of certificates
Application gateway only communicates with known backend instances that have whitelisted their certificate with
the application gateway. To enable whitelisting of certificates, you must upload the public key of backend server
certificates to the application gateway (not the root certificate). Only connections to known and whitelisted
backends are then allowed. The remaining backends results in a gateway error. Self-signed certificates are for test
purposes only and not recommended for production workloads. Such certificates have to be whitelisted with the
application gateway as described in the preceding steps before they can be used.
Next steps
After learning about end to end SSL, go to Configure an application gateway with SSL termination using the
Azure portal to create an application gateway using end to end SSL.
Application Gateway SSL policy overview
You can use Azure Application Gateway to centralize SSL certificate management and reduce encryption and
decryption overhead from a back-end server farm. This centralized SSL handling also lets you specify a central
SSL policy that's suited to your organizational security requirements. This helps you meet compliance
requirements as well as security guidelines and recommended practices.
The SSL policy includes control of the SSL protocol version as well as the cipher suites and the order in which
ciphers are used during an SSL handshake. Application Gateway offers two mechanisms for controlling SSL policy.
You can use either a predefined policy or a custom policy.
Predefined SSL policy

Application Gateway has three predefined security policies. You can configure your gateway with any of these
policies to get the appropriate level of security. The policy names are annotated by the year and month in which
they were configured. Each policy offers different SSL protocol versions and cipher suites. We recommend that
you use the newest SSL policies to ensure the best SSL security.
AppGwSslPolicy20150501
PROPERTY VALUE
Name AppGwSslPolicy20150501
MinProtocolVersion TLSv1_0
Default True (if no predefined policy is specified)

PROPERTY VALUE
CipherSuites TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
AppGwSslPolicy20170401
PROPERTY VALUE
Name AppGwSslPolicy20170401
Default False
CipherSuites TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
AppGwSslPolicy20170401S
PROPERTY VALUE
Name AppGwSslPolicy20170401S
Default False
CipherSuites TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Custom SSL policy

If a predefined SSL policy needs to be configured for your requirements, you must define your own custom SSL
policy. With a custom SSL policy, you have complete control over the minimum SSL protocol version to support,
as well as the supported cipher suites and their priority order.
SSL protocol versions
SSL 2.0 and 3.0 are disabled by default for all application gateways. These protocol versions are not
configurable.
A custom SSL policy gives you the option to select any one of the following three protocols as the minimum
SSL protocol version for your gateway: TLSv1_0, TLSv1_1, and TLSv1_2.
If no SSL policy is defined, all three protocols (TLSv1_0, TLSv1_1, and TLSv1_2) are enabled.
Cipher suites
Application Gateway supports the following cipher suites from which you can choose your custom policy. The
ordering of the cipher suites determines the priority order during SSL negotiation.
Next steps
If you want to learn to configure an SSL policy, see Configure SSL policy on an application gateway.
Web application firewall (WAF)
Web application firewall (WAF ) is a feature of Application Gateway that provides centralized protection of your
web applications from common exploits and vulnerabilities.
Web application firewall is based on rules from the OWASP core rule sets 3.0 or 2.2.9. Web applications are
increasingly targets of malicious attacks that exploit common known vulnerabilities. Common among these
exploits are SQL injection attacks, cross site scripting attacks to name a few. Preventing such attacks in application
code can be challenging and may require rigorous maintenance, patching and monitoring at multiple layers of the
application topology. A centralized web application firewall helps make security management much simpler and
gives better assurance to application administrators against threats or intrusions. A WAF solution can also react to
a security threat faster by patching a known vulnerability at a central location versus securing each of individual
web applications. Existing application gateways can be converted to a web application firewall enabled application
gateway easily.
Application Gateway operates as an application delivery controller and offers SSL termination, cookie-based
session affinity, round-robin load distribution, content-based routing, ability to host multiple websites and security
enhancements. Security enhancements offered by Application Gateway include SSL policy management, end to
end SSL support. Application security is now strengthened by WAF (web application firewall) being directly
integrated into the ADC offering. This provides an easy to configure central location to manage and protect your
web applications against common web vulnerabilities.
Benefits
The following are the core benefits that Application Gateway and web application firewall provide:
Protection
Protect your web application from web vulnerabilities and attacks without modification to backend code.
Protect multiple web applications at the same time behind an application gateway. Application gateway
supports hosting up to 20 websites behind a single gateway that could all be protected against web attacks
with WAF.
Monitoring
Monitor your web application against attacks using a real-time WAF log. This log is integrated with Azure
Monitor to track WAF alerts and logs and easily monitor trends.
WAF will be integrated with Azure Security Center soon. Azure Security Center allows for a central view of
the security state of all your Azure resources.
Customization
The ability to customize WAF rules and rule groups to suit your application requirements and eliminate false
positives.
Features
Web application firewall comes preconfigured with CRS 3.0 by default or you can choose to use 2.2.9. CRS 3.0
offers reduced false positives over 2.2.9. The ability to customize rules to suit your needs is provided. Some of the
common web vulnerabilities which web application firewall protects against includes:
SQL injection protection
Cross site scripting protection
Common Web Attacks Protection such as command injection, HTTP request smuggling, HTTP response
splitting, and remote file inclusion attack
Protection against HTTP protocol violations
Protection against HTTP protocol anomalies such as missing host user-agent and accept headers
Prevention against bots, crawlers, and scanners
Detection of common application misconfigurations (i.e. Apache, IIS, etc.)
For a more detailed list of rules and their protections see the following Core rule sets.
Core rule sets
Application Gateway supports two rule sets, CRS 3.0, and CRS 2.2.9. These core rules sets are collections of rules
that protect your web applications for malicious activity.
OWASP_3.0
The 3.0 core rule set provided has 13 rule groups as shown in the following table. Each of these rule groups
contains multiple rules, which can be disabled.
RULEGROUP DESCRIPTION
REQUEST-911-METHOD-ENFORCEMENT Contains rules to lock down methods (PUT, PATCH< ..)
REQUEST-913-SCANNER-DETECTION Contains rules to protect against port and environment

scanners.
REQUEST-920-PROTOCOL-ENFORCEMENT Contains rules to protect against protocol and encoding

issues.
REQUEST-921-PROTOCOL-ATTACK Contains rules to protect against header injection, request

smuggling, and response splitting
REQUEST-930-APPLICATION-ATTACK-LFI Contains rules to protect against file and path attacks.

REQUEST-931-APPLICATION-ATTACK-RFI Contains rules to protect against Remote File Inclusion (RFI)
REQUEST-932-APPLICATION-ATTACK-RCE Contains rules to protect again Remote Code Execution.
REQUEST-933-APPLICATION-ATTACK-PHP Contains rules to protect against PHP injection attacks.
REQUEST-941-APPLICATION-ATTACK-XSS Contains rules for protecting against cross site scripting.
REQUEST-942-APPLICATION-ATTACK-SQLI Contains rules for protecting against SQL injection attacks.
REQUEST-943-APPLICATION-ATTACK-SESSION- Contains rules to protect against Session Fixation Attacks.

FIXATION
OWASP_2.2.9
The 2.2.9 core rule set provided has 10 rule groups as shown in the following table. Each of these rule groups
contains multiple rules, which can be disabled.
crs_20_protocol_violations Contains rules to protect against protocol violations (invalid

characters, GET with a request body, etc.)
crs_21_protocol_anomalies Contains rules to protect against incorrect header information.
crs_23_request_limits Contains rules to protect against arguments or files that

exceed limitations.
crs_30_http_policy Contains rules to protect against restricted methods, headers,

and file types.
crs_35_bad_robots Contains rules to protect against web crawlers and scanners.
crs_40_generic_attacks Contains rules to protect against generic attacks (session

fixation, remote file inclusion, PHP injection, etc.)
crs_41_sql_injection_attacks Contains rules to protect against SQL injection attacks
crs_41_xss_attacks Contains rules to protect against cross site scripting.
crs_42_tight_security Contains a rule to protect against path traversal attacks
crs_45_trojans Contains rules to protect against backdoor Trojans.
WAF Modes
Application Gateway WAF can be configured to run in the following two modes:
Detection mode – When configured to run in detection mode, Application Gateway WAF monitors and logs
all threat alerts in to a log file. Logging diagnostics for Application Gateway should be turned on using the
Diagnostics section. You also need to ensure that the WAF log is selected and turned on. When running in
detection mode web application firewall does not block incoming requests.
Prevention mode – When configured to run in prevention mode, Application Gateway actively blocks
intrusions and attacks detected by its rules. The attacker receives a 403 unauthorized access exception and the
connection is terminated. Prevention mode continues to log such attacks in the WAF logs.
WAF Monitoring
Monitoring the health of your application gateway is important. Monitoring the health of your web application
firewall and the applications that it protects are provided through logging and integration with Azure Monitor,
Azure Security Center (coming soon), and Log Analytics.
Azure Monitor
Each application gateway log is integrated with Azure Monitor. This allows you to track diagnostic information
including WAF alerts and logs. This capability is provided within the Application Gateway resource in the portal
under the Diagnostics tab or through the Azure Monitor service directly. To learn more about enabling diagnostic
logs for application gateway visit Application Gateway diagnostics
Azure Security Center
Azure Security Center helps you prevent, detect, and respond to threats with increased visibility into and control
over the security of your Azure resources. Application gateway now integrates into Azure Security Center. Azure
Security Center scans your environment to detect unprotected web applications. It can now recommend
application gateway WAF to protect these vulnerable resources. You can directly create application gateway WAF
from the Azure Security Center. These WAF instances are integrated with Azure Security Center and will send
alerts and health information back to Azure Security Center for reporting.
Logging
Application Gateway WAF provides detailed reporting on each threat it detects. Logging is integrated with Azure
Diagnostics logs and alerts are recorded in a json format. These logs can be integrated with Log Analytics.
{
"resourceId":
"/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupId}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEW
AYS/{appGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"time": "2017-03-20T15:52:09.1494499Z",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIp": "104.210.252.3",
"clientPort": "4835",
"requestUri": "/?a=%3Cscript%3Ealert(%22Hello%22);%3C/script%3E",
"ruleSetType": "OWASP",
"ruleSetVersion": "3.0",
"ruleId": "941320",
"message": "Possible XSS Attack Detected - HTML Tag Handler",
"action": "Blocked",
"site": "Global",
"details": {
"message": "Warning. Pattern match \"
<(a|abbr|acronym|address|applet|area|audioscope|b|base|basefront|bdo|bgsound|big|blackface|blink|blockquote|bo
dy|bq|br|button|caption|center|cite|code|col|colgroup|comment|dd|del|dfn|dir|div|dl|dt|em|embed|fieldset|fn|fo
nt|form|frame|frameset|h1|head|h ...\" at ARGS:a.",
"data": "Matched Data: <script> found within ARGS:a: <script>alert(\\x22hello\\x22);</script>",
"file": "rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf",
"line": "865"
}
}
}
Application Gateway WAF SKU pricing

Web application firewall is available under a new a WAF SKU. This SKU is available only in Azure Resource
Manager provisioning model and not under the classic deployment model. Additionally WAF SKU comes only in
medium and large application gateway instance sizes. All the limits for application gateway also apply to the WAF
SKU. Pricing is based on per hour gateway instance charge and data processing charge. Per hour gateway pricing
for WAF SKU is different from Standard SKU charges and can be found at Application Gateway pricing details.
Data processing charges remain the same. There is no per rule or rule group charges. You can protect multiple web
applications behind the same web application firewall and there are no additional charges for supporting multiple
applications.
Next steps
After learning more about the capabilities of WAF, visit How to configure web application firewall on Application
Gateway.
Azure Application Gatewaty URL path based routing
overview
URL Path Based Routing allows you to route traffic to back-end server pools based on URL Paths of the request.
One of the scenarios is to route requests for different content types to different backend server pools.
In the following example, Application Gateway is serving traffic for contoso.com from three back-end server pools
for example: VideoServerPool, ImageServerPool, and DefaultServerPool.
Requests for http://contoso.com/video/* are routed to VideoServerPool, and http://contoso.com/images/* are

routed to ImageServerPool. DefaultServerPool is selected if none of the path patterns match.
IMPORTANT
Rules are processed in the order they are listed in the portal. It is highly recommended to configure multi-site listeners first
prior to configuring a basic listener. This ensures that traffic gets routed to the right back end. If a basic listener is listed first
and matches an incoming request, it gets processed by that listener.
UrlPathMap configuration element

The urlPathMap element is used to specify Path patterns to back-end server pool mappings. The following code
example is the snippet of urlPathMap element from template file.
"urlPathMaps": [{
"name": "{urlpathMapName}",
"id":
"/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/urlPathMaps/{urlpathMap
Name}",
"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/{po
olName2}"
},
"backendHttpsettings": {
"id":
"/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpsettingsList
/{settingName2}"
}
}
}]
}
}]
NOTE
PathPattern: This setting 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 "/." The string fed to the path matcher does not include any text after the first? or #, and those chars are not
allowed here.
You can check out a Resource Manager template using URL -based routing for more information.
PathBasedRouting rule
RequestRoutingRule of type PathBasedRouting is used to bind a listener to a urlPathMap. All requests that are
received for this listener are routed based on policy specified in urlPathMap. Snippet of PathBasedRouting rule:
"requestRoutingRules": [
{
"name": "{ruleName}",
"id":
"/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/requestRoutingRules/{ru
leName}",
"properties": {
"ruleType": "PathBasedRouting",
"httpListener": {
"id":
"/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/httpListeners/<listener
Name>"
},
"urlPathMap": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/
urlPathMaps/{urlpathMapName}"
},
}
}
]
Next steps
After learning about URL -based content routing, go to create an application gateway using URL -based routing to
create an application gateway with URL routing rules.
Application Gateway multiple site hosting
Multiple site hosting enables you to configure more than one web application on the same application gateway
instance. This feature allows you to configure a more efficient topology for your deployments by adding up to 20
websites to one application gateway. Each website can be directed to its own backend pool. In the following
example, application gateway is serving traffic for contoso.com and fabrikam.com from two back-end server pools
called ContosoServerPool and FabrikamServerPool.
IMPORTANT
Rules are processed in the order they are listed in the portal. It is highly recommended to configure multi-site listeners first
prior to configuring a basic listener. This will ensure that traffic gets routed to the right back end. If a basic listener is listed
first and matches an incoming request, it gets processed by that listener.
Requests for http://contoso.com are routed to ContosoServerPool, and http://fabrikam.com are routed to
FabrikamServerPool.
Similarly two subdomains of the same parent domain can be hosted on the same application gateway
deployment. Examples of using subdomains could include http://blog.contoso.com and http://app.contoso.com
hosted on a single application gateway deployment.
Host headers and Server Name Indication (SNI)

There are three common mechanisms for enabling multiple site hosting on the same infrastructure.
1. Host multiple web applications each on a unique IP address.
2. Use host name to host multiple web applications on the same IP address.
3. Use different ports to host multiple web applications on the same IP address.
Currently an application gateway gets a single public IP address on which it listens for traffic. Therefore
supporting multiple applications, each with its own IP address, is currently not supported. Application Gateway
supports hosting multiple applications each listening on different ports but this scenario would require the
applications to accept traffic on non-standard ports and is often not a desired configuration. Application Gateway
relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port. The sites
hosted on application gateway can also support SSL offload with Server Name Indication (SNI) TLS extension.
This scenario means that the client browser and backend web farm must support HTTP/1.1 and TLS extension as
defined in RFC 6066.
Listener configuration element

Existing HTTPListener configuration element is enhanced to support host name and server name indication
elements, which is used by application gateway to route traffic to appropriate backend pool. The following code
example is the snippet of HttpListeners element from template file.
"httpListeners": [
{
"name": "appGatewayHttpsListener1",
"properties": {
"FrontendIPConfiguration": {
"Id":
"/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGat
eway1/frontendIPConfigurations/DefaultFrontendPublicIP"
},
"FrontendPort": {
"Id":
eway1/frontendPorts/appGatewayFrontendPort443'"
},
"Protocol": "Https",
"SslCertificate": {
"Id":
eway1/sslCertificates/appGatewaySslCert1'"
},
"HostName": "contoso.com",
"RequireServerNameIndication": "true"
}
},
{
"name": "appGatewayHttpListener2",
"properties": {
"Id":
eway1/frontendIPConfigurations/appGatewayFrontendIP'"
},
"FrontendPort": {
"Id":
eway1/frontendPorts/appGatewayFrontendPort80'"
},
"Protocol": "Http",
"HostName": "fabrikam.com",
"RequireServerNameIndication": "false"
}
}
],
You can visit Resource Manager template using multiple site hosting for an end to end template-based
deployment.
Routing rule
There is no change required in the routing rule. The routing rule 'Basic' should continue to be chosen to tie the
appropriate site listener to the corresponding backend address pool.
"requestRoutingRules": [
{
"name": "<ruleName1>",
"properties": {
"RuleType": "Basic",
"httpListener": {
"id":
eway1/httpListeners/appGatewayHttpsListener1')]"
},
"id":
eway1/backendAddressPools/ContosoServerPool')]"
},
"backendHttpSettings": {
"id":
eway1/backendHttpSettingsCollection/appGatewayBackendHttpSettings')]"
}
}
},
{
"properties": {
"httpListener": {
"id":
eway1/httpListeners/appGatewayHttpListener2')]"
},
"id":
eway1/backendAddressPools/FabrikamServerPool')]"
},
"id":
eway1/backendHttpSettingsCollection/appGatewayBackendHttpSettings')]"
}
}
}
]
Next steps
After learning about multiple site hosting, go to create an application gateway using multiple site hosting to create
an application gateway with ability to support more than one web application.
Application Gateway redirect overview
A common 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. In the past, customers have used
techniques such as creating a dedicated backend pool whose sole purpose is to redirect requests it receives on
HTTP to HTTPS.
Application Gateway now supports the ability to redirect traffic on the gateway. This simplifies application
configuration, optimizes the resource usage, and supports new redirection scenarios including global and path-
based redirection. Application Gateway redirection support is not limited to HTTP -> HTTPS redirection alone. It
has a generic redirection mechanism, which allows for traffic redirection received at one listener to another listener
on Application Gateway. External site redirection is also supported.
Application Gateway redirection support offers the following capabilities:
Global redirection
Redirects from one listener to another listener on the gateway. This enables HTTP to HTTPS redirection on a
site.
Path-based redirection
This type of redirection enables HTTP to HTTPS redirection only on a specific site area, for example a
shopping cart area denoted by /cart/*.
Redirect to external site
With this change, customers need to create a new redirect configuration object, which specifies the target listener
or external site to which redirection is desired. The configuration element also supports options to enable
appending the URI path and query string to the redirected URL. You can also choose whether redirection is a
temporary (HTTP status code 302) or a permanent redirect (HTTP status code 301). Once created, this redirect
configuration is attached to the source listener via a new rule. When using a basic rule, the redirect configuration is
associated with a source listener and is a global redirect. When a path-based rule is used, the redirect configuration
is defined on the URL path map. So it only applies to the specific path area of a site.
Next steps
Configure URL redirection on an application gateway
Application Gateway support for multi-tenant back
ends
Azure Application Gateway supports virtual machine scale sets, network interfaces, public/private IP, or fully
qualified domain name (FQDN ) as part of its back end pools. By default, application gateway does not change the
incoming HTTP host header from the client and sends the header unaltered to the back end. There are many
services like Azure Web Apps that are multi-tenant in nature and rely on a specific host header or SNI extension to
resolve to the correct endpoint. Application Gateway now supports the ability for users to overwrite the incoming
HTTP host header based on the back end HTTP settings. This capability enables support for multi-tenant back ends
Azure web apps and API management. This capability is available for both the standard and WAF SKU. Multi-
tenant back end support also works with SSL termination and end to end SSL scenarios.
The ability to specify a host override is defined at the HTTP settings and can be applied to any back end pool
during rule creation. Multi-tenant back ends support the following two ways of overriding host header and SNI
extension.
1. The ability to set the host name to a fixed value in the HTTP settings. This capability ensures that the host
header is overridden to this value for all traffic to the back end pool where the HTTP settings are applied.
When using end to end SSL, this overridden host name is used in the SNI extension. This capability enables
scenarios where a back end pool farm expects a host header that is different from the incoming customer
host header.
2. The ability to derive the host name from the IP or FQDN of the back end pool members. HTTP settings also
provide an option to pick the host name from a back end pool member's FQDN if configured with the
option to derive host name from an individual back end pool member. When using end to end SSL, this host
name is derived from the FQDN and is used in the SNI extension. This capability enables scenarios where a
back end pool can have two or more multi-tenant PaaS services like Azure web apps and the request's host
header to each member contains the host name derived from its FQDN.
NOTE
In both of the preceding cases the settings only affect the live traffic behavior and not the health probe behavior. Custom
probes already support the ability to specify a host header in the probe configuration. Custom probes now also support the
ability to derive the host header behavior from the currently configured HTTP settings. This configuration can be specified by
using the PickHostNameFromBackendHttpSettings parameter in the probe configuration. For end to end functionality to
work, both the probe and the HTTP settings must be modified to reflect the correct configuration.
With this capability, customers specify the options in the HTTP settings and custom probes to the appropriate
configuration. This setting is then tied to a listener and a back end pool by using a rule.
Next steps
Learn how to set up an application gateway with a web app as a back end pool member by visiting: Configure App
Service web apps with Application Gateway
Application Gateway health monitoring overview
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. Application gateway sends the health probes with the same port that is defined in the back-end
HTTP settings. This configuration ensures that the probe is testing the same port that customers would be using to
connect to the backend.
In addition to using default health probe monitoring, you can also customize the health probe to suit your
application's requirements. In this article, both default and custom health probes are covered.
Default health probe

An application gateway automatically configures a default health probe when you don't set up any custom probe
configuration. The monitoring behavior works by making an HTTP request to the IP addresses configured for the
back-end pool. For default probes if the backend http settings are configured for HTTPS, the probe uses HTTPS as
well to test health of the backends.
For example: You configure your application gateway to use back-end servers A, B, and C to receive HTTP network
traffic on port 80. The default health monitoring tests the three servers every 30 seconds for a healthy HTTP
response. A healthy HTTP response has a status code between 200 and 399.
If the default probe check fails for server A, the application gateway removes it from its back-end pool, and
network traffic stops flowing to this server. The default probe still continues to check for server A every 30 seconds.
When server A responds successfully to one request from a default health probe, it is added back as healthy to the
back-end pool, and traffic starts flowing to the server again.
Probe Matching
By default, an HTTP (S ) response with status code 200 is considered healthy. Custom health probes additionally
support two matching criteria. Matching criteria can be used to optionally modify the default interpretation of what
consititutes a healthy response.
The following are 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 which looks at HTTP response body and matches
with a user specified string. Note that the match only looks for presence of user specified string in response
body and is not a full regular expression match.
Match criteria can be specified using the New-AzureRmApplicationGatewayProbeHealthResponseMatch cmdlet.
For example:
$match = New-AzureRmApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399

$match = New-AzureRmApplicationGatewayProbeHealthResponseMatch -Body "Healthy"
Once the match criteria is specified, it can be attached to probe configuration using a -Match parameter in
PowerShell.
Default health probe settings
PROBE PROPERTY VALUE DESCRIPTION
Probe URL http://127.0.0.1:<port>/ URL path
Interval 30 Probe interval in seconds
Time-out 30 Probe time-out in seconds
Unhealthy threshold 3 Probe retry count. The back-end server

is marked down after the consecutive
probe failure count reaches the
unhealthy threshold.
NOTE
The port is the same port as the back-end HTTP settings.
The default probe looks only at http://127.0.0.1:<port> to determine health status. If you need to configure the
health probe to go to a custom URL or modify any other settings, you must use custom probes as described in the
following steps:
Custom health probe

Custom probes allow you to have a more granular control over the health monitoring. When using custom probes,
you can configure the probe interval, the URL and path to test, and how many failed responses to accept before
marking the back-end pool instance as unhealthy.
Custom health probe settings
The following table provides definitions for the properties of a custom health probe.
PROBE PROPERTY DESCRIPTION
Name Name of the probe. This name is used to refer to the probe in
back-end HTTP settings.
Protocol Protocol used to send the probe. The probe uses the protocol
defined in the back-end HTTP settings
Host Host name to send the probe. Applicable only when multi-site
is configured on Application Gateway, otherwise use
'127.0.0.1'. This value is different from VM host name.
Path Relative path of the probe. The valid path starts from '/'.
Interval Probe interval in seconds. This value is the time interval

between two consecutive probes.
Time-out Probe time-out in seconds. If a valid response is not received

within this time-out period, the probe is marked as failed.
Unhealthy threshold Probe retry count. The back-end server is marked down after
the consecutive probe failure count reaches the unhealthy
threshold.
IMPORTANT
If Application Gateway is configured for a single site, by default the Host name should be specified as '127.0.0.1', unless
otherwise configured in custom probe. For reference a custom probe is sent to <protocol>://<host>:<port><path>. The
port used will be the same port as defined in the back-end HTTP settings.
NSG considerations
If there is a network security group (NSG ) on an application gateway subnet, port ranges 65503-65534 must be
opened on the application gateway subnet for inbound traffic. These ports are required for the backend health API
to work.
Additionally, outbound Internet connectivity can't be blocked, and traffic from the AzureLoadBalancer tag must be
allowed.
Next steps
After learning about Application Gateway health monitoring, you can configure a custom health probe in the Azure
portal or a custom health probe using PowerShell and the Azure Resource Manager deployment model.
Overview of WebSocket support in Application
Gateway
Application Gateway provides native support for WebSocket across all gateway sizes. There is no user-
configurable setting to selectively enable or disable WebSocket support.
WebSocket protocol standardized in RFC6455 enables a full duplex communication between a server and a client
over a long running TCP connection. This feature allows for a more interactive communication between the web
server and the client, which can be bidirectional without the need for polling as required in HTTP -based
implementations. WebSocket has low overhead unlike HTTP and can reuse the same TCP connection for multiple
request/responses resulting in a more efficient utilization of resources. WebSocket protocols are designed to work
over traditional HTTP ports of 80 and 443.
You can continue using a standard HTTP listener on port 80 or 443 to receive WebSocket traffic. WebSocket traffic
is then directed to the WebSocket enabled backend server using the appropriate backend pool as specified in
application gateway rules. The backend server must respond to the application gateway probes, which are
described in the health probe overview section. Application gateway health probes are HTTP/HTTPS only. Each
backend server must respond to HTTP probes for application gateway to route WebSocket traffic to the server.
Listener configuration element

An existing HTTP listener can be used to support WebSocket traffic. The following is a snippet of an httpListeners
element from a sample template file. You would need both HTTP and HTTPS listeners to support WebSocket and
secure WebSocket traffic. Similarly you can use the portal or PowerShell to create an application gateway with
listeners on port 80/443 to support WebSocket traffic.
"httpListeners": [
{
"name": "appGatewayHttpsListener",
"properties": {
"Id":
"/subscriptions/{subscriptionId/resourceGroups/{resourceGroupName/providers/Microsoft.Network/applicationGatewa
ys/{applicationGatewayName/frontendIPConfigurations/DefaultFrontendPublicIP"
},
"FrontendPort": {
"Id":
ys/{applicationGatewayName/frontendPorts/appGatewayFrontendPort443'"
},
"Protocol": "Https",
"SslCertificate": {
"Id":
ys/{applicationGatewayName/sslCertificates/appGatewaySslCert1'"
},
}
},
{
"name": "appGatewayHttpListener",
"properties": {
"Id":
ys/{applicationGatewayName/frontendIPConfigurations/appGatewayFrontendIP'"
},
"FrontendPort": {
"Id":
ys/{applicationGatewayName/frontendPorts/appGatewayFrontendPort80'"
},
"Protocol": "Http",
}
}
],
BackendAddressPool, BackendHttpSetting, and Routing rule

configuration
A BackendAddressPool is used to define a backend pool with WebSocket enabled servers. The backendHttpSetting
is defined with a backend port 80 and 443. The properties for cookie-based affinity and requestTimeouts are not
relevant to WebSocket traffic. There is no change required in the routing rule, 'Basic' is used to tie the appropriate
listener to the corresponding backend address pool.
"requestRoutingRules": [{
"properties": {
"httpListener": {
"id":
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/applicationGate
ways/{applicationGatewayName}/httpListeners/appGatewayHttpsListener')]"
},
"id":
ways/{applicationGatewayName}/backendAddressPools/ContosoServerPool')]"
},
"id":
ways/{applicationGatewayName}/backendHttpSettingsCollection/appGatewayBackendHttpSettings')]"
}
}
}, {
"properties": {
"httpListener": {
"id":
ways/{applicationGatewayName}/httpListeners/appGatewayHttpListener')]"
},
"id":
ways/{applicationGatewayName}/backendAddressPools/ContosoServerPool')]"
},
"id":
ways/{applicationGatewayName}/backendHttpSettingsCollection/appGatewayBackendHttpSettings')]"
}
}
}]
WebSocket enabled backend

Your backend must have a HTTP/HTTPS web server running on the configured port (usually 80/443) for
WebSocket to work. This requirement is because WebSocket protocol requires the initial handshake to be HTTP
with upgrade to WebSocket protocol as a header field. The following is an example of a header:
GET /chat HTTP/1.1

Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Another reason for this is that application gateway backend health probe supports HTTP and HTTPS protocols
only. If the backend server does not respond to HTTP or HTTPS probes, it is taken out of backend pool.
Next steps
After learning about WebSocket support, go to create an application gateway to get started with a WebSocket
enabled web application.
Manage web traffic with an application gateway
using Azure PowerShell
Application gateway is used to manage and secure web traffic to servers that you maintain. You can use Azure
PowerShell to create an application gateway that uses a virtual machine scale set for backend servers to manage
web traffic. In this example, the scale set contains two virtual machine instances that are added to the default
backend pool of the application gateway.
Set up the network

If you choose to install and use PowerShell locally, this tutorial requires the Azure PowerShell module version 3.6
or later. To find the version, run Get-Module -ListAvailable AzureRM . If you need to upgrade, see Install Azure

resource group using New -AzureRmResourceGroup.

Configure the subnets named myBackendSubnet and myAGSubnet using New -
AzureRmVirtualNetworkSubnetConfig. Create the virtual network myVNet using New -AzureRmVirtualNetwork
with the subnet configurations. And finally, create the public IP address named myAGPublicIPAddress using New -
AzureRmPublicIpAddress. These resources are used to provide network connectivity to the application gateway
and its associated resources.
-Name myAGSubnet `
$vnet = New-AzureRmVirtualNetwork `
-Location eastus `
-Name myVNet `
$pip = New-AzureRmPublicIpAddress `
-Location eastus `

In this section you create resources that support the application gateway, and then finally create it. The resources
that you create include:
IP configurations and frontend port - Associates the subnet that you previously created to the application
gateway and assigns a port to use to access it.
Default pool - All application gateways must have at least one backend pool of servers.
Default listener and rule - The default listener listens for traffic on the port that was assigned and the default
rule sends traffic to the default pool.
Associate myAGSubnet that you previously created to the application gateway using New -
AzureRmApplicationGatewayIPConfiguration. Assign myAGPublicIPAddress to the application gateway using
New -AzureRmApplicationGatewayFrontendIPConfig.
$vnet = Get-AzureRmVirtualNetwork `
-Name myVNet
-Subnet $subnet
-Port 80
Create the backend pool and settings
Create the backend pool named appGatewayBackendPool for the application gateway using New -
AzureRmApplicationGatewayBackendAddressPool. Configure the settings for the backend address pools using
New -AzureRmApplicationGatewayBackendHttpSettings.
$defaultPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool
-Port 80 `
-Protocol Http `
-RequestTimeout 120
Create the default listener and rule

A listener is required to enable the application gateway to route traffic appropriately to the backend pool. In this
example, you create a basic listener that listens for traffic at the root URL.
Create a listener named mydefaultListener using New -AzureRmApplicationGatewayHttpListener with the
frontend configuration and frontend port that you previously created. A rule is required for the listener to know
which backend pool to use for incoming traffic. Create a basic rule named rule1 using New -
AzureRmApplicationGatewayRequestRoutingRule.
-Name mydefaultListener `
-Protocol Http `
-Name rule1 `
-RuleType Basic `
-BackendAddressPool $defaultPool `

Now that you created the necessary supporting resources, specify parameters for the application gateway using
New -AzureRmApplicationGatewaySku, and then create it using New -AzureRmApplicationGateway.
-Tier Standard `
-Capacity 2
$appgw = New-AzureRmApplicationGateway `
-Location eastus `
-BackendAddressPools $defaultPool `
-Sku $sku
In this example, you create a virtual machine scale set to provide servers for the backend pool in the application
gateway. You assign the scale set to the backend pool when you configure the IP settings.
-Name myVNet
$appgw = Get-AzureRmApplicationGateway `
-Name myAppGateway
$backendPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool `
-ApplicationGateway $appgw
$ipConfig = New-AzureRmVmssIpConfig `
-Name myVmssIPConfig `
-SubnetId $vnet.Subnets[1].Id `
-ApplicationGatewayBackendAddressPoolsId $backendPool.Id
$vmssConfig = New-AzureRmVmssConfig `
-Location eastus `
-SkuCapacity 2 `
-SkuName Standard_DS2 `
-UpgradePolicyMode Automatic
Set-AzureRmVmssStorageProfile $vmssConfig `
-ImageReferencePublisher MicrosoftWindowsServer `
-ImageReferenceOffer WindowsServer `
-ImageReferenceSku 2016-Datacenter `
-ImageReferenceVersion latest `
-OsDiskCreateOption FromImage
Set-AzureRmVmssOsProfile $vmssConfig `
-AdminUsername azureuser `
-AdminPassword "Azure123456!" `
-ComputerNamePrefix myvmss
Add-AzureRmVmssNetworkInterfaceConfiguration `
-VirtualMachineScaleSet $vmssConfig `
-Name myVmssNetConfig `
-Primary $true `
-IPConfiguration $ipConfig
New-AzureRmVmss `
-Name myvmss `
-VirtualMachineScaleSet $vmssConfig
Install IIS
$publicSettings = @{ "fileUris" = (,"https://raw.githubusercontent.com/Azure/azure-docs-powershell-
samples/master/application-gateway/iis/appgatewayurl.ps1");
"commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File appgatewayurl.ps1" }
$vmss = Get-AzureRmVmss -ResourceGroupName myResourceGroupAG -VMScaleSetName myvmss
Add-AzureRmVmssExtension -VirtualMachineScaleSet $vmss `

-Name "customScript" `
-Publisher "Microsoft.Compute" `
-Type "CustomScriptExtension" `
-Setting $publicSettings
Update-AzureRmVmss `
-Name myvmss `
-VirtualMachineScaleSet $vmss

Use Get-AzureRmPublicIPAddress to get the public IP address of the application gateway. Copy the public IP
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources using Remove-
Next steps
Set up the network
Restrict web traffic with a web application firewall
Create an application gateway by using the Azure
Resource Manager template
Azure Application Gateway is a layer-7 load balancer. It provides failover and performance-routing HTTP requests
between different servers, whether they are on the cloud or on-premises. Application Gateway provides many
application delivery controller (ADC ) features including HTTP load balancing, cookie-based session affinity, Secure
Sockets Layer (SSL ) offload, custom health probes, support for multi-site, and many others. To find a complete list
of supported features, visit Application Gateway overview
This article walks you through downloading and modifying an existing Azure Resource Manager template from
GitHub and deploying the template from GitHub, PowerShell, and the Azure CLI.
If you are simply deploying the template directly from GitHub without any changes, skip to deploy a template from
GitHub.
Scenario
In this scenario you will:
Create an application gateway with web application firewall.
Create a virtual network named VirtualNetwork1 with a reserved CIDR block of 10.0.0.0/16.
Create a subnet called Appgatewaysubnet that uses 10.0.0.0/28 as its CIDR block.
Set up two previously configured back-end IPs for the web servers you want to load balance the traffic. In this
template example, the back-end IPs are 10.0.1.10 and 10.0.1.11.
NOTE
Those settings are the parameters for this template. To customize the template, you can change rules, the listener, SSL, and
other options in the azuredeploy.json file.
Download and understand the Azure Resource Manager template

You can download the existing Azure Resource Manager template to create a virtual network and two subnets from
GitHub, make any changes you might want, and reuse it. To do so, use the following steps:
1. Navigate to Create Application Gateway with web application firewall enabled.
2. Click azuredeploy.json, and then click RAW.
3. Save the file to a local folder on your computer.
4. If you are familiar with Azure Resource Manager templates, skip to step 7.
5. Open the file that you saved and look at the contents under parameters in line
6. Azure Resource Manager template parameters provide a placeholder for values that can be filled out during
deployment.
PARAMETER DESCRIPTION
subnetPrefix CIDR block for the application gateway subnet.
applicationGatewaySize Size of the application gateway. WAF only allows medium

and large.
backendIpaddress1 IP address of the first web server.
backendIpaddress2 IP address of the second web server.
wafEnabled Setting to determine if WAF is enabled.
wafMode Mode of the web application firewall. Available options are

prevention or detection.
wafRuleSetType Ruleset type for WAF. Currently OWASP is the only

supported option.
wafRuleSetVersion Ruleset version. OWASP CRS 2.2.9 and 3.0 are currently
the supported options.
7. Check the content under resources and notice the following properties:
type. Type of resource being created by the template. In this case, the type is
Microsoft.Network/applicationGateways , which represents an application gateway.
name. Name for the resource. Notice the use of [parameters('applicationGatewayName')] , which means
that the name is provided as input by you or by a parameter file during deployment.
properties. List of properties for the resource. This template uses the virtual network and public IP
address during application gateway creation.
8. Navigate back to https://github.com/Azure/azure-quickstart-templates/blob/master/101-application-
gateway-waf/.
9. Click azuredeploy-parameters.json, and then click RAW.
10. Save the file to a local folder on your computer.
11. Open the file that you saved and edit the values for the parameters. Use the following values to deploy the
application gateway described in our scenario.
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"addressPrefix": {
"value": "10.0.0.0/16"
},
"subnetPrefix": {
"value": "10.0.0.0/28"
},
"applicationGatewaySize": {
"value": "WAF_Medium"
},
"capacity": {
"value": 2
},
"backendIpAddress1": {
"value": "10.0.1.10"
},
"backendIpAddress2": {
"value": "10.0.1.11"
},
"wafEnabled": {
"value": true
},
"wafMode": {
"value": "Detection"
},
"wafRuleSetType": {
"value": "OWASP"
},
"wafRuleSetVersion": {
"value": "3.0"
}
}
}
12. Save the file. You can test the JSON template and parameter template by using online JSON validation
tools like JSlint.com.
Deploy the Azure Resource Manager template by using PowerShell

If you have never used Azure PowerShell, visit: How to install and configure Azure PowerShell and follow the
instructions to sign into Azure and select your subscription.
1. Login to PowerShell
Login-AzureRmAccount
2. Check the subscriptions for the account.
Get-AzureRmSubscription
You are prompted to authenticate with your credentials.

3. Choose which of your Azure subscriptions to use.
Select-AzureRmSubscription -Subscriptionid "GUID of subscription"

4. If needed, create a resource group by using the New-AzureResourceGroup cmdlet. In the following
example, you create a resource group called AppgatewayRG in East US location.
New-AzureRmResourceGroup -Name AppgatewayRG -Location "West US"
5. Run the New-AzureRmResourceGroupDeployment cmdlet to deploy the new virtual network by using
the preceding template and parameter files you downloaded and modified.
New-AzureRmResourceGroupDeployment -Name TestAppgatewayDeployment -ResourceGroupName AppgatewayRG `

-TemplateFile C:\ARM\azuredeploy.json -TemplateParameterFile C:\ARM\azuredeploy-parameters.json
Deploy the Azure Resource Manager template by using the Azure CLI
To deploy the Azure Resource Manager template you downloaded by using Azure CLI, follow the following steps:
1. If you have never used Azure CLI, see Install and configure the Azure CLI and follow the instructions up to
the point where you select your Azure account and subscription.
2. If necessary, run the az group create command to create a resource group, as shown in the following code
snippet. Notice the output of the command. The list shown after the output explains the parameters used.
For more information about resource groups, visit Azure Resource Manager overview.
az group create --location westus --name appgatewayRG
-n (or --name). Name for the new resource group. For our scenario, it's appgatewayRG.
-l (or --location). Azure region where the new resource group is created. For our scenario, it's westus.
3. Run the az group deployment create cmdlet to deploy the new virtual network by using the template and
parameter files you downloaded and modified in the preceding step. The list shown after the output explains
the parameters used.
az group deployment create --resource-group appgatewayRG --name TestAppgatewayDeployment --template-file

azuredeploy.json --parameters @azuredeploy-parameters.json
Deploy the Azure Resource Manager template by using click-to-deploy

Click-to-deploy is another way to use Azure Resource Manager templates. It's an easy way to use templates with
the Azure portal.
1. Go to Create an application gateway with web application firewall.
2. Click Deploy to Azure.
3. Fill out the parameters for the deployment template on the portal and click OK.
4. Select I agree to the terms and conditions stated above and click Purchase.
5. On the Custom deployment blade, click Create.
Providing certificate data to Resource Manager templates

When using SSL with a template, the certificate needs to be provided in a base64 string instead of being uploaded.
To convert a .pfx or .cer to a base64 string use one of the following commands. The following commands convert
the certificate to a base64 string, which can be provided to the template. The expected output is a string that can be
stored in a variable and pasted in the template.
macOS
cert=$( base64 <certificate path and name>.pfx )

echo $cert
Windows
[System.Convert]::ToBase64String([System.IO.File]::ReadAllBytes("<certificate path and name>.pfx"))
Delete all resources

To delete all resources created in this article, complete one of the following steps:
PowerShell
Remove-AzureRmResourceGroup -Name appgatewayRG
Azure CLI
az group delete --name appgatewayRG
Next steps
If you want to configure SSL offload, visit: Configure an application gateway for SSL offload.
If you want to configure an application gateway to use with an internal load balancer, visit: Create an application
gateway with an internal load balancer (ILB ).
If you want more information about load balancing options in general, visit:
Azure Load Balancer
Azure Traffic Manager
Create an application gateway with an internal load
balancer (ILB)
Azure Application Gateway can be configured with an Internet-facing VIP or with an internal endpoint that is not
exposed to the Internet, also known as an internal load balancer (ILB ) endpoint. Configuring the gateway with an
ILB is useful for internal line-of-business applications that are not exposed to the Internet. It's also useful for
services and tiers within a multi-tier application that sit in a security boundary that is not exposed to the Internet
but still require round-robin load distribution, session stickiness, or Secure Sockets Layer (SSL ) termination.
This article walks you through the steps to configure an application gateway with an ILB.
Before you begin

1. Install the latest version of the Azure PowerShell cmdlets by using the Web Platform Installer. You can
download and install the latest version from the Windows PowerShell section of the Downloads page.
2. You create a virtual network and a subnet for Application Gateway. Make sure that no virtual machines or cloud
deployments are using the subnet. Application Gateway must be by itself in a virtual network subnet.
3. The servers that you configure to use the application gateway must exist or have their endpoints created either
in the virtual network or with a public IP/VIP assigned.
What is required to create an application gateway?

Back-end server pool: The list of IP addresses of the back-end servers. The IP addresses listed should either
belong to the virtual network but in a different subnet for the application gateway or should be a public IP/VIP.
Back-end server pool settings: Every pool has settings like port, protocol, and cookie-based affinity. These
settings are tied to a pool and are applied to all servers within the pool.
Front-end port: This port is the public port that is opened on the application gateway. Traffic hits this port, and
then gets redirected to one of the back-end servers.
Listener: The listener has a front-end port, a protocol (Http or Https, these are case-sensitive), and the SSL
certificate name (if configuring SSL offload).
Rule: The rule binds the listener and the back-end server pool and defines which back-end server pool the
traffic should be directed to when it hits a particular listener. Currently, only the basic rule is supported. The
basic rule is round-robin load distribution.

The difference between using Azure Classic and Azure Resource Manager is the order in which you create the
application gateway and the items that need to be configured. With Resource Manager, all items that make an
application gateway is configured individually and then put together to create the application gateway resource.
Here are the steps that are needed to create an application gateway:
1. Create a resource group for Resource Manager
2. Create a virtual network and a subnet for the application gateway
3. Create an application gateway configuration object
4. Create an application gateway resource
Create a resource group for Resource Manager
Make sure that you switch PowerShell mode to use the Azure Resource Manager cmdlets. More info is available at
Using Windows PowerShell with Resource Manager.
Step 1
Connect-AzureRmAccount
Step 2
Check the subscriptions for the account.
You are prompted to authenticate with your credentials.

Step 3
Choose which of your Azure subscriptions to use.
Select-AzureRmSubscription -Subscriptionid "GUID of subscription"
Step 4
Create a new resource group (skip this step if you're using an existing resource group).
New-AzureRmResourceGroup -Name appgw-rg -location "West US"
Azure Resource Manager requires that all resource groups specify a location. This is used as the default location for
resources in that resource group. Make sure that all commands to create an application gateway uses the same
resource group.
In the preceding example, we created a resource group called "appgw -rg" and location "West US".
Create a virtual network and a subnet for the application gateway

The following example shows how to create a virtual network by using Resource Manager:
Step 1
$subnetconfig = New-AzureRmVirtualNetworkSubnetConfig -Name subnet01 -AddressPrefix 10.0.0.0/24
This step assigns the address range 10.0.0.0/24 to a subnet variable to be used to create a virtual network.
Step 2
$vnet = New-AzureRmVirtualNetwork -Name appgwvnet -ResourceGroupName appgw-rg -Location "West US" -

AddressPrefix 10.0.0.0/16 -Subnet $subnetconfig
This step creates a virtual network named "appgwvnet" in resource group "appgw -rg" for the West US region
using the prefix 10.0.0.0/16 with subnet 10.0.0.0/24.
Step 3
$subnet = $vnet.subnets[0]
This step assigns the subnet object to variable $subnet for the next steps.
Create an application gateway configuration object

Step 1
$gipconfig = New-AzureRmApplicationGatewayIPConfiguration -Name gatewayIP01 -Subnet $subnet
This step creates an application gateway IP configuration named "gatewayIP01". When Application Gateway starts,
it picks up an IP address from the subnet configured and route network traffic to the IP addresses in the back-end
IP pool. Keep in mind that each instance takes one IP address.
Step 2
$pool = New-AzureRmApplicationGatewayBackendAddressPool -Name pool01 -BackendIPAddresses

10.1.1.8,10.1.1.9,10.1.1.10
This step configures the back-end IP address pool named "pool01" with IP addresses "10.1.1.8, 10.1.1.9, 10.1.1.10".
Those are the IP addresses that receive the network traffic that comes from the front-end IP endpoint. You replace
the preceding IP addresses to add your own application IP address endpoints.
Step 3
$poolSetting = New-AzureRmApplicationGatewayBackendHttpSettings -Name poolsetting01 -Port 80 -Protocol Http -

CookieBasedAffinity Disabled
This step configures application gateway setting "poolsetting01" for the load balanced network traffic in the back-
end pool.
Step 4
$fp = New-AzureRmApplicationGatewayFrontendPort -Name frontendport01 -Port 80
This step configures the front-end IP port named "frontendport01" for the ILB.
Step 5
$fipconfig = New-AzureRmApplicationGatewayFrontendIPConfig -Name fipconfig01 -Subnet $subnet
This step creates the front-end IP configuration called "fipconfig01" and associates it with a private IP from the
current virtual network subnet.
Step 6
$listener = New-AzureRmApplicationGatewayHttpListener -Name listener01 -Protocol Http -FrontendIPConfiguration

$fipconfig -FrontendPort $fp
This step creates the listener called "listener01" and associates the front-end port to the front-end IP configuration.
Step 7
$rule = New-AzureRmApplicationGatewayRequestRoutingRule -Name rule01 -RuleType Basic -BackendHttpSettings
$poolSetting -HttpListener $listener -BackendAddressPool $pool
This step creates the load balancer routing rule called "rule01" that configures the load balancer behavior.
Step 8
$sku = New-AzureRmApplicationGatewaySku -Name Standard_Small -Tier Standard -Capacity 2
This step configures the instance size of the application gateway.
NOTE
The default value for InstanceCount is 2, with a maximum value of 10. The default value for GatewaySize is Medium. You can
choose between Standard_Small, Standard_Medium, and Standard_Large.
Create an application gateway by using New-AzureApplicationGateway

Creates an application gateway with all configuration items from the preceding steps. In this example, the
application gateway is called "appgwtest".
$appgw = New-AzureRmApplicationGateway -Name appgwtest -ResourceGroupName appgw-rg -Location "West US" -

BackendAddressPools $pool -BackendHttpSettingsCollection $poolSetting -FrontendIpConfigurations $fipconfig -
GatewayIpConfigurations $gipconfig -FrontendPorts $fp -HttpListeners $listener -RequestRoutingRules $rule -Sku
$sku
This step creates an application gateway with all configuration items from the preceding steps. In the example, the
application gateway is called "appgwtest".
Delete an application gateway

To delete an application gateway, you need to do the following steps in order:
1. Use the Stop-AzureRmApplicationGateway cmdlet to stop the gateway.
2. Use the Remove-AzureRmApplicationGateway cmdlet to remove the gateway.
3. Verify that the gateway has been removed by using the Get-AzureApplicationGateway cmdlet.
Step 1
Get the application gateway object and associate it to a variable "$getgw".
$getgw = Get-AzureRmApplicationGateway -Name appgwtest -ResourceGroupName appgw-rg
Step 2
Use Stop-AzureRmApplicationGateway to stop the application gateway. This sample shows the
Stop-AzureRmApplicationGateway cmdlet on the first line, followed by the output.
Stop-AzureRmApplicationGateway -ApplicationGateway $getgw

VERBOSE: 9:49:34 PM - Begin Operation: Stop-AzureApplicationGateway
VERBOSE: 10:10:06 PM - Completed Operation: Stop-AzureApplicationGateway
Name HTTP Status Code Operation ID Error
---- ---------------- ------------ ----
Successful OK ce6c6c95-77b4-2118-9d65-e29defadffb8
Once the application gateway is in a stopped state, use the Remove-AzureRmApplicationGateway cmdlet to remove the
service.
Remove-AzureRmApplicationGateway -Name appgwtest -ResourceGroupName appgw-rg -Force
VERBOSE: 10:49:34 PM - Begin Operation: Remove-AzureApplicationGateway

VERBOSE: 10:50:36 PM - Completed Operation: Remove-AzureApplicationGateway
Name HTTP Status Code Operation ID Error
---- ---------------- ------------ ----
Successful OK 055f3a96-8681-2094-a304-8d9a11ad8301
NOTE
The -force switch can be used to suppress the remove confirmation message.
To verify that the service has been removed, you can use the Get-AzureRmApplicationGateway cmdlet. This step is not
required.
Get-AzureRmApplicationGateway -Name appgwtest -ResourceGroupName appgw-rg
VERBOSE: 10:52:46 PM - Begin Operation: Get-AzureApplicationGateway
Get-AzureApplicationGateway : ResourceNotFound: The gateway does not exist.
Next steps
If you want to configure SSL offload, see Configure an application gateway for SSL offload.
If you want to configure an application gateway to use with an ILB, see Create an application gateway with an
internal load balancer (ILB ).
If you want more information about load balancing options in general, see:
Azure Load Balancer
Azure Traffic Manager
Configure an application gateway with SSL
termination using the Azure portal
You can use the Azure portal to configure an application gateway with a certificate for SSL termination that uses
virtual machines for backend servers.
In this article, you learn how to:
Create the virtual machines used as backend servers
Log in to Azure

In this section, you use New -SelfSignedCertificate to create a self-signed certificate that you upload to the Azure
portal when you create the listener for the application gateway.
On your local computer, open a Windows PowerShell window as an administrator. Run the following command to
create the certificate:
New-SelfSignedCertificate \
-certstorelocation cert:\localmachine\my \
-dnsname www.contoso.com
You should see something like this response:
PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\my
Thumbprint Subject
---------- -------
E1E81C23B3AD33F9B4D1717B20AB65DBB91AC630 CN=www.contoso.com
Use [Export-PfxCertificate](https://docs.microsoft.com/powershell/module/pkiclient/export-pfxcertificate) with

the Thumbprint that was returned to export a pfx file from the certificate:
$pwd = ConvertTo-SecureString -String "Azure123456!" -Force -AsPlainText

Export-PfxCertificate \
-cert cert:\localMachine\my\E1E81C23B3AD33F9B4D1717B20AB65DBB91AC630 \
-FilePath c:\appgwcert.pfx \
-Password $pwd

A virtual network is needed for communication between the resources that you create. Two subnets are created in
this example: one for the application gateway, and the other for the backend servers. You can create a virtual
network at the same time that you create the application gateway.
1. Click New found on the upper left-hand corner of the Azure portal.
3. Enter myAppGateway for the name of the application gateway and myResourceGroupAG for the new resource
group.
5. Click Choose a virtual network, click Create new, and then enter these values for the virtual network:

7. Click Choose a public IP address, click Create new, and then enter the name of the public IP address. In this
and then click OK.
8. Click HTTPS for the protocol of the listener and make sure that the port is defined as 443.
9. Click the folder icon and browse to the appgwcert.pfx certificate that you previously created to upload it.
10. Enter mycert1 for the name of the certificate and Azure123456! for the password, and then click OK.
11. Review the settings on the summary page, and then click OK to create the network resources and the
application gateway. It may take several minutes for the application gateway to be created, wait until the
deployment finishes successfully before moving on to the next section.
Add a subnet
2. Click Subnets, and then click Subnet.

In this example, you create two virtual machines to be used as backend servers for the application gateway. You
also install IIS on the virtual machines to verify that the application gateway was successfully created.
1. Click New.
2. Click Compute and then select Windows Server 2016 Datacenter in the Featured list.
4. Click OK.
5. Select DS1_V2 for the size of the virtual machine, and click Select.
Install IIS
-VMName myVM `
-Location EastUS
Add backend servers
1. Click All resources, and then click myAppGateway.
appGateayBackendPool.
3. Click Add target to add each virtual machine that you created to the backend pool.
4. Click Save.

1. Click All resources, and then click myAGPublicIPAddress.
2. Copy the public IP address, and then paste it into the address bar of your browser. To accept the security
warning if you used a self-signed certificate, select Details and then Go on to the webpage:
Your secured IIS website is then displayed as in the following example:
Next steps
To learn more about application gateways and their associated resources, continue to the how -to articles.
using Azure PowerShell
You can use Azure PowerShell to create an application gateway with a certificate for SSL termination that uses a
virtual machine scale set for backend servers. In this example, the scale set contains two virtual machine instances
that are added to the default backend pool of the application gateway.
Set up a network
This tutorial requires the Azure PowerShell module version 3.6 or later. Run Get-Module -ListAvailable AzureRM to
find the version. If you need to upgrade, see Install Azure PowerShell module. If you are running PowerShell
locally, you also need to run Login-AzureRmAccount to create a connection with Azure.

For production use, you should import a valid certificate signed by trusted provider. For this tutorial, you create a
self-signed certificate using New -SelfSignedCertificate. You can use Export-PfxCertificate with the Thumbprint
that was returned to export a pfx file from the certificate.
New-SelfSignedCertificate `
-certstorelocation cert:\localmachine\my `
You should see something like this result:
Thumbprint Subject
---------- -------
Use the thumbprint to create the pfx file:
Export-PfxCertificate `
-cert cert:\localMachine\my\E1E81C23B3AD33F9B4D1717B20AB65DBB91AC630 `
-FilePath c:\appgwcert.pfx `
-Password $pwd

resource group named myResourceGroupAG with New -AzureRmResourceGroup.

Configure the subnets named myBackendSubnet and myAGSubnet using New -
AzureRmVirtualNetworkSubnetConfig. Create the virtual network named myVNet using New -
AzureRmVirtualNetwork with the subnet configurations. And finally, create the public IP address named
myAGPublicIPAddress using New -AzureRmPublicIpAddress. These resources are used to provide network
connectivity to the application gateway and its associated resources.
-Name myAGSubnet `
-Location eastus `
-Name myVNet `
-Location eastus `

-Name myVNet
-Subnet $subnet
-Port 443
AzureRmApplicationGatewayBackendAddressPool. Configure the settings for the backend pool using New -
-Port 80 `
-Protocol Http `
-RequestTimeout 120

example, you create a basic listener that listens for HTTPS traffic at the root URL.
Create a certificate object using New -AzureRmApplicationGatewaySslCertificate and then create a listener named
mydefaultListener using New -AzureRmApplicationGatewayHttpListener with the frontend configuration, frontend
port, and certificate that you previously created. A rule is required for the listener to know which backend pool to
use for incoming traffic. Create a basic rule named rule1 using New -
$pwd = ConvertTo-SecureString `
-String "Azure123456!" `
-Force `
-AsPlainText
$cert = New-AzureRmApplicationGatewaySslCertificate `
-Name "appgwcert" `
-CertificateFile "c:\appgwcert.pfx" `
-Password $pwd
-Protocol Https `
-FrontendPort $frontendport `
-SslCertificate $cert
-Name rule1 `
-RuleType Basic `
Create the application gateway with the certificate

Now that you created the necessary supporting resources, specify parameters for the application gateway named
myAppGateway using New -AzureRmApplicationGatewaySku, and then create it using New -
AzureRmApplicationGateway with the certificate.
-Tier Standard `
-Capacity 2
-Location eastus `
-Sku $sku `
-SslCertificates $cert

-Name myVNet
-Name myAppGateway
-Location eastus `
-SkuCapacity 2 `
-ImageReferenceVersion latest
-Primary $true `
New-AzureRmVmss `
-Name myvmss `
Install IIS


-Name myvmss `
You can use Get-AzureRmPublicIPAddress to get the public IP address of the application gateway. Copy the public
IP address, and then paste it into the address bar of your browser.
To accept the security warning if you used a self-signed certificate, select Details and then Go on to the
webpage. Your secured IIS website is then displayed as in the following example:
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources using Remove-
Next steps
Set up a network
Create an application gateway that hosts multiple web sites
Renew Application Gateway certificates
At some point, you'll need to renew your certificates if you configured your application gateway for SSL
encryption.
You can renew a certificate associated with a listener using either the Azure portal, Azure PowerShell, or Azure CLI:
Azure portal
To renew a listener certificate from the portal, navigate to your application gateway listeners. Click the listener that
has a certificate that needs to be renewed, and then click Renew or edit selected certificate.
Upload your new PFX certificate, give it a name, type the password, and then click Save.
Azure PowerShell
To renew your certificate using Azure PowerShell, use the following cmdlet:
-ResourceGroupName <ResourceGroup> `
-Name <AppGatewayName>
$password = ConvertTo-SecureString `
-String "<password>" `
-Force `
-AsPlainText
set-azureRmApplicationGatewaySSLCertificate -Name <oldcertname> `

-ApplicationGateway $appgw -CertificateFile <newcertPath> -Password $password
Azure CLI
az network application-gateway ssl-cert update \
-n "<CertName>" \
--gateway-name "<AppGatewayName>" \
-g "ResourceGroupName>" \
--cert-file <PathToCerFile> \
--cert-password "<password>"
Next steps
To learn how to configure SSL Offloading with Azure Application Gateway, see Configure SSL Offload
Configure SSL policy versions and cipher suites on
Application Gateway
Learn how to configure SSL policy versions and cipher suites on Application Gateway. You can select from a list of
predefined policies that contain different configurations of SSL policy versions and enabled cipher suites. You also
have the ability to define a custom SSL policy based on your requirements.
Get available SSL options

The Get-AzureRMApplicationGatewayAvailableSslOptions cmdlet provides a listing of available pre-defined policies,
available cipher suites, and protocol versions that can be configured. The following example shows an example
output from running the cmdlet.
DefaultPolicy: AppGwSslPolicy20150501
PredefinedPolicies:
/subscriptions/147a22e9-2356-4e56-b3de-
1f5842ae4a3b/resourceGroups//providers/Microsoft.Network/ApplicationGatewayAvailableSslOptions/default/Applic
ationGatewaySslPredefinedPolicy/AppGwSslPolicy20150501
ationGatewaySslPredefinedPolicy/AppGwSslPolicy20170401
ationGatewaySslPredefinedPolicy/AppGwSslPolicy20170401S
AvailableCipherSuites:
AvailableProtocols:
TLSv1_0
TLSv1_1
TLSv1_2
List pre-defined SSL Policies

Application gateway comes with three pre-defined policies that can be used. The
Get-AzureRmApplicationGatewaySslPredefinedPolicy cmdlet retrieves these policies. Each policy has different
protocol versions and cipher suites enabled. These pre-defined policies can be used to quickly configure an SSL
policy on your application gateway. By default AppGwSslPolicy20150501 is selected if no specific SSL policy is
defined.
The following output is an example of running Get-AzureRmApplicationGatewaySslPredefinedPolicy .
Name: AppGwSslPolicy20150501
MinProtocolVersion: TLSv1_0
CipherSuites:
...
Name: AppGwSslPolicy20170401
MinProtocolVersion: TLSv1_1
CipherSuites:
...
Configure a custom SSL policy

When configuring a custom SSL policy, you pass the following parameters: PolicyType, MinProtocolVersion,
CipherSuite, and ApplicationGateway. If you attempt to pass other parameters, you get an error when creating or
updating the Application Gateway.
The following example sets a custom SSL policy on an application gateway. It sets the minimum protocol version
to TLSv1_1 and enables the following cipher suites:
IMPORTANT
At least one cipher suite from the following list must be selected when configuring a custom SSL policy. Application gateway
uses RSA SHA256 cipher suites for backend management.
# get an application gateway resource
$gw = Get-AzureRmApplicationGateway -Name AdatumAppGateway -ResourceGroup AdatumAppGatewayRG
# set the SSL policy on the application gateway

Set-AzureRmApplicationGatewaySslPolicy -ApplicationGateway $gw -PolicyType Custom -MinProtocolVersion TLSv1_1
-CipherSuite "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_RSA_WITH_AES_128_GCM_SHA256"
# validate the SSL policy locally

Get-AzureRmApplicationGatewaySslPolicy -ApplicationGateway $gw
# update the gateway with validated SSL policy

Set-AzureRmApplicationGateway -ApplicationGateway $gw
Create an application gateway with a pre-defined SSL policy

When configuring a Predefined SSL policy, you pass the following parameters: PolicyType, PolicyName, and
ApplicationGateway. If you attempt to pass other parameters, you get an error when creating or updating the
Application Gateway.
The following example creates a new application gateway with a pre-defined SSL policy.
# Create a resource group
$rg = New-AzureRmResourceGroup -Name ContosoRG -Location "East US"
# Create a subnet for the application gateway

$subnet = New-AzureRmVirtualNetworkSubnetConfig -Name subnet01 -AddressPrefix 10.0.0.0/24
# Create a virtual network with a 10.0.0.0/16 address space

$vnet = New-AzureRmVirtualNetwork -Name appgwvnet -ResourceGroupName $rg.ResourceGroupName -Location "East US"
-AddressPrefix 10.0.0.0/16 -Subnet $subnet
# Retrieve the subnet object for later use

$subnet = $vnet.Subnets[0]
# Create a public IP address

$publicip = New-AzureRmPublicIpAddress -ResourceGroupName $rg.ResourceGroupName -name publicIP01 -location
"East US" -AllocationMethod Dynamic
# Create a ip configuration object

# Create a backend pool for backend web servers

$pool = New-AzureRmApplicationGatewayBackendAddressPool -Name pool01 -BackendIPAddresses 134.170.185.46,
134.170.188.221,134.170.185.50
# Define the backend http settings to be used.

CookieBasedAffinity Enabled
# Create a new port for SSL

# Upload an existing pfx certificate for SSL offload

$password = ConvertTo-SecureString -String "P@ssw0rd" -AsPlainText -Force
$cert = New-AzureRmApplicationGatewaySslCertificate -Name cert01 -CertificateFile C:\folder\contoso.pfx -
Password $password
# Create a frontend IP configuration for the public IP address

$fipconfig = New-AzureRmApplicationGatewayFrontendIPConfig -Name fipconfig01 -PublicIPAddress $publicip
# Create a new listener with the certificate, port, and frontend ip.
$listener = New-AzureRmApplicationGatewayHttpListener -Name listener01 -Protocol Https -
FrontendIPConfiguration $fipconfig -FrontendPort $fp -SslCertificate $cert
# Create a new rule for backend traffic routing

# Define the size of the application gateway

# Configure the SSL policy to use a different pre-defined policy

$policy = New-AzureRmApplicationGatewaySslPolicy -PolicyType Predefined -PolicyName AppGwSslPolicy20170401S
# Create the application gateway.

$appgw = New-AzureRmApplicationGateway -Name appgwtest -ResourceGroupName $rg.ResourceGroupName -Location
"East US" -BackendAddressPools $pool -BackendHttpSettingsCollection $poolSetting -FrontendIpConfigurations
$fipconfig -GatewayIpConfigurations $gipconfig -FrontendPorts $fp -HttpListeners $listener -
RequestRoutingRules $rule -Sku $sku -SslCertificates $cert -SslPolicy $policy
Update an existing application gateway with a pre-defined SSL policy

To set a custom SSL policy, pass the following parameters: PolicyType, MinProtocolVersion, CipherSuite, and
ApplicationGateway. To set a Predefined SSL policy, pass the following parameters: PolicyType, PolicyName,
and ApplicationGateway. If you attempt to pass other parameters, you get an error when creating or updating
the Application Gateway.
In the following example, there are code samples for both Custom Policy and Predefined Policy. Uncomment the
policy you want to use.
# You have to change these parameters to match your environment.

$AppGWname = "YourAppGwName"
$RG = "YourResourceGroupName"
$AppGw = get-azurermapplicationgateway -Name $AppGWname -ResourceGroupName $RG
# Choose either custom policy or prefedined policy and uncomment the one you want to use.
# SSL Custom Policy

# Set-AzureRmApplicationGatewaySslPolicy -PolicyType Custom -MinProtocolVersion TLSv1_2 -CipherSuite
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_RSA_WITH_AES_128_CBC_SHA256" -ApplicationGateway $AppGw
# SSL Predefined Policy

# Set-AzureRmApplicationGatewaySslPolicy -PolicyType Predefined -PolicyName "AppGwSslPolicy20170401S" -
ApplicationGateway $AppGW
# Update AppGW
# The SSL policy options are not validated or updated on the Application Gateway until this cmdlet is
executed.
$SetGW = Set-AzureRmApplicationGateway -ApplicationGateway $AppGW
Next steps
Visit Application Gateway redirect overview to learn how to redirect HTTP traffic to an HTTPS endpoint.
Create an application gateway with a web application
firewall using the Azure portal
You can use the Azure portal to create an application gateway with a web application firewall (WAF ). The WAF uses
OWASP rules to protect your application. These rules include protection against attacks such as SQL injection,
cross-site scripting attacks, and session hijacks.
Log in to Azure

Select WAF for the tier of the application gateway.
and then click OK.
8. Accept the default values for the Listener configuration, leave the Web application firewall disabled, and then
click OK.
9. Review the settings on the summary page, and then click OK to create network resources and the application
gateway. It may take several minutes for the application gateway to be created, wait until the deployment
finishes successfully before moving on to the next section.
Add a subnet

1. Click New.
4. Click OK.
Install IIS
-VMName myVM `
-Location EastUS
Add backend servers
1. Click All resources, and then click myAppGateway.
3. Click Add target to add each virtual machine that you created to the backend pool.
4. Click Save.

Create a storage account
In this tutorial, the application gateway uses a storage account to store data for detection and prevention purposes.
You could also use Log Analytics or Event Hub to record data.
2. Select Storage, and then select Storage account - blob, file, table, queue.
3. Enter the name of the storage account, select Use existing for the resource group, and then select
myResourceGroupAG. In this example, the storage account name is myagstore1. Accept the default values for
the other settings and then click Create.
Configure diagnostics to record data into the ApplicationGatewayAccessLog, ApplicationGatewayPerformanceLog,
and ApplicationGatewayFirewallLog logs.
1. In the left-hand menu, click All resources, and then select myAppGateway.
2. Under Monitoring, click Diagnostics logs.
3. Click Add diagnostics setting.
4. Enter myDiagnosticsSettings as the name for the diagnostics settings.
5. Select Archive to a storage account, and then click Configure to select the myagstore1 storage account that
you previously created.
6. Select the application gateway logs to collect and retain.
7. Click Save.
1. Find the public IP address for the application gateway on the Overview screen. Click All resources and then
click myAGPublicIPAddress.
2. Copy the public IP address, and then paste it into the address bar of your browser.
Next steps
In this article, you learned how to:
Enable web application firewall using Azure
PowerShell
You can restrict traffic on an application gateway with a web application firewall (WAF ). The WAF uses OWASP
rules to protect your application. These rules include protection against attacks such as SQL injection, cross-site
scripting attacks, and session hijacks.
Set up the network
If you prefer, you can complete this tutorial using Azure CLI.

Azure tools preinstalled and configured to use with your account. Just click the Copy to copy the code, paste it
into the Cloud Shell, and then press enter to run it. There are a few ways to launch the Cloud Shell:
3.6 or later. Run Get-Module -ListAvailable AzureRM to find the version. If you need to upgrade, see Install Azure

Create the subnet configurations named myBackendSubnet and myAGSubnet using New -
-Name myAGSubnet `
-Location eastus `
-Name myVNet `
-Location eastus `

In this section you create resources that support the application gateway, and then finally create it and a WAF. The
resources that you create include:
-Name myVNet
-Subnet $subnet
-Port 80

AzureRmApplicationGatewayBackendAddressPool. Configure the settings for the backend address pools using
New -AzureRmApplicationGatewayBackendHttpSettings.
-Port 80 `
-Protocol Http `
-RequestTimeout 120

A listener is required to enable the application gateway to route traffic appropriately to the backend address pools.
In this example, you create a basic listener that listens for traffic at the root URL.
Create a listener named mydefaultListener using New -AzureRmApplicationGatewayHttpListener with the
which backend pool to use for incoming traffic. Create a basic rule named rule1 using New -
-Protocol Http `
-Name rule1 `
-RuleType Basic `
Create the application gateway with the WAF

New -AzureRmApplicationGatewaySku. Specify the WAF configuration using New -
AzureRmApplicationGatewayWebApplicationFirewallConfiguration. And then create the application gateway
named myAppGateway using New -AzureRmApplicationGateway.
-Name WAF_Medium `
-Tier WAF `
-Capacity 2
$wafConfig = New-AzureRmApplicationGatewayWebApplicationFirewallConfiguration `
-Enabled $true `
-FirewallMode "Detection"
-Location eastus `
-Sku $sku `
-WebApplicationFirewallConfig $wafConfig

-Name myVNet
-Name myAppGateway
-Location eastus `
-SkuCapacity 2 `
-Primary $true `
New-AzureRmVmss `
-Name myvmss `
Install IIS


-Name myvmss `
In this tutorial, the application gateway uses a storage account to store data for detection and prevention
purposes. You could also use Log Analytics or Event Hub to record data.
Create the storage account
Create a storage account named myagstore1 using New -AzureRmStorageAccount.
$storageAccount = New-AzureRmStorageAccount `
-Name myagstore1 `
-Location eastus `
-SkuName "Standard_LRS"
Configure diagnostics to record data into the ApplicationGatewayAccessLog,
ApplicationGatewayPerformanceLog, and ApplicationGatewayFirewallLog logs using Set-
AzureRmDiagnosticSetting.
-Name myAppGateway
$store = Get-AzureRmStorageAccount `
-Name myagstore1
Set-AzureRmDiagnosticSetting `
-ResourceId $appgw.Id `
-StorageAccountId $store.Id `
-Categories ApplicationGatewayAccessLog, ApplicationGatewayPerformanceLog, ApplicationGatewayFirewallLog `
-Enabled $true `
-RetentionEnabled $true `
-RetentionInDays 30

IP address, and then paste it into the address bar of your browser.
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources using
Remove-AzureRmResourceGroup.
Next steps
Set up the network
Customize web application firewall rules through the
Azure portal
The Azure Application Gateway web application firewall (WAF ) provides protection for web applications. These
protections are provided by the Open Web Application Security Project (OWASP ) Core Rule Set (CRS ). Some
rules can cause false positives and block real traffic. For this reason, Application Gateway provides the capability to
customize rule groups and rules. For more information on the specific rule groups and rules, see List of web
application firewall CRS rule groups and rules.
NOTE
If your application gateway is not using the WAF tier, the option to upgrade the application gateway to the WAF tier appears
in the right pane.
View rule groups and rules

To view rule groups and rules
1. Browse to the application gateway, and then select Web application firewall.
2. Select Advanced rule configuration.
This view shows a table on the page of all the rule groups provided with the chosen rule set. All of the rule's
check boxes are selected.
Search for rules to disable
The Web application firewall settings blade provides the capability to filter the rules through a text search. The
result displays only the rule groups and rules that contain the text you searched for.
Disable rule groups and rules
When your're disabling rules, you can disable an entire rule group or specific rules under one or more rule groups.
To disable rule groups or specific rules
1. Search for the rules or rule groups that you want to disable.
2. Clear the check boxes for the rules that you want to disable.
3. Select Save.
Next steps
After you configure your disabled rules, you can learn how to view your WAF logs. For more information, see
Application Gateway diagnostics.
Customize web application firewall rules through
PowerShell
application firewall CRS Rule groups and rules.

The following code examples show how to view rules and rule groups that are configurable on a WAF -enabled
View rule groups
The following example shows how to view rule groups:
Get-AzureRmApplicationGatewayAvailableWafRuleSets
The following output is a truncated response from the preceding example:

OWASP (Ver. 3.0):
REQUEST-910-IP-REPUTATION:
Description:
Rules:
RuleId Description
------ -----------
910011 Rule 910011
910012 Rule 910012
... ...
REQUEST-911-METHOD-ENFORCEMENT:
Description:
Rules:
RuleId Description
------ -----------
911011 Rule 911011
... ...
OWASP (Ver. 2.2.9):
crs_20_protocol_violations:
Description:
Rules:
RuleId Description
------ -----------
960911 Invalid HTTP Request Line
981227 Apache Error: Invalid URI in Request.
960000 Attempted multipart/form-data bypass
... ...
Disable rules
The following example disables rules 910018 and 910017 on an application gateway:
$disabledrules=New-AzureRmApplicationGatewayFirewallDisabledRuleGroupConfig -RuleGroupName REQUEST-910-IP-

REPUTATION -Rules 910018,910017
Set-AzureRmApplicationGatewayWebApplicationFirewallConfiguration -ApplicationGateway $gw -Enabled $true -
FirewallMode Detection -RuleSetVersion 3.0 -RuleSetType OWASP -DisabledRuleGroups $disabledrules
Next steps
Application Gateway Diagnostics.
Customize web application firewall rules through the
Azure CLI 2.0
application firewall CRS rule groups and rules.

The following code examples show how to view rules and rule groups that are configurable.
View rule groups
The following example shows how to view the rule groups:
az network application-gateway waf-config list-rule-sets --type OWASP

[
{
"id":
"/subscriptions//resourceGroups//providers/Microsoft.Network/applicationGatewayAvailableWafRuleSets/",
"location": null,
"name": "OWASP_3.0",
"provisioningState": "Succeeded",
"resourceGroup": "",
"ruleGroups": [
{
"description": "",
"ruleGroupName": "REQUEST-910-IP-REPUTATION",
"rules": null
},
...
],
"tags": null,
"type": "Microsoft.Network/applicationGatewayAvailableWafRuleSets"
},
{
"id":
"location": null,
"name": "OWASP_2.2.9",
"ruleGroups": [
{
"description": "",
"ruleGroupName": "crs_20_protocol_violations",
"rules": null
},
...
],
"ruleSetVersion": "2.2.9",
"tags": null,
}
]
View rules in a rule group

The following example shows how to view rules in a specified rule group:
az network application-gateway waf-config list-rule-sets --group "REQUEST-910-IP-REPUTATION"

[
{
"id":
"location": null,
"name": "OWASP_3.0",
"ruleGroups": [
{
"description": "",
"ruleGroupName": "REQUEST-910-IP-REPUTATION",
"rules": [
{
"description": "Rule 910011",
"ruleId": 910011
},
...
]
}
],
"tags": null,
}
]
Disable rules
The following example disables rules 910018 and 910017 on an application gateway:
az network application-gateway waf-config set --resource-group AdatumAppGatewayRG --gateway-name

AdatumAppGateway --enabled true --rule-set-version 3.0 --disabled-rules 910018 910017
Next steps
Application Gateway diagnostics.
Create an application gateway with path-based
routing rules using the Azure portal
You can use the Azure portal to configure URL path-based routing rules when you create an application gateway.
In this tutorial, you create backend pools using virtual machines. You then create routing rules that make sure web
Create virtual machines for backend servers
Create backend pools with the backend servers
Create a backend listener
Create a path-based routing rule
Log in to Azure

and then click OK.
click OK.
Add a subnet
Create virtual machines

In this example, you create three virtual machines to be used as backend servers for the application gateway. You
1. Click New.
myVM1 - for the name of the virtual machine.
4. Click OK.
Install IIS

samples/master/application-gateway/iis/appgatewayurl.ps1"); "commandToExecute" = "powershell -
ExecutionPolicy Unrestricted -File appgatewayurl.ps1" }
-Location eastus `
-VMName myVM1 `
-Settings $publicSettings
3. Create two more virtual machines and install IIS using the steps that you just finished. Enter the names of
myVM2 and myVM3 for the names and for the values of VMName in Set-AzureRmVMExtension.
Create backend pools with the virtual machines

1. Click All resources and then click myAppGateway.
3. Click Add target to add myVM1 to appGatewayBackendPool.
4. Click Save.
5. Click Backend pools and then click Add.
6. Enter a name of imagesBackendPool and add myVM2 using Add target.
7. Click OK.
8. Click Add again to add another backend pool with a name of videoBackendPool and add myVM3 to it.

1. Click Listeners and the click Basic.
2. Enter myBackendListener for the name, myFrontendPort for the name of the frontend port, and then 8080 as
the port for the listener.
3. Click OK.

1. Click Rules and then click Path-based.
2. Enter rule2 for the name.
3. Enter Images for the name of the first path. Enter /images/* for the path. Select imagesBackendPool for the
backend pool.
4. Enter Video for the name of the second path. Enter /video/* for the path. Select videoBackendPool for the
backend pool.
5. Click OK.

2. Copy the public IP address, and then paste it into the address bar of your browser. Such as,
http://40.121.222.19.
3. Change the URL to http://<ip-address>:8080/images/test.htm, substituting <ip-address> with your IP

address, and you should see something like the following example:
4. Change the URL to http://<ip-address>:8080/video/test.htm, substituting <ip-address> with your IP
address, and you should see something like the following example:
Next steps
In this article, you learned how to
Route web traffic based on the URL using Azure
PowerShell
You can use Azure PowerShell to configure web traffic routing to specific scalable server pools based on the URL
that is used to access your application. In this tutorial, you create an Azure Application Gateway with three
backend pools using Virtual Machine Scale Sets. Each of the backend pools serves a specific purpose such as,
common data, images, and video. Routing traffic to separate pools ensures that your customers get the
information that they need when they need it.
To enable traffic routing, you create routing rules assigned to listeners that listen on specific ports to ensure web
Set up the network

Because of the time needed to create resources, it can take up to 90 minutes to complete this tutorial.

You need to create a resource group that contains all of the resources for your application.
Create an Azure resource group using New -AzureRmResourceGroup.

Whether you have an existing virtual network or create a new one, you need to make sure that it contains a subnet
that is only used for application gateways. In this tutorial, you create a subnet for the application gateway and a
subnet for the scale sets. You create a public IP address to enable access to the resources in the application
gateway.
Create the subnet configurations myAGSubnet and myBackendSubnet using New -
-Name myAGSubnet `
-Location eastus `
-Name myVNet `
-Location eastus `

In this section you create resources that support the application gateway, and then finally create it. The resources
-Name myVNet
$pip = Get-AzureRmPublicIpAddress `
-Name myAGPublicIPAddress
-Subnet $subnet
-Port 80
Create the default pool and settings

Create the default backend pool named appGatewayBackendPool for the application gateway using New -
-Port 80 `
-Protocol Http `
-RequestTimeout 120

tutorial, you create two listeners. The first basic listener that you create listens for traffic at the root URL. The
second listener that you create listens for traffic at specific URLs.
Create the default listener named myDefaultListener using New -AzureRmApplicationGatewayHttpListener with
the frontend configuration and frontend port that you previously created.
A rule is required for the listener to know which backend pool to use for incoming traffic. Create a basic rule
named rule1 using New -AzureRmApplicationGatewayRequestRoutingRule.
-Name myDefaultListener `
-Protocol Http `
-Name rule1 `
-RuleType Basic `

AzureRmApplicationGateway.
-Tier Standard `
-Capacity 2
-Location eastus `
-Sku $sku
It may take up to 30 minutes for the application gateway to be created, wait until the deployment finishes
successfully before moving on to the next section. At this point in the tutorial, you have an application gateway
that is listening for traffic on port 80 and sends that traffic to a default pool of servers.
Add image and video backend pools and port
Add backend pools named imagesBackendPool and videoBackendPool to your application gatewayAdd-
AzureRmApplicationGatewayBackendAddressPool. Add the frontend port for the pools using Add-
AzureRmApplicationGatewayFrontendPort. Submit the changes to the application gateway using Set-
-Name myAppGateway
Add-AzureRmApplicationGatewayBackendAddressPool `
-ApplicationGateway $appgw `
-Name imagesBackendPool
-Name videoBackendPool
Add-AzureRmApplicationGatewayFrontendPort `
-Name bport `
-Port 8080
Set-AzureRmApplicationGateway -ApplicationGateway $appgw
Updating the application gateway can also take up to 20 minutes to finish.

Add backend listener
Add the backend listener named backendListener that's needed to route traffic using Add-
AzureRmApplicationGatewayHttpListener.
-Name myAppGateway
$backendPort = Get-AzureRmApplicationGatewayFrontendPort `
-Name bport
$fipconfig = Get-AzureRmApplicationGatewayFrontendIPConfig `
Add-AzureRmApplicationGatewayHttpListener `
-Name backendListener `
-Protocol Http `
-FrontendPort $backendPort
Add URL path map

URL path maps make sure that the URLs sent to your application are routed to specific backend pools. Create
URL path maps named imagePathRule and videoPathRule using New -
AzureRmApplicationGatewayPathRuleConfig and Add-AzureRmApplicationGatewayUrlPathMapConfig.
-Name myAppGateway
$poolSettings = Get-AzureRmApplicationGatewayBackendHttpSettings `
-Name myPoolSettings
$imagePool = Get-AzureRmApplicationGatewayBackendAddressPool `
$videoPool = Get-AzureRmApplicationGatewayBackendAddressPool `
$defaultPool = Get-AzureRmApplicationGatewayBackendAddressPool `
$imagePathRule = New-AzureRmApplicationGatewayPathRuleConfig `
-Name imagePathRule `
-Paths "/images/*" `
-BackendAddressPool $imagePool `
$videoPathRule = New-AzureRmApplicationGatewayPathRuleConfig `
-Name videoPathRule `
-Paths "/video/*" `
-BackendAddressPool $videoPool `
Add-AzureRmApplicationGatewayUrlPathMapConfig `
-Name urlpathmap `
-PathRules $imagePathRule, $videoPathRule `
-DefaultBackendAddressPool $defaultPool `
-DefaultBackendHttpSettings $poolSettings
Add routing rule

The routing rule associates the URL map with the listener that you created. Add the rule named rule2 using Add-
-Name myAppGateway
$backendlistener = Get-AzureRmApplicationGatewayHttpListener `
-Name backendListener
$urlPathMap = Get-AzureRmApplicationGatewayUrlPathMapConfig `
-Name urlpathmap
Add-AzureRmApplicationGatewayRequestRoutingRule `
-Name rule2 `
-RuleType PathBasedRouting `
-HttpListener $backendlistener `
-UrlPathMap $urlPathMap

The scale sets that you create are named myvmss1, myvmss2, and myvmss3. You assign the scale set to the
backend pool when you configure the IP settings.
-Name myVNet
-Name myAppGateway
$imagesPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name imagesBackendPool `
-Name videoBackendPool `
for ($i=1; $i -le 3; $i++)

{
if ($i -eq 1)
{
$poolId = $backendPool.Id
}
if ($i -eq 2)
{
$poolId = $imagesPool.Id
}
if ($i -eq 3)
{
$poolId = $videoPool.Id
}
-Name myVmssIPConfig$i `
-ApplicationGatewayBackendAddressPoolsId $poolId
-Location eastus `
-SkuCapacity 2 `
-ComputerNamePrefix myvmss$i
-Name myVmssNetConfig$i `
-Primary $true `
New-AzureRmVmss `
-Name myvmss$i `
}
Install IIS
Each scale set contains two virtual machine instances on which you install IIS, which runs a sample page to test
whether the application gateway is working.

for ($i=1; $i -le 3; $i++)

{
$vmss = Get-AzureRmVmss -ResourceGroupName myResourceGroupAG -VMScaleSetName myvmss$i
-Name myvmss$i `
}

Use Get-AzureRmPublicIPAddress to get the public IP address of the application gateway. Copy the public IP
address, and then paste it into the address bar of your browser. Such as, http://52.168.55.24,
http://52.168.55.24:8080/images/test.htm, or http://52.168.55.24:8080/video/test.htm.
Change the URL to http://<ip-address>:8080/images/test.htm, substituting your IP address for <ip-address>, and
Change the URL to http://<ip-address>:8080/video/test.htm, substituting your IP address for <ip-address>, and
Clean up resources
Next steps
Set up the network
Redirect web traffic based on the URL
Create and configure an application gateway to host
multiple web sites using the Azure portal
You can use the Azure portal to configure the hosting of multiple web sites when you create an application
gateway. In this tutorial, you define backend address pools using virtual machines. You then configure listeners and
rules based on domains that you own to make sure web traffic arrives at the appropriate servers in the pools. This
tutorial assumes that you own multiple domains and uses examples of www.contoso.com and www.fabrikam.com.
Log in to Azure

and then click OK.
click OK.
Add a subnet
Create virtual machines

also install IIS on the virtual machines to verify that traffic is routing correctly.
1. Click New.
contosoVM - for the name of the virtual machine.
4. Click OK.
Install IIS

samples/master/application-gateway/iis/appgatewayurl.ps1"); "commandToExecute" = "powershell -
ExecutionPolicy Unrestricted -File appgatewayurl.ps1" }
-Location eastus `
-VMName contosoVM `
-Settings $publicSettings
3. Create the second virtual machine and install IIS using the steps that you just finished. Enter the names of
fabrikamVM for the name and for the value of VMName in Set-AzureRmVMExtension.
Create backend pools with the virtual machines

1. Click All resources and then click myAppGateway.
2. Click Backend pools, and then click Add.
3. Enter a name of contosoPool and add contosoVM using Add target.
4. Click OK.
5. Click Backend pools and then click Add.
6. Create the fabrikamPool with the fabrikamVM using the steps that you just finished.

1. Click Listeners and then click Multi-site.
2. Enter these values for the listener:
contosoListener - for the name of the listener.
www.contoso.com - replace this host name example with your domain name.
3. Click OK.
4. Create a second listener using the name of fabrikamListener and use your second domain name. In this
example, www.fabrikam.com is used.

Rules are processed in the order they are listed, and traffic is directed using the first rule that matches regardless of
specificity. For example, if you have a rule using a basic listener and a rule using a multi-site listener both on the
same port, the rule with the multi-site listener must be listed before the rule with the basic listener in order for the
multi-site rule to function as expected.
In this example, you create two new rules and delete the default rule that was created when you created the
1. Click Rules and then click Basic.
2. Enter contosoRule for the name.
3. Select contosoListener for the listener.
4. Select contosoPool for the backend pool.
5. Click OK.
6. Create a second rule using the names of fabrikamRule, fabrikamListener, and fabrikamPool.
7. Delete the default rule named rule1 by clicking it, and then clicking Delete.

a CNAME record in your domain. The use of A-records is not recommended because the VIP may change when
the application gateway is restarted.
2. Copy the DNS address and use it as the value for a new CNAME record in your domain.

1. Enter your domain name into the address bar of your browser. Such as, http://www.contoso.com.
2. Change the address to your other domain and you should see something like the following example:
Next steps
Create an application gateway that hosts multiple
web sites using Azure PowerShell
You can use Azure Powershell to configure the hosting of multiple web sites when you create an application
gateway. In this tutorial, you define backend address pools using virtual machines scale sets. You then configure
listeners and rules based on domains that you own to make sure web traffic arrives at the appropriate servers in
the pools. This tutorial assumes that you own multiple domains and uses examples of www.contoso.com and
www.fabrikam.com.
Set up the network



Create the subnet configurations using New -AzureRmVirtualNetworkSubnetConfig. Create the virtual network
using New -AzureRmVirtualNetwork with the subnet configurations. And finally, create the public IP address
using New -AzureRmPublicIpAddress. These resources are used to provide network connectivity to the application
gateway and its associated resources.
-Name myAGSubnet `
-Location eastus `
-Name myVNet `
-Location eastus `

Associate the subnet that you previously created to the application gateway using New -
AzureRmApplicationGatewayIPConfiguration. Assign the public IP address to the application gateway using
-Name myVNet
-Subnet $subnet
-Port 80
Create the backend pools and settings

Create the first backend address pool for the application gateway using New -
AzureRmApplicationGatewayBackendAddressPool. Configure the settings for the pool using New -
$contosoPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name contosoPool
$fabrikamPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name fabrikamPool
-Port 80 `
-Protocol Http `
-RequestTimeout 120
Create the listeners and rules

Listeners are required to enable the application gateway to route traffic appropriately to the backend address
pools. In this tutorial, you create two listeners for your two domains. In this example, listeners are created for the
domains of www.contoso.com and www.fabrikam.com.
Create the first listener using New -AzureRmApplicationGatewayHttpListener with the frontend configuration and
frontend port that you previously created. A rule is required for the listener to know which backend pool to use for
incoming traffic. Create a basic rule named contosoRule using New -
$contosolistener = New-AzureRmApplicationGatewayHttpListener `
-Name contosoListener `
-Protocol Http `
-HostName "www.contoso.com"
$fabrikamlistener = New-AzureRmApplicationGatewayHttpListener `
-Name fabrikamListener `
-Protocol Http `
-HostName "www.fabrikam.com"
$contosoRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name contosoRule `
-RuleType Basic `
-HttpListener $contosoListener `
-BackendAddressPool $contosoPool `
$fabrikamRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name fabrikamRule `
-RuleType Basic `
-HttpListener $fabrikamListener `
-BackendAddressPool $fabrikamPool `

New -AzureRmApplicationGatewaySku, and then create it using New -AzureRmApplicationGateway.
-Tier Standard `
-Capacity 2
-Location eastus `
-BackendAddressPools $contosoPool, $fabrikamPool `
-HttpListeners $contosoListener, $fabrikamListener `
-RequestRoutingRules $contosoRule, $fabrikamRule `
-Sku $sku

In this example, you create two virtual machine scale sets that support the two backend pools that you created.
The scale sets that you create are named myvmss1 and myvmss2. Each scale set contains two virtual machine
instances on which you install IIS. You assign the scale set to the backend pool when you configure the IP settings.
-Name myVNet
-Name myAppGateway
$contosoPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name contosoPool `
$fabrikamPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name fabrikamPool `
for ($i=1; $i -le 2; $i++)

{
if ($i -eq 1)
{
$poolId = $contosoPool.Id
}
if ($i -eq 2)
{
$poolId = $fabrikamPool.Id
}
-Location eastus `
-SkuCapacity 2 `
-Primary $true `
New-AzureRmVmss `
-Name myvmss$i `
}
Install IIS
for ($i=1; $i -le 2; $i++)

{
$vmss = Get-AzureRmVmss `
-VMScaleSetName myvmss$i

-Name myvmss$i `
}
Create CNAME record in your domain

After the application gateway is created with its public IP address, you can get the DNS address and use it to
create a CNAME record in your domain. You can use Get-AzureRmPublicIPAddress to get the DNS address of the
you create. The use of A-records is not recommended because the VIP may change when the application gateway
is restarted.

Change the address to your other domain and you should see something like the following example:
Clean up resources
Next steps
Set up the network
Create an application gateway with URL path-based routing rules
Create an application gateway with HTTP to HTTPS
redirection using Azure PowerShell
You can use the Azure PowerShell to create an application gateway with a certificate for SSL termination. A routing
rule is used to redirect HTTP traffic to the HTTPS port in your application gateway. In this example, you also create
a virtual machine scale set for the backend pool of the application gateway that contains two virtual machine
instances.
Set up a network
Add a listener and redirection rule
This tutorial requires the Azure PowerShell module version 3.6 or later. Run Get-Module -ListAvailable AzureRM to
find the version. If you need to upgrade, see Install Azure PowerShell module. To run the commands in this tutorial,
you also need to run Login-AzureRmAccount to create a connection with Azure.

For production use, you should import a valid certificate signed by a trusted provider. For this tutorial, you create a
self-signed certificate using New -SelfSignedCertificate. You can use Export-PfxCertificate with the Thumbprint that
was returned to export a pfx file from the certificate.
New-SelfSignedCertificate `
-certstorelocation cert:\localmachine\my `
You should see something like this result:
Thumbprint Subject
---------- -------
Use the thumbprint to create the pfx file:

Export-PfxCertificate `
-cert cert:\localMachine\my\E1E81C23B3AD33F9B4D1717B20AB65DBB91AC630 `
-FilePath c:\appgwcert.pfx `
-Password $pwd
resource group named myResourceGroupAG using New -AzureRmResourceGroup.

Create the subnet configurations for myBackendSubnet and myAGSubnet using New -
-Name myAGSubnet `
-Location eastus `
-Name myVNet `
-Location eastus `

New -AzureRmApplicationGatewayFrontendIPConfig. And then you can create the HTTPS port using New -
AzureRmApplicationGatewayFrontendPort.
-Name myVNet
-Subnet $subnet
$frontendPort = New-AzureRmApplicationGatewayFrontendPort `
-Port 443

-Port 80 `
-Protocol Http `
-RequestTimeout 120

example, you create a basic listener that listens for HTTPS traffic at the root URL.
Create a certificate object using New -AzureRmApplicationGatewaySslCertificate and then create a listener named
appGatewayHttpListener using New -AzureRmApplicationGatewayHttpListener with the frontend configuration,
frontend port, and certificate that you previously created. A rule is required for the listener to know which backend
pool to use for incoming traffic. Create a basic rule named rule1 using New -
$pwd = ConvertTo-SecureString `
-String "Azure123456!" `
-Force `
-AsPlainText
$cert = New-AzureRmApplicationGatewaySslCertificate `
-Name "appgwcert" `
-CertificateFile "c:\appgwcert.pfx" `
-Password $pwd
$defaultListener = New-AzureRmApplicationGatewayHttpListener `
-Name appGatewayHttpListener `
-Protocol Https `
-FrontendPort $frontendPort `
-SslCertificate $cert
-Name rule1 `
-RuleType Basic `
-HttpListener $defaultListener `

AzureRmApplicationGateway with the certificate.
-Tier Standard `
-Capacity 2
-Location eastus `
-FrontendPorts $frontendPort `
-HttpListeners $defaultListener `
-Sku $sku `
-SslCertificates $cert

Add the HTTP port
Add the HTTP port to the application gateway using Add-AzureRmApplicationGatewayFrontendPort.
-ResourceGroupName myResourceGroupAG
-Name httpPort `
-Port 80 `
Add the HTTP listener

Add the HTTP listener named myListener to the application gateway using Add-
$fp = Get-AzureRmApplicationGatewayFrontendPort `
-Name httpPort `
-Name myListener `
-Protocol Http `
-FrontendPort $fp `
Add the redirection configuration

Add the HTTP to HTTPS redirection configuration to the application gateway using Add-
AzureRmApplicationGatewayRedirectConfiguration.
$defaultListener = Get-AzureRmApplicationGatewayHttpListener `
-Name appGatewayHttpListener `
Add-AzureRmApplicationGatewayRedirectConfiguration -Name httpToHttps `
-RedirectType Permanent `
-TargetListener $defaultListener `
-IncludePath $true `
-IncludeQueryString $true `
Add the routing rule

Add the routing rule with the redirection configuration to the application gateway using Add-
$myListener = Get-AzureRmApplicationGatewayHttpListener `
-Name myListener `
$redirectConfig = Get-AzureRmApplicationGatewayRedirectConfiguration `
-Name httpToHttps `
-Name rule2 `
-RuleType Basic `
-HttpListener $myListener `
-RedirectConfiguration $redirectConfig `

-Name myVNet
-Name myAppGateway
-Location eastus `
-SkuCapacity 2 `
-Primary $true `
New-AzureRmVmss `
-Name myvmss `
Install IIS

-Name myvmss `

IP address, and then paste it into the address bar of your browser. For example, http://52.170.203.149

To accept the security warning if you used a self-signed certificate, select Details and then Go on to the webpage.
Your secured IIS website is then displayed as in the following example:
Next steps
Set up a network
Create an application gateway with HTTP to HTTPS
redirection using the Azure CLI
You can use the Azure CLI to create an application gateway with a certificate for SSL termination. A routing rule is
used to redirect HTTP traffic to the HTTPS port in your application gateway. In this example, you also create a
virtual machine scale set for the backend pool of the application gateway that contains two virtual machine
instances.
Set up a network



For production use, you should import a valid certificate signed by a trusted provider. For this tutorial, you create a
self-signed certificate and pfx file using the openssl command.
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out appgwcert.crt
Enter values that make sense for your certificate. You can accept the default values.
openssl pkcs12 -export -out appgwcert.pfx -inkey privateKey.key -in appgwcert.crt
Enter the password for the certificate. In this example, Azure123456! is being used.



--name myVNet \
--location eastus \

capacity, sku, and HTTP settings.
The application gateway is assigned to myAGSubnet and myAGPublicIPAddress that you previously created. In this
example, you associate the certificate that you created and its password when you create the application gateway.
--location eastus \
--capacity 2 \
--cert-file appgwcert.pfx \
--cert-password "Azure123456!"

Add the HTTP port
You can use az network application-gateway frontend-port create to add the HTTP port to the application gateway.

--port 80 \
--name httpPort
Add the HTTP listener

You can use az network application-gateway http-listener create to add the listener named myListener to the

--name myListener \
--frontend-port httpPort \

Add the HTTP to HTTPS redirection configuration to the application gateway using az network application-
gateway redirect-config create.
--name httpToHttps \
--type Permanent \
--target-listener appGatewayHttpListener \
--include-query-string true
Add the routing rule

Add the routing rule named rule2 with the redirection configuration to the application gateway using az network
application-gateway rule create.

--name rule2 \
--http-listener myListener \
--rule-type Basic \
--redirect-config httpToHttps

In this example, you create a virtual machine scale set named myvmss that provides servers for the backend pool in
the application gateway. The virtual machines in the scale set are associated with myBackendSubnet and
appGatewayBackendPool. To create the scale set, you can use az vmss create.
az vmss create \
--name myvmss \
--image UbuntuLTS \
Install NGINX

--version 2.0 \

To get the public IP address of the application gateway, you can use az network public-ip show. Copy the public IP
--output tsv
To accept the security warning if you used a self-signed certificate, select Details and then Go on to the webpage.
Your secured NGINX site is then displayed as in the following example:
Next steps
Set up a network
Create an application gateway with internal
You can use Azure Powershell to configure web traffic redirection when you create an application gateway. In this
tutorial, you define a backend pool using a virtual machines scale set. You then configure listeners and rules based
on domains that you own to make sure web traffic arrives at the appropriate pool. This tutorial assumes that you
own multiple domains and uses examples of www.contoso.com and www.contoso.org.
Set up the network
Add listeners and redirection rule
Create a virtual machine scale set with the backend pool



-Name myAGSubnet `
-Location eastus `
-Name myVNet `
-Location eastus `

New -AzureRmApplicationGatewayFrontendIPConfig. And then you can create the HTTP port using New -
-Name myVNet
-Subnet $subnet
$frontendPort = New-AzureRmApplicationGatewayFrontendPort `
-Port 80

Create a backend pool named contosoPool for the application gateway using New -
$contosoPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name contosoPool
-Port 80 `
-Protocol Http `
-RequestTimeout 120
Create the first listener and rule

tutorial, you create two listeners for your two domains. In this example, listeners are created for the domains of
www.contoso.com and www.contoso.org.
Create the first listener named contosoComListener using New -AzureRmApplicationGatewayHttpListener with the
which backend pool to use for incoming traffic. Create a basic rule named contosoComRule using New -
$contosoComlistener = New-AzureRmApplicationGatewayHttpListener `
-Name contosoComListener `
-Protocol Http `
-HostName "www.contoso.com"
-Name contosoComRule `
-RuleType Basic `
-HttpListener $contosoComListener `
-BackendAddressPool $contosoPool `

-Tier Standard `
-Capacity 2
-Location eastus `
-BackendAddressPools $contosoPool `
-FrontendPorts $frontendPort `
-HttpListeners $contosoComListener `
-Sku $sku
Add the second listener

Add the listener named contosoOrgListener that's needed to redirect traffic using Add-
-Name myAppGateway
$frontendPort = Get-AzureRmApplicationGatewayFrontendPort `
$ipconfig = Get-AzureRmApplicationGatewayFrontendIPConfig `
-Name contosoOrgListener `
-Protocol Http `
-FrontendIPConfiguration $ipconfig `
-HostName "www.contoso.org"

You can cconfigure redirection for the listener using Add-AzureRmApplicationGatewayRedirectConfiguration.
-Name myAppGateway
$contosoComlistener = Get-AzureRmApplicationGatewayHttpListener `
-Name contosoComListener `
$contosoOrglistener = Get-AzureRmApplicationGatewayHttpListener `
Add-AzureRmApplicationGatewayRedirectConfiguration `
-Name redirectOrgtoCom `
-RedirectType Found `
-TargetListener $contosoComListener `
-IncludeQueryString $true
Add the second routing rule

You can then associate the redirection configuration to a new rule named contosoOrgRule using Add-
-Name myAppGateway
$contosoOrglistener = Get-AzureRmApplicationGatewayHttpListener `
-Name redirectOrgtoCom `
-Name contosoOrgRule `
-RuleType Basic `
-HttpListener $contosoOrgListener `
-RedirectConfiguration $redirectConfig
In this example, you create a virtual machine scale set that supports the backend pool that you created. The scale
set that you create is named myvmss and contains two virtual machine instances on which you install IIS. You
assign the scale set to the backend pool when you configure the IP settings.
-Name myVNet
-Name myAppGateway
-Name contosoPool `
-Location eastus `
-SkuCapacity 2 `
-Primary $true `
New-AzureRmVmss `
-Name myvmss `
Install IIS

-Name myvmss `

a CNAME record in your domain. You can use Get-AzureRmPublicIPAddress to get the DNS address of the
is restarted.

Change the address to your other domain, for example http://www.contoso.org and you should see that the traffic
has been redirected back to the listener for www.contoso.com.
Next steps
Set up the network
Create a virtual machine scale set with the backend pools
Create an application gateway with internal
redirection using the Azure CLI
You can use the Azure CLI to configure web traffic redirection when you create an application gateway. In this
tutorial, you define a backend pool using a virtual machines scale set. You then configure listeners and rules based
on domains that you own to make sure web traffic arrives at the appropriate pool. This tutorial assumes that you
own multiple domains and uses examples of www.contoso.com and www.contoso.org.
Set up the network




can then add the subnet named myBackendSubnet that's needed by the backend pool of servers using az network
vnet subnet create. Create the public IP address named myAGPublicIPAddress using az network public-ip create.

--name myVNet \
--location eastus \

capacity, sku, and HTTP settings. The application gateway is assigned to myAGSubnet and myAGPublicIPAddress
that you previously created.

--location eastus \
--capacity 2 \

tutorial, you create two listeners for your two domains. In this example, listeners are created for the domains of
www.contoso.com and www.contoso.org.
Add the backend listeners that are needed to route traffic using az network application-gateway http-listener
create.
--name contosoComListener \
--host-name www.contoso.com
--name contosoOrgListener \
--host-name www.contoso.org

Add the redirection configuration that sends traffic from www.consoto.org to the listener for www.contoso.com in
the application gateway using az network application-gateway redirect-config create.

--name orgToCom \
--type Permanent \
--target-listener contosoListener \
--include-query-string true
Add routing rules

Rules are processed in the order in which they are created, and traffic is directed using the first rule that matches
the URL sent to the application gateway. For example, if you have a rule using a basic listener and a rule using a
multi-site listener both on the same port, the rule with the multi-site listener must be listed before the rule with the
basic listener in order for the multi-site rule to function as expected.
In this example, you create two new rules and delete the default rule that was created. You can add the rule using
az network application-gateway rule create.

--name contosoComRule \
--http-listener contosoComListener \
--rule-type Basic \
--name contosoOrgRule \
--http-listener contosoOrgListener \
--rule-type Basic \
--redirect-config orgToCom
az network application-gateway rule delete \
--name rule1 \
--resource-group myResourceGroupAG

In this example, you create a virtual machine scale set that supports the backend pool that you created. The scale
set that you create is named myvmss and contains two virtual machine instances on which you install NGINX.
az vmss create \
--name myvmss \
--image UbuntuLTS \
Install NGINX
Run this command in the shell window:

--version 2.0 \

a CNAME record in your domain. You can use az network public-ip show to get the DNS address of the
is restarted.

--query [dnsSettings.fqdn] \
--output tsv

Change the address to your other domain, for example http://www.contoso.org and you should see that the traffic
has been redirected back to the listener for www.contoso.com.
Next steps
Set up the network

Configure App Service Web Apps with Application
Gateway
Application gateway allows you to have an Azure Web App or other multi-tenant service as a back-end pool
member. In this article, you learn to configure an Azure web app with Application Gateway. The first example
shows you how to configure an existing application gateway to use a web app as a back-end pool member. The
second example shows you how to create a new application gateway with a web app as a back-end pool member.
Configure a web app behind an existing application gateway

The following example adds a web app as a back-end pool member to an existing application gateway. Both the
switch -PickHostNamefromBackendHttpSettings on the Probe configuration and -PickHostNameFromBackendAddress on
the back-end http settings must be provided in order for web apps to work.
# FQDN of the web app

$webappFQDN = "<enter your webapp FQDN i.e mywebsite.azurewebsites.net>"
# Retrieve an existing application gateway

$gw = Get-AzureRmApplicationGateway -Name ContosoAppGateway -ResourceGroupName $rg.ResourceGroupName
# Define the status codes to match for the probe

$match=New-AzureRmApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
# Add a new probe to the application gateway

Add-AzureRmApplicationGatewayProbeConfig -name webappprobe2 -ApplicationGateway $gw -Protocol Http -Path / -
Interval 30 -Timeout 120 -UnhealthyThreshold 3 -PickHostNameFromBackendHttpSettings -Match $match
# Retrieve the newly added probe

$probe = Get-AzureRmApplicationGatewayProbeConfig -name webappprobe2 -ApplicationGateway $gw
# Configure an existing backend http settings

Set-AzureRmApplicationGatewayBackendHttpSettings -Name appGatewayBackendHttpSettings -ApplicationGateway $gw -
PickHostNameFromBackendAddress -Port 80 -Protocol http -CookieBasedAffinity Disabled -RequestTimeout 30 -Probe
$probe
# Add the web app to the backend pool

Set-AzureRmApplicationGatewayBackendAddressPool -Name appGatewayBackendPool -ApplicationGateway $gw -
BackendFqdns $webappFQDN
# Update the application gateway

Configure a web application behind a new application gateway

This scenario deploys a web app with the asp.net getting started website and an application gateway.
# Defines a variable for a dotnet get started web app repository location
$gitrepo="https://github.com/Azure-Samples/app-service-web-dotnet-get-started.git"
# Unique web app name

$webappname="mywebapp$(Get-Random)"
# Creates a resource group

$rg = New-AzureRmResourceGroup -Name ContosoRG -Location Eastus
# Create an App Service plan in Free tier.
New-AzureRmAppServicePlan -Name $webappname -Location EastUs -ResourceGroupName $rg.ResourceGroupName -Tier
Free
# Creates a web app

$webapp = New-AzureRmWebApp -ResourceGroupName $rg.ResourceGroupName -Name $webappname -Location EastUs -
AppServicePlan $webappname
# Configure GitHub deployment from your GitHub repo and deploy once to web app.
$PropertiesObject = @{
repoUrl = "$gitrepo";
branch = "master";
isManualIntegration = "true";
}
Set-AzureRmResource -PropertyObject $PropertiesObject -ResourceGroupName $rg.ResourceGroupName -ResourceType
Microsoft.Web/sites/sourcecontrols -ResourceName $webappname/web -ApiVersion 2015-08-01 -Force
# Creates a subnet for the application gateway

# Creates a vnet for the application gateway

$vnet = New-AzureRmVirtualNetwork -Name appgwvnet -ResourceGroupName $rg.ResourceGroupName -Location EastUs -
AddressPrefix 10.0.0.0/16 -Subnet $subnet
# Retrieve the subnet object for use later

# Create a public IP address

$publicip = New-AzureRmPublicIpAddress -ResourceGroupName $rg.ResourceGroupName -name publicIP01 -location
EastUs -AllocationMethod Dynamic
# Create a new IP configuration

# Create a backend pool with the hostname of the web app

$pool = New-AzureRmApplicationGatewayBackendAddressPool -Name appGatewayBackendPool -BackendFqdns
$webapp.HostNames
# Define the status codes to match for the probe

$match = New-AzureRmApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
# Create a probe with the PickHostNameFromBackendHttpSettings switch for web apps

$probeconfig = New-AzureRmApplicationGatewayProbeConfig -name webappprobe -Protocol Http -Path / -Interval 30 -
Timeout 120 -UnhealthyThreshold 3 -PickHostNameFromBackendHttpSettings -Match $match
# Define the backend http settings

$poolSetting = New-AzureRmApplicationGatewayBackendHttpSettings -Name appGatewayBackendHttpSettings -Port 80 -
Protocol Http -CookieBasedAffinity Disabled -RequestTimeout 120 -PickHostNameFromBackendAddress -Probe
$probeconfig
# Create a new front-end port

# Create a new front end IP configuration

# Create a new listener using the front-end ip configuration and port created earlier
$listener = New-AzureRmApplicationGatewayHttpListener -Name listener01 -Protocol Http -FrontendIPConfiguration
$fipconfig -FrontendPort $fp
# Create a new rule

# Define the application gateway SKU to use

# Create the application gateway

$appgw = New-AzureRmApplicationGateway -Name ContosoAppGateway -ResourceGroupName $rg.ResourceGroupName -
$appgw = New-AzureRmApplicationGateway -Name ContosoAppGateway -ResourceGroupName $rg.ResourceGroupName -
Location EastUs -BackendAddressPools $pool -BackendHttpSettingsCollection $poolSetting -Probes $probeconfig -
FrontendIpConfigurations $fipconfig -GatewayIpConfigurations $gipconfig -FrontendPorts $fp -HttpListeners
$listener -RequestRoutingRules $rule -Sku $sku
Get application gateway DNS name

Once the gateway is created, the next step is to configure the front end for communication. When using a public IP,
application gateway requires a dynamically assigned DNS name, which is not friendly. To ensure end users can hit
the application gateway, a CNAME record can be used to point to the public endpoint of the application gateway.
To create the alias, retrieve the details of the application gateway and its associated IP/DNS name using the
PublicIPAddress element attached to the application gateway. This can be done with Azure DNS or other DNS
providers, by creating a CNAME record that points to the public IP address. The use of A-records is not
recommended since the VIP may change on restart of application gateway.
Get-AzureRmPublicIpAddress -ResourceGroupName ContosoRG -Name publicIP01
Name : publicIP01
ResourceGroupName : ContosoRG
Location : eastus
Id :
/subscriptions/<subscription_id>/resourceGroups/ContosoRG/providers/Microsoft.Network/publicIPAddresses/publicI
P01
Etag : W/"00000d5b-54ed-4907-bae8-99bd5766d0e5"
ResourceGuid : 00000000-0000-0000-0000-000000000000
ProvisioningState : Succeeded
Tags :
PublicIpAllocationMethod : Dynamic
IpAddress : xx.xx.xxx.xx
PublicIpAddressVersion : IPv4
IdleTimeoutInMinutes : 4
IpConfiguration : {
"Id":
"/subscriptions/<subscription_id>/resourceGroups/ContosoRG/providers/Microsoft.Network/applicationGateways/Cont
osoAppGateway/frontendIP
Configurations/frontend1"
}
DnsSettings : {
"Fqdn": "00000000-0000-xxxx-xxxx-xxxxxxxxxxxx.cloudapp.net"
}
Next steps
Learn how to configure redirection by visiting: Configure redirection on Application Gateway with PowerShell.
Create an application gateway with URL path-based
You can use Azure PowerShell to configure URL -based routing rules when you create an application gateway. In
this tutorial, you create backend pools using virtual machine scale sets. You then create URL routing rules that
make sure web traffic is redirected to the appropriate backend pool.
Set up the network
The following example shows site traffic coming from both ports 8080 and 8081 and being directed to the same
backend pools:

PowerShell module. If you are running PowerShell locally, you also need to run Connect-AzureRmAccount to create
a connection with Azure.


-Name myAGSubnet `
New-AzureRmVirtualNetwork `
-Location eastus `
-Name myVNet `
New-AzureRmPublicIpAddress `
-Location eastus `

In this section, you create resources that support the application gateway, and then finally create it. The resources
New -AzureRmApplicationGatewayFrontendIPConfig. And then you can create the HTTP port using New -
-Name myVNet
$pip = Get-AzureRmPublicIpAddress `
-Name myAGPublicIPAddress
-Subnet $subnet
-Port 80
Create the default pool and settings

Create the default backend pool named appGatewayBackendPool for the application gateway using New -
-Port 80 `
-Protocol Http `
-RequestTimeout 120

A listener is required to enable the application gateway to route traffic appropriately to a backend pool. In this
tutorial, you create multiple listeners. The first basic listener expects traffic at the root URL. The other listeners
expect traffic at specific URLs, such as http://52.168.55.24:8080/images/ or http://52.168.55.24:8081/video/.
Create a listener named defaultListener using New -AzureRmApplicationGatewayHttpListener with the frontend
configuration and frontend port that you previously created. A rule is required for the listener to know which
backend pool to use for incoming traffic. Create a basic rule named rule1 using New -
-Name defaultListener `
-Protocol Http `
-Name rule1 `
-RuleType Basic `
-Tier Standard `
-Capacity 2
New-AzureRmApplicationGateway `
-Location eastus `
-Sku $sku
Add backend pools and ports

You can add backend pools to your application gateway by using Add-
AzureRmApplicationGatewayBackendAddressPool. In this example, imagesBackendPool and videoBackendPool
are created. You add the frontend port for the pools using Add-AzureRmApplicationGatewayFrontendPort. You
then submit the changes to the application gateway using Set-AzureRmApplicationGateway.
-Name myAppGateway
-Name bport `
-Port 8080
-Name rport `
-Port 8081

Add listeners
Add the listeners named backendListener and redirectedListener that are needed to route traffic using Add-
-Name myAppGateway
$backendPort = Get-AzureRmApplicationGatewayFrontendPort `
-Name bport
$redirectPort = Get-AzureRmApplicationGatewayFrontendPort `
-Name rport
-Name backendListener `
-Protocol Http `
-FrontendPort $backendPort
-Name redirectedListener `
-Protocol Http `
-FrontendPort $redirectPort
Add the default URL path map

URL path maps make sure that specific URLs are routed to specific backend pools. You can create the URL path
maps named imagePathRule and videoPathRule using New -AzureRmApplicationGatewayPathRuleConfig and
Add-AzureRmApplicationGatewayUrlPathMapConfig.
-Name myAppGateway
$imagePool = Get-AzureRmApplicationGatewayBackendAddressPool `
$imagePathRule = New-AzureRmApplicationGatewayPathRuleConfig `
-Name imagePathRule `
-BackendAddressPool $imagePool `
$videoPathRule = New-AzureRmApplicationGatewayPathRuleConfig `
-Name videoPathRule `
-Paths "/video/*" `
-BackendAddressPool $videoPool `
-Name urlpathmap `
-PathRules $imagePathRule, $videoPathRule `
Add redirection configuration

You can configure redirection for the listener using Add-AzureRmApplicationGatewayRedirectConfiguration.
-Name myAppGateway
$backendListener = Get-AzureRmApplicationGatewayHttpListener `
$redirectConfig = Add-AzureRmApplicationGatewayRedirectConfiguration `
-Name redirectConfig `
-RedirectType Found `
-TargetListener $backendListener `
-IncludeQueryString $true
Add the redirection URL path map

-Name myAppGateway
-Name redirectConfig
$redirectPathRule = New-AzureRmApplicationGatewayPathRuleConfig `
-Name redirectPathRule `
-RedirectConfiguration $redirectConfig
-Name redirectpathmap `
-PathRules $redirectPathRule `
Add routing rules

The routing rules associate the URL maps with the listeners that you created. You can add the rules named
defaultRule and redirectedRule using Add-AzureRmApplicationGatewayRequestRoutingRule.
-Name myAppGateway
$backendlistener = Get-AzureRmApplicationGatewayHttpListener `
$redirectlistener = Get-AzureRmApplicationGatewayHttpListener `
-Name redirectedListener
$urlPathMap = Get-AzureRmApplicationGatewayUrlPathMapConfig `
-Name urlpathmap
$redirectPathMap = Get-AzureRmApplicationGatewayUrlPathMapConfig `
-Name redirectpathmap
-Name defaultRule `
-HttpListener $backendlistener `
-UrlPathMap $urlPathMap
-Name redirectedRule `
-HttpListener $redirectlistener `
-UrlPathMap $redirectPathMap

The scale sets that you create are named myvmss1, myvmss2, and myvmss3. Each scale set contains two virtual
machine instances on which you install IIS. You assign the scale set to the backend pool when you configure the IP
settings.
-Name myVNet
-Name myAppGateway
$imagesPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name imagesBackendPool `
-Name videoBackendPool `
for ($i=1; $i -le 3; $i++)

{
if ($i -eq 1)
{
$poolId = $backendPool.Id
}
if ($i -eq 2)
{
$poolId = $imagesPool.Id
}
if ($i -eq 3)
{
$poolId = $videoPool.Id
}
-Location eastus `
-SkuCapacity 2 `
-Primary $true `
New-AzureRmVmss `
-Name myvmss$i `
}
Install IIS
for ($i=1; $i -le 3; $i++)

{
$vmss = Get-AzureRmVmss -ResourceGroupName myResourceGroupAG -VMScaleSetName myvmss$i

-Name myvmss$i `
}

IP address, and then paste it into the address bar of your browser. Such as, http://52.168.55.24,
http://52.168.55.24:8080/images/test.htm, http://52.168.55.24:8080/video/test.htm, or
http://52.168.55.24:8081/images/test.htm.
Now, change the URL to http://<ip-address>:8081/images/test.htm, substituting your IP address for <ip-
address>, and you should see traffic redirected back to the images backend pool at http://<ip-
address>:8080/images.
Clean up resources
Next steps
Set up the network
Learn more about what you can do with application gateway
Create a zone redundant Azure application gateway -
private preview
The application gateway zone redundant platform is a new SKU that offers many enhancements over the existing
application gateway SKU including:
Zone resiliency - An application gateway deployment can now span multiple Availability Zones, removing the
need to provision and pin 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, thus ensuring zone
failure resiliency. The backend pool for applications can be similarly distributed across availability zones.
Performance enhancements
Static VIP - The application gateway VIP now supports the static VIP type exclusively. This ensures that the
VIP associated with application gateway does not change after a restart.
Key vault integration for customer SSL certificates
Faster deployment and update time
NOTE
The zone redundant application gateway is currently in private preview. This preview is provided without a service level
agreement and is not recommended for production workloads. Certain features may not be supported or may have
constrained capabilities. See the Supplemental Terms of Use for Microsoft Azure Previews for details.
Supported regions
Zone redundant application gateways are currently supported in the East US 2 region. More regions will be added
soon.
Topologies
With the current release, you no longer need to create zone pinned application gateways to get zonal redundancy.
The same application gateway deployment can now span multiple zones.
At least three instances are required to ensure that they are spread across all three zones. Application gateway
distributes instances across zones as more instances are added.
Previous zone redundant topologies looked like the following diagram:
The new zone redundant topology looks like this diagram:
Deployment
Prerequisites
Currently zone redundant capability is only available in private preview. You must email
appgwxzone@microsoft.com to be whitelisted. Once you receive a confirmation, you can proceed to the next steps.
Include the following information in your email for whitelisting:
Subscription ID
Region name
Approximate count of application gateways required
Resource Manager template deployment
1. Make sure the subscription you use is whitelisted as previously mentioned.
2. After you receive a confirmation, sign in to the Azure account and select the appropriate subscription if more
than one subscription is present. Make sure you select the subscription that was whitelisted.
Login-AzureRmAccount
Select-AzureRmSubscription -Subscription "<whitelisted subscription name>”
3. Create a new resource group
New-AzureRmResourceGroup -Name <resource group name> -Location "East US 2"
4. Download the templates from GitHub and note the folder where you save them.
5. Create a new deployment in the resource group you created. Modify the template and parameters file
appropriately before you deploy.
The following diagram shows where you can retrieve the tenant ID on the Azure portal:
The template creates the following resources:

User Assigned Identity - this is used for enabling application gateway instances to access key vault and
retrieve the certificates stored by user.
KeyVault – the Key Vault where the user’s certificate is stored. This can be a pre-existing Key Vault as well.
Secret – the private key that is stored in the Key Vault.
Access Policy – An access policy applied on the Key Vault that grants permission using User Assigned Identity
so that application gateway deployments can retrieve user certificates.
Public IP address – a reserved IP address that is used to access the application gateway. This IP address never
changes for the lifecycle of the application gateway.
Network Security Groups – An NSG auto-created on the application gateway subnet that opens port traffic
on the configured listener. This is explicitly created and managed in the new SKU compared to the previous SKU
where this NSG was implicit.
Virtual Network – The vnet where the application gateway and applications are deployed.
Application Gateway – Creates an application gateway with instances in the required zones. By default, all
zones (1,2,3) are selected. The SKU name is changed to Standard_v2. This SKU name is subject to change.
Currently, the autoscale configuration has the min and max set to the required number of instances. Once
autoscaling is enabled, this can be adjusted.
New-AzureRmResourceGroupDeployment -Name Deployment1 -ResourceGroupName AmitVMSSLinuxTest9 -TemplateFile

<complete path to template.json> -TemplateParameterFile <complete path to parameters.json>
PowerShell deployment
1. Ensure that the subscription used is whitelisted as previously mentioned in the prerequisites.
2. Download and install the private PowerShell MSI from GitHub.
3. Download the private PowerShell zip file from the location mentioned in preview registration confirmation
email. Unzip the file to your drive and note the location.
4. Once the preview is enabled, load the preview modules first before signing on to your account:
$azurePSPath = "<complete path to Azure-PowerShell folder>"

import-module "$azurePSPath\AzureRM.Profile\AzureRM.Profile.psd1"
import-module "$azurePSPath\Azure.Storage\Azure.Storage.psd1"
import-module "$azurePSPath\AzureRM.Resources\AzureRM.Resources.psd1"
import-module "$azurePSPath\AzureRM.Network\AzureRM.Network.psd1"
import-module "$azurePSPath\AzureRM.KeyVault\AzureRM.KeyVault.psd1"
5. Sign in to the Azure account and select the desired subscription if more than one subscription is present.
Ensure you select the appropriate subscription that was whitelisted.
6. Run the following commands to establish common constants that include names for most of the entities
being created.
Modify the entries as required for your naming preference.
$location = "eastus2"
$version = "300"
$rgname = "RG_A_$version"
$appgwName = "AGW_A_$version"
$vaultName = "KVA$version"
$userAssignedIdentityName = "UI_A_$version"
$certificateName = "KVCA$version"
$nsgName = "NSG_A_$version"
$vnetName = "VN_A_$version"
$gwSubnetName = "SN_A_$version"
$gipconfigname = "GC_A_$version"
$publicIpName = "PIP_A_$version"
$fipconfig01Name = "FC_A_$version"
$poolName = "BP_A_$version"
$frontendPort01Name = "FP1_A_$version"
$frontendPort02Name = "FP2_A_$version"
$poolSetting01Name = "BS_A_$version"
$listener01Name = "HL1_A_$version"
$listener02Name = "HL2_A_$version"
$rule01Name = "RR1_A_$version"
$rule02Name = "RR2_A_$version"
$AddressPrefix = "111.111.222.0"
7. Create the resource group:
$resourceGroup = New-AzureRmResourceGroup -Name $rgname -Location $location -Force

8. Create the User Assigned Identity used to give access to the application gateway to retrieve certificates from
the Key Vault.
$userAssignedIdentity = New-AzureRmResource -ResourceGroupName $rgname -Location $location -ResourceName

$userAssignedIdentityName -ResourceType Microsoft.ManagedIdentity/userAssignedIdentities -Force
9. Create the Key Vault used to store your certificates:
$keyVault = New-AzureRmKeyVault -VaultName $vaultName -ResourceGroupName $rgname -Location $location -

EnableSoftDelete
10. Upload certificate to Key Vault as a secret:
$securepfxpwd = ConvertTo-SecureString -String "<password>" -AsPlainText -Force
$cert = Import-AzureKeyVaultCertificate -VaultName $vaultName -Name $certificateName -FilePath

‘<path to pfx file>' -Password $securepfxpwd
11. Assign access policy to the Key Vault using the User Assigned Identity. This allows the application gateway
instances to access the Key Vault secret:
Set-AzureRmKeyVaultAccessPolicy -VaultName $vaultName -ResourceGroupName $rgname -PermissionsToSecrets

get -ObjectId $userAssignedIdentity.Properties.principalId
12. Create the Network Security Group (NSG ) to allow access to the application gateway subnet on ports where
new listeners are created.
For example, for HTTP/HTTPS on default ports the NSG would allow inbound access to 80, 443 and 65200-
65535 for management operations.
$srule01 = New-AzureRmNetworkSecurityRuleConfig -Name "listeners" -Direction Inbound -

SourceAddressPrefix * -SourcePortRange * -Protocol * -DestinationAddressPrefix * -DestinationPortRange
22,80,443 -Access Allow -Priority 100
$srule02 = New-AzureRmNetworkSecurityRuleConfig -Name "managementPorts" -Direction Inbound -

SourceAddressPrefix * -SourcePortRange * -Protocol * -DestinationAddressPrefix * -DestinationPortRange
"65200-65535" -Access Allow -Priority 101
$nsg = New-AzureRmNetworkSecurityGroup -Name $nsgName -ResourceGroupName $rgname -Location $location -

SecurityRules $srule01,$srule02 -Force
13. Create VNet and subnets:
$gwSubnet = New-AzureRmVirtualNetworkSubnetConfig -Name

$gwSubnetName -AddressPrefix "$AddressPrefix/24" -NetworkSecurityGroup $nsg
$vnet = New-AzureRmvirtualNetwork -Name $vnetName -ResourceGroupName $rgname -Location $location -

AddressPrefix "$AddressPrefix/24" -Subnet $gwSubnet -Force
14. Create a public IP address of type reserved/static:
$publicip = New-AzureRmPublicIpAddress -ResourceGroupName $rgname -name $publicIpName -location

$location -AllocationMethod Static -Sku Standard -Force
15. Create the application gateway:
$gipconfig = New-AzureRmApplicationGatewayIPConfiguration -Name $gipconfigname -Subnet $gwSubnet
$fipconfig01 = New-AzureRmApplicationGatewayFrontendIPConfig -Name $fipconfig01Name -PublicIPAddress

$publicip
$pool = New-AzureRmApplicationGatewayBackendAddressPool -Name $poolName -BackendIPAddresses

testbackend1.westus.cloudapp.azure.com, testbackend2.westus.cloudapp.azure.com
$fp01 = New-AzureRmApplicationGatewayFrontendPort -Name $frontendPort01Name -Port 443
$fp02 = New-AzureRmApplicationGatewayFrontendPort -Name $frontendPort02Name -Port 80
$sslCert01 = New-AzureRmApplicationGatewaySslCertificate -Name "SSLCert" -KeyVaultSecretId $secret.Id
$listener01 = New-AzureRmApplicationGatewayHttpListener -Name $listener01Name -Protocol Https -

FrontendIPConfiguration
$fipconfig01 -FrontendPort $fp01 -SslCertificate $sslCert01
$listener02 = New-AzureRmApplicationGatewayHttpListener -Name $listener02Name -Protocol Http -

FrontendIPConfiguration $fipconfig01 -FrontendPort $fp02
$poolSetting01 = New-AzureRmApplicationGatewayBackendHttpSettings -Name $poolSetting01Name -Port 80 -

Protocol Http -CookieBasedAffinity Disabled
$rule01 = New-AzureRmApplicationGatewayRequestRoutingRule -Name $rule01Name -RuleType basic -

BackendHttpSettings $poolSetting01 -HttpListener $listener01 -BackendAddressPool $pool
$rule02 = New-AzureRmApplicationGatewayRequestRoutingRule -Name $rule02Name -RuleType basic -

BackendHttpSettings $poolSetting01 -HttpListener $listener02 -BackendAddressPool $pool
$sku = New-AzureRmApplicationGatewaySku -Name Standard_v2 -Tier Standard_v2 -Capacity 2
$listeners = @($listener02)
$fps = @($fp01, $fp02)
$fipconfigs = @($fipconfig01)
$sslCerts = @($sslCert01)
$rules = @($rule01, $rule02)
$listeners = @($listener01, $listener02)
$appgw = New-AzureRmApplicationGateway -Name $appgwName -ResourceGroupName $rgname -Location $location -

UserAssignedIdentityId $userAssignedIdentity.ResourceId -Probes $probeHttps -BackendAddressPools $pool -
BackendHttpSettingsCollection $poolSetting01 -GatewayIpConfigurations $gipconfig -
FrontendIpConfigurations $fipconfigs -FrontendPorts $fps -HttpListeners $listeners -RequestRoutingRules
$rules -Sku $sku -SslPolicy $sslPolicy -sslCertificates $sslCerts -Force
16. Retrieve the created application gateway’s public IP address:
$pip = Get-AzureRmPublicIpAddress -Name $publicIpName -ResourceGroupName $rgname $pip.IpAddress
Frequently asked questions

Will I be billed for application gateway in preview?
During preview, there is no charge. You will be billed for resources other than application gateway, such as
Key Vault, virtual machines etc.
What regions is the preview available in?
The preview is currently available in the East US 2 region. More regions will be added soon.
Is the portal supported in the preview?
No, support is limited to a private PowerShell module and Resource Manager template during the private
preview.
Is production workload supported during private preview?
No, there is no SL A or support during the private preview. It is not recommended to put production
workloads during previews. Support is limited to direct interaction with product group using the email alias
for preview.
How do I report issues?
The private preview may contain bugs and may have frequent code deployments. Use the support alias
appgwxzone@microsoft.com for reporting issues and assistance.
Known issues and limitations

ISSUE DETAILS
Billing No billing currently
Diagnostics logs (not metrics) Performance and request/response logs don’t appear currently
Portal/CLI/SDK No support for portal, CLI, or SDK. The portal must not be
used to issue updates to preview gateways.
Update via template fails occasionally This is due to race condition with KeyVault access policy
Autoscaling No support for autoscaling currently
WAF Currently WAF is not supported
User supplied certificates and Dynamic VIPs These are not supported in the new model. Use Key Vault for
storing certificates and static VIPs.
Same subnet for old and preview version of application A subnet with an existing application gateway (old model)
gateway cannot be used for the private preview version.
HTTP/2, FIPS mode, WebSocket, Azure Web Apps as backend Currently unsupported
Support and feedback

For support and feedback, contact to appgwxzone@microsoft.com. The application gateway product group is
happy to hear your feedback for enhancements and provide guidance where required.
Next steps
Learn about other application gateway features:
What is Azure Application Gateway?
Create a custom probe for Application Gateway by
using the portal
In this article, you add a custom probe to an existing application gateway through the Azure portal. Custom
probes are useful for applications that have a specific health check page or for applications that do not provide a
successful response on the default web application.
Before you begin

If you do not already have an application gateway, visit Create an Application Gateway to create an application
gateway to work with.
Create the probe

Probes are configured in a two-step process through the portal. The first step is to create the probe. In the second
step, you add the probe to the backend http settings of the application gateway.
1. Log in to the Azure portal. If you don't already have an account, you can sign up for a free one-month trial
2. In the Azure portal Favorites pane, click All resources. Click the application gateway in the All resources
blade. If the subscription you selected already has several resources in it, you can enter partners.contoso.net
in the Filter by name… box to easily access the application gateway.
3. Click Probes and click the Add button to add a probe.
4. On the Add health probe blade, fill out the required information for the probe, and when complete click
OK.
SETTING VALUE DETAILS

SETTING VALUE DETAILS
Name customProbe This value is a friendly name to the

probe that is accessible in the portal.
Protocol HTTP or HTTPS The protocol that the health probe

uses.
Host i.e contoso.com This value is the host name that is

used for the probe. Applicable only
when multi-site is configured on
Application Gateway, otherwise use
'127.0.0.1'. This value is different
from the VM host name.
Path / or another path The remainder of the full url for the
custom probe. A valid path starts
with '/'. For the default path of
http://contoso.com just use '/'
Interval (secs) 30 How often the probe is run to check

for health. It is not recommended to
set the lower than 30 seconds.
Timeout (secs) 30 The amount of time the probe waits

before timing out. The timeout
interval needs to be high enough
that an http call can be made to
ensure the backend health page is
available.
Unhealthy threshold 3 Number of failed attempts to be

considered unhealthy. A threshold of
0 means that if a health check fails
the back-end is determined
unhealthy immediately.
IMPORTANT
The host name is not the same as server name. This value is the name of the virtual host running on the application
server. The probe is sent to http://(host name):(port from httpsetting)/urlPath
Add probe to the gateway

Now that the probe has been created, it is time to add it to the gateway. Probe settings are set on the backend http
settings of the application gateway.
1. Click HTTP settings on the application gateway, to bring up the configuration blade click the current
backend http settings listed in the window.
2. On the appGatewayBackEndHttpSettings settings blade, check the Use custom probe checkbox and
choose the probe created in the Create the probe section on the Custom probe drop-down.. When
complete, click Save and the settings are applied.
The default probe checks the default access to the web application. Now that a custom probe has been created, the
application gateway uses the custom path defined to monitor health for the backend servers. Based on the criteria
that was defined, the application gateway checks the path specified in the probe. If the call to host:Port/path does
not return an HTTP 200-399 status response, the server is taken out of rotation after the unhealthy threshold is
reached. Probing continues on the unhealthy instance to determine when it becomes healthy again. Once the
instance is added back to healthy server pool, traffic begins flowing to it again and probing to the instance
continues at user specified interval as normal.
Next steps
To learn how to configure SSL Offloading with Azure Application Gateway, see Configure SSL Offload
Create a custom probe for Azure Application
Gateway (classic) by using PowerShell
In this article, you add a custom probe to an existing application gateway with PowerShell. Custom probes are
useful for applications that have a specific health check page or for applications that do not provide a successful
response on the default web application.
IMPORTANT
Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. This
article covers using the Classic deployment model. Microsoft recommends that most new deployments use the Resource
Manager model. Learn how to perform these steps using the Resource Manager model.
Prerequisite: Install the Azure PowerShell module

To perform the steps in this article, you need to install and configure the Azure PowerShell module. Be sure to
complete all of the instructions. After the installation is finished, sign in to Azure and select your subscription.
NOTE
You need an Azure account to complete these steps. If you don't have an Azure account, you can sign up for a free trial.

To create an application gateway:
1. Create an application gateway resource.
2. Create a configuration XML file or a configuration object.
3. Commit the configuration to the newly created application gateway resource.
Create an application gateway resource with a custom probe
To create the gateway, use the New-AzureApplicationGateway cmdlet, replacing the values with your own. Billing for
the gateway does not start at this point. Billing begins in a later step, when the gateway is successfully started.
The following example creates an application gateway by using a virtual network called "testvnet1" and a subnet
called "subnet-1".
New-AzureApplicationGateway -Name AppGwTest -VnetName testvnet1 -Subnets @("Subnet-1")
To validate that the gateway was created, you can use the Get-AzureApplicationGateway cmdlet.
Get-AzureApplicationGateway AppGwTest
NOTE
The default value for InstanceCount is 2, with a maximum value of 10. The default value for GatewaySize is Medium. You can
choose between Small, Medium, and Large.
VirtualIPs and DnsName are shown as blank because the gateway has not started yet. These values are created
once the gateway is in the running state.
Configure an application gateway by using XML
In the following example, you use an XML file to configure all application gateway settings and commit them to
the application gateway resource.
Copy the following text to Notepad.
<ApplicationGatewayConfiguration xmlns:i="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/windowsazure">
<FrontendIPConfigurations>
<FrontendIPConfiguration>
<Name>fip1</Name>
<Type>Private</Type>
</FrontendIPConfiguration>
</FrontendIPConfigurations>
<FrontendPorts>
<FrontendPort>
<Name>port1</Name>
<Port>80</Port>
</FrontendPort>
</FrontendPorts>
<Probes>
<Probe>
<Name>Probe01</Name>
<Protocol>Http</Protocol>
<Host>contoso.com</Host>
<Path>/path/custompath.htm</Path>
<Interval>15</Interval>
<Timeout>15</Timeout>
<UnhealthyThreshold>5</UnhealthyThreshold>
</Probe>
</Probes>
<BackendAddressPools>
<BackendAddressPool>
<Name>pool1</Name>
<IPAddresses>
<IPAddress>1.1.1.1</IPAddress>
<IPAddress>2.2.2.2</IPAddress>
</IPAddresses>
</BackendAddressPool>
</BackendAddressPools>
<BackendHttpSettingsList>
<BackendHttpSettings>
<Name>setting1</Name>
<Port>80</Port>
<CookieBasedAffinity>Enabled</CookieBasedAffinity>
<RequestTimeout>120</RequestTimeout>
<Probe>Probe01</Probe>
</BackendHttpSettings>
</BackendHttpSettingsList>
<HttpListeners>
<HttpListener>
<Name>listener1</Name>
<FrontendIP>fip1</FrontendIP>
<FrontendPort>port1</FrontendPort>
</HttpListener>
</HttpListeners>
<HttpLoadBalancingRules>
<HttpLoadBalancingRule>
<Name>lbrule1</Name>
<Type>basic</Type>
<BackendHttpSettings>setting1</BackendHttpSettings>
<Listener>listener1</Listener>
<BackendAddressPool>pool1</BackendAddressPool>
</HttpLoadBalancingRule>
</HttpLoadBalancingRules>
</ApplicationGatewayConfiguration>
Edit the values between the parentheses for the configuration items. Save the file with extension .xml.
The following example shows how to use a configuration file to set up the application gateway to load balance
HTTP traffic on public port 80 and send network traffic to back-end port 80 between two IP addresses by using a
custom probe.
IMPORTANT
The protocol item Http or Https is case-sensitive.
A new configuration item <Probe> is added to configure custom probes.

The configuration parameters are:
PARAMETER DESCRIPTION
Name Reference name for custom probe.
* Protocol Protocol used (possible values are HTTP or HTTPS).
Host and Path Complete URL path that is invoked by the application
gateway to determine the health of the instance. For example,
if you have a website http://contoso.com/, then the custom
probe can be configured for
"http://contoso.com/path/custompath.htm" for probe checks
to have a successful HTTP response.
Interval Configures the probe interval checks in seconds.
Timeout Defines the probe time-out for an HTTP response check.
UnhealthyThreshold The number of failed HTTP responses needed to flag the back-
end instance as unhealthy.
The probe name is referenced in the <BackendHttpSettings> configuration to assign which back-end pool uses
custom probe settings.
Add a custom probe to an existing application gateway

Changing the current configuration of an application gateway requires three steps: Get the current XML
configuration file, modify to have a custom probe, and configure the application gateway with the new XML
settings.
1. Get the XML file by using Get-AzureApplicationGatewayConfig . This cmdlet exports the configuration XML
to be modified to add a probe setting.
Get-AzureApplicationGatewayConfig -Name "<application gateway name>" -Exporttofile "<path to file>"
2. Open the XML file in a text editor. Add a <probe> section after <frontendport> .
<Probes>
<Probe>
<Name>Probe01</Name>
<Host>contoso.com</Host>
<Path>/path/custompath.htm</Path>
<Interval>15</Interval>
<Timeout>15</Timeout>
<UnhealthyThreshold>5</UnhealthyThreshold>
</Probe>
</Probes>
In the backendHttpSettings section of the XML, add the probe name as shown in the following example:
<BackendHttpSettings>
<Name>setting1</Name>
<Port>80</Port>
<CookieBasedAffinity>Enabled</CookieBasedAffinity>
<RequestTimeout>120</RequestTimeout>
<Probe>Probe01</Probe>
</BackendHttpSettings>
Save the XML file.

3. Update the application gateway configuration with the new XML file by using
Set-AzureApplicationGatewayConfig . This cmdlet updates your application gateway with the new
configuration.
Set-AzureApplicationGatewayConfig -Name "<application gateway name>" -Configfile "<path to file>"
Next steps
If you want to configure Secure Sockets Layer (SSL ) offload, see Configure an application gateway for SSL
offload.
If you want to configure an application gateway to use with an internal load balancer, see Create an application
gateway with an internal load balancer (ILB ).
Create a custom probe for Azure Application
Gateway by using PowerShell for Azure Resource
Manager
In this article, you add a custom probe to an existing application gateway with PowerShell. Custom probes are
useful for applications that have a specific health check page or for applications that do not provide a successful
response on the default web application.
NOTE
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
article covers using the Resource Manager deployment model, which Microsoft recommends for most new deployments
instead of the classic deployment model.
Prerequisite: Install the Azure PowerShell module

To perform the steps in this article, you need to install and configure the Azure PowerShell module. Be sure to
complete all of the instructions. After the installation is finished, sign in to Azure and select your subscription.
NOTE
You need an Azure account to complete these steps. If you don't have an Azure account, you can sign up for a free trial.
Create an application gateway with a custom probe

Sign in and create resource group
1. Use Connect-AzureRmAccount to authenticate.
Connect-AzureRmAccount
2. Get the subscriptions for the account.
3. Choose which of your Azure subscriptions to use.
Select-AzureRmSubscription -Subscriptionid '{subscriptionGuid}'
4. Create a resource group. You can skip this step if you have an existing resource group.
New-AzureRmResourceGroup -Name appgw-rg -Location 'West US'
Azure Resource Manager requires that all resource groups specify a location. This location is used as the default
location for resources in that resource group. Make sure that all commands to create an application gateway use
the same resource group.
In the preceding example, we created a resource group called appgw-RG in location West US.
Create a virtual network and a subnet
The following example creates a virtual network and a subnet for the application gateway. Application gateway
requires its own subnet for use. For this reason, the subnet created for the application gateway should be smaller
than the address space of the VNET to allow for other subnets to be created and used.
# Assign the address range 10.0.0.0/24 to a subnet variable to be used to create a virtual network.
# Create a virtual network named appgwvnet in resource group appgw-rg for the West US region using the prefix
10.0.0.0/16 with subnet 10.0.0.0/24.
$vnet = New-AzureRmVirtualNetwork -Name appgwvnet -ResourceGroupName appgw-rg -Location 'West US' -
AddressPrefix 10.0.0.0/16 -Subnet $subnet
# Assign a subnet variable for the next steps, which create an application gateway.
$subnet = $vnet.Subnets[0]
Create a public IP address for the front-end configuration

Create a public IP resource publicIP01 in resource group appgw-rg for the West US region. This example uses
a public IP address for the front-end IP address of the application gateway. Application gateway requires the
public IP address to have a dynamically created DNS name therefore the -DomainNameLabel cannot be specified
during the creation of the public IP address.
$publicip = New-AzureRmPublicIpAddress -ResourceGroupName appgw-rg -Name publicIP01 -Location 'West US' -

AllocationMethod Dynamic

You set up all configuration items before creating the application gateway. The following example creates the
configuration items that are needed for an application gateway resource.
COMPONENT DESCRIPTION
Gateway IP configuration An IP configuration for an application gateway.
Backend pool A pool of IP addresses, FQDN's, or NICs that are to the

application servers that host the web application
Health probe A custom probe used to monitor the health of the backend
pool members
HTTP settings A collection of settings including, port, protocol, cookie-based

affinity, probe, and timeout. These settings determine how
traffic is routed to the backend pool members
Frontend port The port that the application gateway listens for traffic on
Listener A combination of a protocol, frontend IP configuration, and

frontend port. This is what listens for incoming requests.
Rule Routes the traffic to the appropriate backend based on HTTP

settings.
# Creates a application gateway Frontend IP configuration named gatewayIP01
#Creates a back-end IP address pool named pool01 with IP addresses 134.170.185.46, 134.170.188.221,
134.170.185.50.
$pool = New-AzureRmApplicationGatewayBackendAddressPool -Name pool01 -BackendIPAddresses 134.170.185.46,
134.170.188.221, 134.170.185.50
# Creates a probe that will check health at http://contoso.com/path/path.htm

$probe = New-AzureRmApplicationGatewayProbeConfig -Name probe01 -Protocol Http -HostName 'contoso.com' -Path
'/path/path.htm' -Interval 30 -Timeout 120 -UnhealthyThreshold 8
# Creates the backend http settings to be used. This component references the $probe created in the previous
command.
CookieBasedAffinity Disabled -Probe $probe -RequestTimeout 80
# Creates a frontend port for the application gateway to listen on port 80 that will be used by the listener.
# Creates a frontend IP configuration. This associates the $publicip variable defined previously with the
front-end IP that will be used by the listener.
# Creates the listener. The listener is a combination of protocol and the frontend IP configuration
$fipconfig and frontend port $fp created in previous steps.
$listener = New-AzureRmApplicationGatewayHttpListener -Name listener01 -Protocol Http -
FrontendIPConfiguration $fipconfig -FrontendPort $fp
# Creates the rule that routes traffic to the backend pools. In this example we create a basic rule that
uses the previous defined http settings and backend address pool. It also associates the listener to the
rule
# Sets the SKU of the application gateway, in this example we create a small standard application gateway
with 2 instances.
# The final step creates the application gateway with all the previously defined components.
$appgw = New-AzureRmApplicationGateway -Name appgwtest -ResourceGroupName appgw-rg -Location 'West US' -
BackendAddressPools $pool -Probes $probe -BackendHttpSettingsCollection $poolSetting -
FrontendIpConfigurations $fipconfig -GatewayIpConfigurations $gipconfig -FrontendPorts $fp -HttpListeners
$listener -RequestRoutingRules $rule -Sku $sku
Add a probe to an existing application gateway

The following code snippet adds a probe to an existing application gateway.
# Load the application gateway resource into a PowerShell variable by using Get-AzureRmApplicationGateway.
# Create the probe object that will check health at http://contoso.com/path/path.htm

$getgw = Add-AzureRmApplicationGatewayProbeConfig -ApplicationGateway $getgw -Name probe01 -Protocol Http -
HostName 'contoso.com' -Path '/path/custompath.htm' -Interval 30 -Timeout 120 -UnhealthyThreshold 8
# Set the backend HTTP settings to use the new probe

$getgw = Set-AzureRmApplicationGatewayBackendHttpSettings -ApplicationGateway $getgw -Name
$getgw.BackendHttpSettingsCollection.name -Port 80 -Protocol Http -CookieBasedAffinity Disabled -Probe $probe
-RequestTimeout 120
# Save the application gateway with the configuration changes

Set-AzureRmApplicationGateway -ApplicationGateway $getgw
Remove a probe from an existing application gateway
The following code snippet removes a probe from an existing application gateway.
# Load the application gateway resource into a PowerShell variable by using Get-AzureRmApplicationGateway.
# Remove the probe from the application gateway configuration object

$getgw = Remove-AzureRmApplicationGatewayProbeConfig -ApplicationGateway $getgw -Name $getgw.Probes.name
# Set the backend HTTP settings to remove the reference to the probe. The backend http settings now use the
default probe
$getgw = Set-AzureRmApplicationGatewayBackendHttpSettings -ApplicationGateway $getgw -Name
$getgw.BackendHttpSettingsCollection.name -Port 80 -Protocol http -CookieBasedAffinity Disabled
# Save the application gateway with the configuration changes

Set-AzureRmApplicationGateway -ApplicationGateway $getgw
Get application gateway DNS name

Once the gateway is created, the next step is to configure the front end for communication. When using a public
IP, application gateway requires a dynamically assigned DNS name, which is not friendly. To ensure end users can
hit the application gateway a CNAME record can be used to point to the public endpoint of the application
gateway. Configuring a custom domain name for in Azure. To do this, retrieve details of the application gateway
and its associated IP/DNS name using the PublicIPAddress element attached to the application gateway. The
application gateway's DNS name should be used to create a CNAME record, which points the two web
applications to this DNS name. The use of A-records is not recommended since the VIP may change on restart of
Get-AzureRmPublicIpAddress -ResourceGroupName appgw-RG -Name publicIP01
Name : publicIP01
ResourceGroupName : appgw-RG
Location : westus
Id : /subscriptions/<subscription_id>/resourceGroups/appgw-
RG/providers/Microsoft.Network/publicIPAddresses/publicIP01
Etag : W/"00000d5b-54ed-4907-bae8-99bd5766d0e5"
ResourceGuid : 00000000-0000-0000-0000-000000000000
ProvisioningState : Succeeded
Tags :
PublicIpAllocationMethod : Dynamic
IpAddress : xx.xx.xxx.xx
PublicIpAddressVersion : IPv4
IdleTimeoutInMinutes : 4
IpConfiguration : {
"Id": "/subscriptions/<subscription_id>/resourceGroups/appgw-
RG/providers/Microsoft.Network/applicationGateways/appgwtest/frontendIP
Configurations/frontend1"
}
DnsSettings : {
"Fqdn": "00000000-0000-xxxx-xxxx-xxxxxxxxxxxx.cloudapp.net"
}
Next steps
Learn to configure SSL offloading by visiting: Configure SSL Offload
Troubleshooting bad gateway errors in Application
Gateway
Learn how to troubleshoot bad gateway (502) errors received when using application gateway.
Overview
After configuring an application gateway, one of the errors that users may encounter is "Server Error: 502 - Web
server received an invalid response while acting as a gateway or proxy server". This error may happen due to the
following main reasons:
NSG, UDR or Custom DNS is blocking access to backend pool members.
Back-end VMs or instances of virtual machine scale set are not responding to the default health probe.
Invalid or improper configuration of custom health probes.
Azure Application Gateway's back-end pool is not configured or empty.
None of the VMs or instances in virtual machine scale set are healthy.
Request time-out or connectivity issues with user requests.
Network Security Group, User Defined Route, or Custom DNS issue

Cause
If access to backend is blocked due to presence of NSG, UDR or custom DNS, Application Gateway instances will
not be able to reach the backend pool and would result in probe failures causing 502 errors. Note that the
NSG/UDR could be present either in Application Gateway subnet or the subnet where the application VMs are
deployed. Similarly presence of custom DNS in the VNET could also cause issues if FQDN is used for backend
pool members and is not resolved correctly by the user configured DNS server for the VNET.
Solution
Validate NSG, UDR, and DNS configuration by going through the following steps:
Check NSGs associated with Application Gateway subnet. Ensure that communication to backend is not
blocked.
Check UDR associated with Application Gateway subnet. Ensure that UDR is not directing traffic away from
backend subnet - for example check for routing to network virtual appliances or default routes being advertised
to Application Gateway subnet via ExpressRoute/VPN.
$vnet = Get-AzureRmVirtualNetwork -Name vnetName -ResourceGroupName rgName

Get-AzureRmVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
Check effective NSG and route with the backend VM
Get-AzureRmEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg

Get-AzureRmEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
Check presence of custom DNS in the VNet. DNS can be checked by looking at details of the VNet properties
in the output.
Get-AzureRmVirtualNetwork -Name vnetName -ResourceGroupName rgName
DhcpOptions : {
"DnsServers": [
"x.x.x.x"
]
}
If present, ensure that the DNS server is able to resolve backend pool member's FQDN correctly.
Problems with default health probe

Cause
502 errors can also be frequent indicators that the default health probe is not able to reach back-end VMs. When
an Application Gateway instance is provisioned, it automatically configures a default health probe to each
BackendAddressPool using properties of the BackendHttpSetting. No user input is required to set this probe.
Specifically, when a load balancing rule is configured, an association is made between a BackendHttpSetting and
BackendAddressPool. A default probe is configured for each of these associations and Application Gateway
initiates a periodic health check connection to each instance in the BackendAddressPool at the port specified in the
BackendHttpSetting element. Following table lists the values associated with the default health probe.
PROBE PROPERTY VALUE DESCRIPTION
Probe URL http://127.0.0.1/ URL path
Interval 30 Probe interval in seconds
Time-out 30 Probe time-out in seconds
Unhealthy threshold 3 Probe retry count. The back-end server

is marked down after the consecutive
probe failure count reaches the
unhealthy threshold.
Solution
Ensure that a default site is configured and is listening at 127.0.0.1.
If BackendHttpSetting specifies a port other than 80, the default site should be configured to listen at that port.
The call to http://127.0.0.1:port should return an HTTP result code of 200. This should be returned within the 30
sec time-out period.
Ensure that port configured is open and that there are no firewall rules or Azure Network Security Groups,
which block incoming or outgoing traffic on the port configured.
If Azure classic VMs or Cloud Service is used with FQDN or Public IP, ensure that the corresponding endpoint
is opened.
If the VM is configured via Azure Resource Manager and is outside the VNet where Application Gateway is
deployed, Network Security Group must be configured to allow access on the desired port.
Problems with custom health probe

Cause
Custom health probes allow additional flexibility to the default probing behavior. When using custom probes, users
can configure the probe interval, the URL, and path to test, and how many failed responses to accept before
marking the back-end pool instance as unhealthy. The following additional properties are added.
PROBE PROPERTY DESCRIPTION
Name Name of the probe. This name is used to refer to the probe in
back-end HTTP settings.
Protocol Protocol used to send the probe. The probe uses the protocol
defined in the back-end HTTP settings
Host Host name to send the probe. Applicable only when multi-site
is configured on Application Gateway. This is different from
VM host name.
Path Relative path of the probe. The valid path starts from '/'. The
probe is sent to <protocol>://<host>:<port><path>
Interval Probe interval in seconds. This is the time interval between

two consecutive probes.
Time-out Probe time-out in seconds. If a valid response is not received

within this time-out period, the probe is marked as failed.
Unhealthy threshold Probe retry count. The back-end server is marked down after
the consecutive probe failure count reaches the unhealthy
threshold.
Solution
Validate that the Custom Health Probe is configured correctly as the preceding table. In addition to the preceding
troubleshooting steps, also ensure the following:
Ensure that the probe is correctly specified as per the guide.
If Application Gateway is configured for a single site, by default the Host name should be specified as
'127.0.0.1', unless otherwise configured in custom probe.
Ensure that a call to http://<host>:<port><path> returns an HTTP result code of 200.
Ensure that Interval, Time-out and UnhealtyThreshold are within the acceptable ranges.
If using an HTTPS probe, make sure that the backend server doesn't require SNI by configuring a fallback
certificate on the backend server itself.
Request time-out
Cause
When a user request is received, Application Gateway applies the configured rules to the request and routes it to a
back-end pool instance. It waits for a configurable interval of time for a response from the back-end instance. By
default, this interval is 30 seconds. If Application Gateway does not receive a response from back-end application
in this interval, user request would see a 502 error.
Solution
Application Gateway allows users to configure this setting via BackendHttpSetting, which can be then applied to
different pools. Different back-end pools can have different BackendHttpSetting and hence different request time-
out configured.
New-AzureRmApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -

CookieBasedAffinity Enabled -RequestTimeout 60
Empty BackendAddressPool
Cause
If the Application Gateway has no VMs or virtual machine scale set configured in the back-end address pool, it
cannot route any customer request and throws a bad gateway error.
Solution
Ensure that the back-end address pool is not empty. This can be done either via PowerShell, CLI, or portal.
Get-AzureRmApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"
The output from the preceding cmdlet should contain non-empty back-end address pool. Following is an example
where two pools are returned which are configured with FQDN or IP addresses for backend VMs. The
provisioning state of the BackendAddressPool must be 'Succeeded'.
BackendAddressPoolsText:
[{
"BackendAddresses": [{
"ipAddress": "10.0.0.10",
"ipAddress": "10.0.0.11"
}],
"BackendIpConfigurations": [],
"ProvisioningState": "Succeeded",
"Name": "Pool01",
"Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
"Id": "/subscriptions/<subscription id>/resourceGroups/<resource group
name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
"BackendAddresses": [{
"Fqdn": "xyx.cloudapp.net",
"Fqdn": "abc.cloudapp.net"
}],
"BackendIpConfigurations": [],
"ProvisioningState": "Succeeded",
"Name": "Pool02",
"Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
"Id": "/subscriptions/<subscription id>/resourceGroups/<resource group
name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]
Unhealthy instances in BackendAddressPool

Cause
If all the instances of BackendAddressPool are unhealthy, then Application Gateway would not have any back-end
to route user request to. This could also be the case when back-end instances are healthy but do not have the
required application deployed.
Solution
Ensure that the instances are healthy and the application is properly configured. Check if the back-end instances are
able to respond to a ping from another VM in the same VNet. If configured with a public end point, ensure that a
browser request to the web application is serviceable.
Next steps
If the preceding steps do not resolve the issue, open a support ticket.
Back-end health, diagnostic logs, and metrics for
Application Gateway
By using Azure Application Gateway, you can monitor resources in the following ways:
Back-end health: Application Gateway provides the capability to monitor the health of the servers in the
back-end pools through the Azure portal and through PowerShell. You can also find the health of the back-
end pools through the performance diagnostic logs.
Logs: Logs allow for performance, access, and other data to be saved or consumed from a resource for
monitoring purposes.
Metrics: Application Gateway currently has seven metrics to view performance counters.
Back-end health
Application Gateway provides the capability to monitor the health of individual members of the back-end pools
through the portal, PowerShell, and the command-line interface (CLI). You can also find an aggregated health
summary of back-end pools through the performance diagnostic logs.
The back-end health report reflects the output of the Application Gateway health probe to the back-end instances.
When probing is successful and the back end can receive traffic, it's considered healthy. Otherwise, it's considered
unhealthy.
IMPORTANT
If there is a network security group (NSG) on an Application Gateway subnet, open port ranges 65503-65534 on the
Application Gateway subnet for inbound traffic. This port range is required for Azure infrastructure communication. They are
protected (locked down) by Azure certificates. Without proper certificates, external entities, including the customers of those
gateways, will not be able to initiate any changes on those endpoints.
View back-end health through the portal

In the portal, back-end health is provided automatically. In an existing application gateway, select Monitoring >
Backend health.
Each member in the back-end pool is listed on this page (whether it's a NIC, IP, or FQDN ). Back-end pool name,
port, back-end HTTP settings name, and health status are shown. Valid values for health status are Healthy,
Unhealthy, and Unknown.
NOTE
If you see a back-end health status of Unknown, ensure that access to the back end is not blocked by an NSG rule, a user-
defined route (UDR), or a custom DNS in the virtual network.
View back-end health through PowerShell
The following PowerShell code shows how to view back-end health by using the
Get-AzureRmApplicationGatewayBackendHealth cmdlet:
Get-AzureRmApplicationGatewayBackendHealth -Name ApplicationGateway1 -ResourceGroupName Contoso
View back-end health through Azure CLI 2.0
az network application-gateway show-backend-health --resource-group AdatumAppGatewayRG --name AdatumAppGateway
Results
The following snippet shows an example of the response:
{
"BackendAddressPool": {
"Id": "/subscriptions/00000000-0000-0000-
000000000000/resourceGroups/ContosoRG/providers/Microsoft.Network/applicationGateways/applicationGateway1/back
endAddressPools/appGatewayBackendPool"
},
"BackendHttpSettingsCollection": [
{
"BackendHttpSettings": {
"Id": "/00000000-0000-0000-
000000000000/resourceGroups/ContosoRG/providers/Microsoft.Network/applicationGateways/applicationGateway1/back
endHttpSettingsCollection/appGatewayBackendHttpSettings"
},
"Servers": [
{
"Address": "hostname.westus.cloudapp.azure.com",
"Health": "Healthy"
},
{
"Address": "hostname.westus.cloudapp.azure.com",
"Health": "Healthy"
}
]
}
]
}
Diagnostic logs
You can use different types of logs in Azure to manage and troubleshoot application gateways. You can access
some of these logs through the portal. All logs can be extracted from Azure Blob storage and viewed in different
tools, such as Log Analytics, Excel, and Power BI. You can learn more about the different types of logs from the
following list:
Activity log: You can use Azure activity logs (formerly known as operational logs and audit logs) to view all
operations that are submitted to your Azure subscription, and their status. Activity log entries are collected by
default, and you can view them in the Azure portal.
Access log: You can use this log to view Application Gateway access patterns and analyze important
information, including the caller's IP, requested URL, response latency, return code, and bytes in and out. An
access log is collected every 300 seconds. This log contains one record per instance of Application Gateway.
The Application Gateway instance can be identified by the instanceId property.
Performance log: You can use this log to view how Application Gateway instances are performing. This log
captures performance information for each instance, including total requests served, throughput in bytes, total
requests served, failed request count, and healthy and unhealthy back-end instance count. A performance log is
collected every 60 seconds.
Firewall log: You can use this log to view the requests that are logged through either detection or prevention
mode of an application gateway that is configured with the web application firewall.
NOTE
Logs are available only for resources deployed in the Azure Resource Manager deployment model. You cannot use logs for
resources in the classic deployment model. For a better understanding of the two models, see the Understanding Resource
Manager deployment and classic deployment article.
You have three options for storing your logs:

Storage account: Storage accounts are best used for logs when logs are stored for a longer duration and
reviewed when needed.
Event hubs: Event hubs are a great option for integrating with other security information and event
management (SEIM ) tools to get alerts on your resources.
Log Analytics: Log Analytics is best used for general real-time monitoring of your application or looking at
trends.
Enable logging through PowerShell
Activity logging is automatically enabled for every Resource Manager resource. You must enable access and
performance logging to start collecting the data available through those logs. To enable logging, use the following
steps:
1. Note your storage account's resource ID, where the log data is stored. This value is of the form:
/subscriptions/<subscriptionId>/resourceGroups/<resource group
name>/providers/Microsoft.Storage/storageAccounts/<storage account name>. You can use any storage
account in your subscription. You can use the Azure portal to find this information.
2. Note your application gateway's resource ID for which logging is enabled. This value is of the form:
/subscriptions/<subscriptionId>/resourceGroups/<resource group
name>/providers/Microsoft.Network/applicationGateways/<application gateway name>. You can use the
portal to find this information.
3. Enable diagnostic logging by using the following PowerShell cmdlet:
Set-AzureRmDiagnosticSetting -ResourceId /subscriptions/<subscriptionId>/resourceGroups/<resource

group name>/providers/Microsoft.Network/applicationGateways/<application gateway name> -
StorageAccountId /subscriptions/<subscriptionId>/resourceGroups/<resource group
name>/providers/Microsoft.Storage/storageAccounts/<storage account name> -Enabled $true
TIP
Activity logs do not require a separate storage account. The use of storage for access and performance logging incurs
service charges.
Enable logging through the Azure portal

1. In the Azure portal, find your resource and click Diagnostic logs.
For Application Gateway, three logs are available:
Access log
Performance log
Firewall log
2. To start collecting data, click Turn on diagnostics.
3. The Diagnostics settings blade provides the settings for the diagnostic logs. In this example, Log
Analytics stores the logs. Click Configure under Log Analytics to configure your workspace. You can also
use event hubs and a storage account to save the diagnostic logs.
4. Choose an existing Log Analytics workspace or create a new one. This example uses an existing one.
5. Confirm the settings and click Save.
Activity log
Azure generates the activity log by default. The logs are preserved for 90 days in the Azure event logs store. Learn
more about these logs by reading the View events and activity log article.
Access log
The access log is generated only if you've enabled it on each Application Gateway instance, as detailed in the
preceding steps. The data is stored in the storage account that you specified when you enabled the logging. Each
access of Application Gateway is logged in JSON format, as shown in the following example:
VALUE DESCRIPTION
instanceId Application Gateway instance that served the request.
clientIP Originating IP for the request.
clientPort Originating port for the request.

VALUE DESCRIPTION
httpMethod HTTP method used by the request.
requestUri URI of the received request.
RequestQuery Server-Routed: Back-end pool instance that was sent the

request.
X-AzureApplicationGateway-LOG-ID: Correlation ID used
for the request. It can be used to troubleshoot traffic issues
on the back-end servers.
SERVER-STATUS: HTTP response code that Application
Gateway received from the back end.
UserAgent User agent from the HTTP request header.
httpStatus HTTP status code returned to the client from Application

Gateway.
httpVersion HTTP version of the request.
receivedBytes Size of packet received, in bytes.
sentBytes Size of packet sent, in bytes.
timeTaken Length of time (in milliseconds) that it takes for a request to

be processed and its response to be sent. This is calculated as
the interval from the time when Application Gateway receives
the first byte of an HTTP request to the time when the
response send operation finishes. It's important to note that
the Time-Taken field usually includes the time that the request
and response packets are traveling over the network.
sslEnabled Whether communication to the back-end pools used SSL.

Valid values are on and off.
{
"resourceId":
"/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/PEERINGTEST/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{a
pplicationGatewayName}",
"operationName": "ApplicationGatewayAccess",
"time": "2017-04-26T19:27:38Z",
"category": "ApplicationGatewayAccessLog",
"properties": {
"clientIP": "191.96.249.97",
"clientPort": 46886,
"httpMethod": "GET",
"requestUri": "/phpmyadmin/scripts/setup.php",
"requestQuery": "X-AzureApplicationGateway-CACHE-HIT=0&SERVER-ROUTED=10.4.0.4&X-
AzureApplicationGateway-LOG-ID=874f1f0f-6807-41c9-b7bc-f3cfa74aa0b1&SERVER-STATUS=404",
"userAgent": "-",
"httpStatus": 404,
"httpVersion": "HTTP/1.0",
"receivedBytes": 65,
"sentBytes": 553,
"timeTaken": 205,
"sslEnabled": "off"
}
}
Performance log
The performance log is generated only if you have enabled it on each Application Gateway instance, as detailed in
the preceding steps. The data is stored in the storage account that you specified when you enabled the logging.
The performance log data is generated in 1-minute intervals. The following data is logged:
VALUE DESCRIPTION
instanceId Application Gateway instance for which performance data is

being generated. For a multiple-instance application gateway,
there is one row per instance.
healthyHostCount Number of healthy hosts in the back-end pool.
unHealthyHostCount Number of unhealthy hosts in the back-end pool.
requestCount Number of requests served.
latency Latency (in milliseconds) of requests from the instance to the

back end that serves the requests.
failedRequestCount Number of failed requests.
throughput Average throughput since the last log, measured in bytes per
second.
{
"resourceId":
"/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGAT
EWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayPerformance",
"time": "2016-04-09T00:00:00Z",
"category": "ApplicationGatewayPerformanceLog",
"properties":
{
"instanceId":"ApplicationGatewayRole_IN_1",
"healthyHostCount":"4",
"unHealthyHostCount":"0",
"requestCount":"185",
"latency":"0",
"failedRequestCount":"0",
"throughput":"119427"
}
}
NOTE
Latency is calculated from the time when the first byte of the HTTP request is received to the time when the last byte of the
HTTP response is sent. It's the sum of the Application Gateway processing time plus the network cost to the back end, plus
the time that the back end takes to process the request.
Firewall log
The firewall log is generated only if you have enabled it for each application gateway, as detailed in the preceding
steps. This log also requires that the web application firewall is configured on an application gateway. The data is
stored in the storage account that you specified when you enabled the logging. The following data is logged:
VALUE DESCRIPTION
instanceId Application Gateway instance for which firewall data is being

generated. For a multiple-instance application gateway, there
is one row per instance.
clientIp Originating IP for the request.
clientPort Originating port for the request.
requestUri URL of the received request.
ruleSetType Rule set type. The available value is OWASP.
ruleSetVersion Rule set version used. Available values are 2.2.9 and 3.0.
ruleId Rule ID of the triggering event.
message User-friendly message for the triggering event. More details

are provided in the details section.
action Action taken on the request. Available values are Blocked and
Allowed.
site Site for which the log was generated. Currently, only Global is
listed because rules are global.
VALUE DESCRIPTION
details Details of the triggering event.
details.message Description of the rule.
details.data Specific data found in request that matched the rule.
details.file Configuration file that contained the rule.
details.line Line number in the configuration file that triggered the event.
{
"resourceId":
"/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGAT
EWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"time": "2017-03-20T15:52:09.1494499Z",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"clientIp": "104.210.252.3",
"clientPort": "4835",
"requestUri": "/?a=%3Cscript%3Ealert(%22Hello%22);%3C/script%3E",
"ruleId": "941320",
"message": "Possible XSS Attack Detected - HTML Tag Handler",
"action": "Blocked",
"site": "Global",
"details": {
"message": "Warning. Pattern match \"
<(a|abbr|acronym|address|applet|area|audioscope|b|base|basefront|bdo|bgsound|big|blackface|blink|blockquote|bo
dy|bq|br|button|caption|center|cite|code|col|colgroup|comment|dd|del|dfn|dir|div|dl|dt|em|embed|fieldset|fn|fo
nt|form|frame|frameset|h1|head|h ...\" at ARGS:a.",
"data": "Matched Data: <script> found within ARGS:a: <script>alert(\\x22hello\\x22);</script>",
"file": "rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf",
"line": "865"
}
}
}
View and analyze the activity log

You can view and analyze activity log data by using any of the following methods:
Azure tools: Retrieve information from the activity log through Azure PowerShell, the Azure CLI, the Azure
REST API, or the Azure portal. Step-by-step instructions for each method are detailed in the Activity
operations with Resource Manager article.
Power BI: If you don't already have a Power BI account, you can try it for free. By using the Azure Activity
Logs content pack for Power BI, you can analyze your data with preconfigured dashboards that you can use as
is or customize.
View and analyze the access, performance, and firewall logs
Azure Log Analytics can collect the counter and event log files from your Blob storage account. It includes
visualizations and powerful search capabilities to analyze your logs.
You can also connect to your storage account and retrieve the JSON log entries for access and performance logs.
After you download the JSON files, you can convert them to CSV and view them in Excel, Power BI, or any other
data-visualization tool.
TIP
If you are familiar with Visual Studio and basic concepts of changing values for constants and variables in C#, you can use
the log converter tools available from GitHub.
Metrics
Metrics are a feature for certain Azure resources where you can view performance counters in the portal. For
Application Gateway, the following metrics are available:
Current Connections
Failed Requests
Healthy Host Count
You can filter on a per backend pool basis to show healthy/unhealthy hosts in a specific backend pool.
Response Status
The response status code distribution can be further categorized to show responses in 2xx, 3xx, 4xx, and 5xx
categories.
Throughput
Total Requests
Unhealthy Host count
You can filter on a per backend pool basis to show healthy/unhealthy hosts in a specific backend pool.
Browse to an application gateway, under Monitoring click Metrics. To view the available values, select the
METRIC drop-down list.
In the following image, you see an example with three metrics displayed for the last 30 minutes:
To see a current list of metrics, see Supported metrics with Azure Monitor.
Alert rules
You can start alert rules based on metrics for a resource. For example, an alert can call a webhook or email an
administrator if the throughput of the application gateway is above, below, or at a threshold for a specified period.
The following example walks you through creating an alert rule that sends an email to an administrator after
throughput breaches a threshold:
1. Click Add metric alert to open the Add rule blade. You can also reach this blade from the metrics blade.
2. On the Add rule blade, fill out the name, condition, and notify sections, and click OK.
In the Condition selector, select one of the four values: Greater than, Greater than or equal, Less
than, or Less than or equal to.
In the Period selector, select a period from five minutes to six hours.
If you select Email owners, contributors, and readers, the email can be dynamic based on the
users who have access to that resource. Otherwise, you can provide a comma-separated list of users
in the Additional administrator email(s) box.
If the threshold is breached, an email that's similar to the one in the following image arrives:
A list of alerts appears after you create a metric alert. It provides an overview of all the alert rules.
To learn more about alert notifications, see Receive alert notifications.

To understand more about webhooks and how you can use them with alerts, visit Configure a webhook on an
Azure metric alert.
Next steps
Visualize counter and event logs by using Log Analytics.
Visualize your Azure activity log with Power BI blog post.
View and analyze Azure activity logs in Power BI and more blog post.
List of web application firewall CRS rule groups and
rules offered
Application Gateway web application firewall (WAF ) protects web applications from common vulnerabilities and
exploits. This is done through rules that are defined based on the OWASP core rule sets 2.2.9 or 3.0. These rules
can be disabled on a rule by rule basis. This article contains the current rules and rulesets offered.
The following tables are the Rule groups and rules that are available when using Application Gateway with web
application firewall. Each table represents the rules found in a rule group for a specific CRS version.
OWASP_3.0
REQUEST -911-METHOD-ENFORCEMENT
RULEID DESCRIPTION
911011 Rule 911011
911012 Rule 911012
911100 Method is not allowed by policy
911013 Rule 911013
911014 Rule 911014
911015 Rule 911015
911016 Rule 911016
911017 Rule 911017
911018 Rule 911018
REQUEST -913-SCANNER -DETECTION
RULEID DESCRIPTION
913011 Rule 913011
913012 Rule 913012
913100 Found User-Agent associated with security scanner
913110 Found request header associated with security scanner
913120 Found request filename/argument associated with security

scanner
RULEID DESCRIPTION
913013 Rule 913013
913014 Rule 913014
913101 Found User-Agent associated with scripting/generic HTTP

client
913102 Found User-Agent associated with web crawler/bot
913015 Rule 913015
913016 Rule 913016
913017 Rule 913017
913018 Rule 913018
REQUEST -920-PROTOCOL -ENFORCEMENT
RULEID DESCRIPTION
920011 Rule 920011
920012 Rule 920012
920130 Failed to parse request body.
920140 Multipart request body failed strict validation = PE

%@{REQBODY_PROCESSOR_ERROR} BQ
%@{MULTIPART_BOUNDARY_QUOTED} BW
%@{MULTIPART_BOUNDARY_WHITESPACE} DB
%@{MULTIPART_DATA_BEFORE} DA
%@{MULTIPART_DATA_AFTER} HF
%@{MULTIPART_HEADER_FOLDING} LF
%@{MULTIPART_LF_LINE} SM
%@{MULTIPART_SEMICOLON_MISSING} IQ
%@{MULTIPART_INVALID_QUOTING} IH
%@{MULTIPART_INVALID_HEADER_FOLDING} FLE
%@{MULTIPART_FILE_LIMIT_EXCEEDED}
920160 Content-Length HTTP header is not numeric.
920170 GET or HEAD Request with Body Content.
920180 POST request missing Content-Length Header.
920190 Range = Invalid Last Byte Value.
920210 Multiple/Conflicting Connection Header Data Found.

RULEID DESCRIPTION
920220 URL Encoding Abuse Attack Attempt
920250 UTF8 Encoding Abuse Attack Attempt
920260 Unicode Full/Half Width Abuse Attack Attempt
920270 Invalid character in request (null character)
920280 Request Missing a Host Header
920290 Empty Host Header
920310 Request Has an Empty Accept Header
920330 Empty User Agent Header
920340 Request Containing Content but Missing Content-Type

header
920350 Host header is a numeric IP address
920380 Too many arguments in request
920360 Argument name too long
920370 Argument value too long
920390 Total arguments size exceeded
920400 Uploaded file size too large
920410 Total uploaded files size too large
920420 Request content type is not allowed by policy
920430 HTTP protocol version is not allowed by policy
920440 URL file extension is restricted by policy
920450 HTTP header is restricted by policy (%@{MATCHED_VAR})
920013 Rule 920013
920014 Rule 920014
920200 Range = Too many fields (6 or more)

RULEID DESCRIPTION
920201 Range = Too many fields for pdf request (35 or more)
920230 Multiple URL Encoding Detected
920300 Request Missing an Accept Header
920271 Invalid character in request (non printable characters)
920320 Missing User Agent Header
920015 Rule 920015
920016 Rule 920016
920272 Invalid character in request (outside of printable chars below

ascii 127)
920017 Rule 920017
920018 Rule 920018
920202 Range = Too many fields for pdf request (6 or more)
920273 Invalid character in request (outside of very strict set)
920274 Invalid character in request headers (outside of very strict set)
920460 Rule 920460
REQUEST -921-PROTOCOL -ATTACK
RULEID DESCRIPTION
921011 Rule 921011
921012 Rule 921012
921100 HTTP Request Smuggling Attack.
921110 HTTP Request Smuggling Attack
921120 HTTP Response Splitting Attack
921140 HTTP Header Injection Attack via headers
921150 HTTP Header Injection Attack via payload (CR/LF detected)
921160 HTTP Header Injection Attack via payload (CR/LF and header-
name detected)
RULEID DESCRIPTION
921013 Rule 921013
921014 Rule 921014
921151 HTTP Header Injection Attack via payload (CR/LF detected)
921015 Rule 921015
921016 Rule 921016
921170 Rule 921170
921180 HTTP Parameter Pollution (%@{TX.1})
921017 Rule 921017
921018 Rule 921018
REQUEST -930-APPLICATION -ATTACK -LFI
RULEID DESCRIPTION
930011 Rule 930011
930012 Rule 930012
930100 Path Traversal Attack (/../)
930110 Path Traversal Attack (/../)
930120 OS File Access Attempt
930130 Restricted File Access Attempt
930013 Rule 930013
930014 Rule 930014
930015 Rule 930015
930016 Rule 930016
930017 Rule 930017
930018 Rule 930018
REQUEST -931-APPLICATION -ATTACK -RFI

RULEID DESCRIPTION
931011 Rule 931011
931012 Rule 931012
931100 Possible Remote File Inclusion (RFI) Attack = URL Parameter

using IP Address
931110 Possible Remote File Inclusion (RFI) Attack = Common RFI

Vulnerable Parameter Name used w/URL Payload
931120 Possible Remote File Inclusion (RFI) Attack = URL Payload

Used w/Trailing Question Mark Character (?)
931013 Rule 931013
931014 Rule 931014
931130 Possible Remote File Inclusion (RFI) Attack = Off-Domain

Reference/Link
931015 Rule 931015
931016 Rule 931016
931017 Rule 931017
931018 Rule 931018
REQUEST -932-APPLICATION -ATTACK -RCE
RULEID DESCRIPTION
932011 Rule 932011
932012 Rule 932012
932120 Remote Command Execution = Windows PowerShell

Command Found
932130 Remote Command Execution = Unix Shell Expression Found
932140 Remote Command Execution = Windows FOR/IF Command

Found
932160 Remote Command Execution = Unix Shell Code Found
932170 Remote Command Execution = Shellshock (CVE-2014-6271)
932171 Remote Command Execution = Shellshock (CVE-2014-6271)
932013 Rule 932013

RULEID DESCRIPTION
932014 Rule 932014
932015 Rule 932015
932016 Rule 932016
932017 Rule 932017
932018 Rule 932018
REQUEST -933-APPLICATION -ATTACK -PHP
RULEID DESCRIPTION
933011 Rule 933011
933012 Rule 933012
933100 PHP Injection Attack = Opening/Closing Tag Found
933110 PHP Injection Attack = PHP Script File Upload Found
933120 PHP Injection Attack = Configuration Directive Found
933130 PHP Injection Attack = Variables Found
933150 PHP Injection Attack = High-Risk PHP Function Name Found
933160 PHP Injection Attack = High-Risk PHP Function Call Found
933180 PHP Injection Attack = Variable Function Call Found
933013 Rule 933013
933014 Rule 933014
933151 PHP Injection Attack = Medium-Risk PHP Function Name

Found
933015 Rule 933015
933016 Rule 933016
933131 PHP Injection Attack = Variables Found
933161 PHP Injection Attack = Low-Value PHP Function Call Found
933111 PHP Injection Attack = PHP Script File Upload Found
933017 Rule 933017

RULEID DESCRIPTION
933018 Rule 933018
REQUEST -941-APPLICATION -ATTACK -XSS
RULEID DESCRIPTION
941011 Rule 941011
941012 Rule 941012
941100 XSS Attack Detected via libinjection
941110 XSS Filter - Category 1 = Script Tag Vector
941130 XSS Filter - Category 3 = Attribute Vector
941140 XSS Filter - Category 4 = Javascript URI Vector
941150 XSS Filter - Category 5 = Disallowed HTML Attributes
941180 Node-Validator Blacklist Keywords
941190 IE XSS Filters - Attack Detected.
941310 US-ASCII Malformed Encoding XSS Filter - Attack Detected.
941350 UTF-7 Encoding IE XSS - Attack Detected.
941013 Rule 941013

RULEID DESCRIPTION
941014 Rule 941014
941320 Possible XSS Attack Detected - HTML Tag Handler
941015 Rule 941015
941016 Rule 941016
941017 Rule 941017
941018 Rule 941018
REQUEST -942-APPLICATION -ATTACK -SQLI
RULEID DESCRIPTION
942011 Rule 942011
942012 Rule 942012
942100 SQL Injection Attack Detected via libinjection
942140 SQL Injection Attack = Common DB Names Detected
942160 Detects blind sqli tests using sleep() or benchmark().
942170 Detects SQL benchmark and sleep injection attempts

including conditional queries
942230 Detects conditional SQL injection attempts
942270 Looking for basic sql injection. Common attack string for
mysql oracle and others.
942290 Finds basic MongoDB SQL injection attempts
942320 Detects MySQL and PostgreSQL stored procedure/function

injections
942350 Detects MySQL UDF injection and other data/structure

manipulation attempts
942013 Rule 942013
942014 Rule 942014
942150 SQL Injection Attack
942440 SQL Comment Sequence Detected.

RULEID DESCRIPTION
942450 SQL Hex Encoding Identified
942015 Rule 942015
942016 Rule 942016
942251 Detects HAVING injections
942460 Meta-Character Anomaly Detection Alert - Repetitive Non-

Word Characters
942017 Rule 942017
942018 Rule 942018
REQUEST -943-APPLICATION -ATTACK -SESSION -FIXATION
RULEID DESCRIPTION
943011 Rule 943011
943012 Rule 943012
943100 Possible Session Fixation Attack = Setting Cookie Values in

HTML
943110 Possible Session Fixation Attack = SessionID Parameter Name

with Off-Domain Referrer
943120 Possible Session Fixation Attack = SessionID Parameter Name

with No Referrer
943013 Rule 943013
943014 Rule 943014
943015 Rule 943015
943016 Rule 943016
943017 Rule 943017
943018 Rule 943018
OWASP_2.2.9
crs_20_protocol_violations
RULEID DESCRIPTION

RULEID DESCRIPTION
981227 Apache Error = Invalid URI in Request.
960912 Failed to parse request body.
960914 Multipart request body failed strict validation = PE

%@{REQBODY_PROCESSOR_ERROR} BQ
%@{MULTIPART_BOUNDARY_QUOTED} BW
%@{MULTIPART_BOUNDARY_WHITESPACE} DB
%@{MULTIPART_DATA_BEFORE} DA
%@{MULTIPART_DATA_AFTER} HF
%@{MULTIPART_HEADER_FOLDING} LF
%@{MULTIPART_LF_LINE} SM
%@{MULTIPART_SEMICOLON_MISSING} IQ
%@{MULTIPART_INVALID_QUOTING} IH
%@{MULTIPART_INVALID_HEADER_FOLDING} FLE
%@{MULTIPART_FILE_LIMIT_EXCEEDED}
960915 Multipart parser detected a possible unmatched boundary.
960016 Content-Length HTTP header is not numeric.
960011 GET or HEAD Request with Body Content.
960012 POST request missing Content-Length Header.
960902 Invalid Use of Identity Encoding.
960022 Expect Header Not Allowed for HTTP 1.0.
960020 Pragma Header requires Cache-Control Header for HTTP/1.1

requests.
958291 Range = field exists and begins with 0.
958230 Range = Invalid Last Byte Value.
958295 Multiple/Conflicting Connection Header Data Found.
950109 Multiple URL Encoding Detected
950801 UTF8 Encoding Abuse Attack Attempt
950116 Unicode Full/Half Width Abuse Attack Attempt
960901 Invalid character in request
960018 Invalid character in request
crs_21_protocol_anomalies
RULEID DESCRIPTION
960008 Request Missing a Host Header
960007 Empty Host Header
960015 Request Missing an Accept Header
960009 Request Missing a User Agent Header
960006 Empty User Agent Header
960904 Request Containing Content but Missing Content-Type

header
960017 Host header is a numeric IP address
crs_23_request_limits
RULEID DESCRIPTION
960209 Argument name too long
960208 Argument value too long
960335 Too many arguments in request
960341 Total arguments size exceeded
960342 Uploaded file size too large
960343 Total uploaded files size too large
crs_30_http_policy
RULEID DESCRIPTION
960032 Method is not allowed by policy
960010 Request content type is not allowed by policy
960034 HTTP protocol version is not allowed by policy
960035 URL file extension is restricted by policy
960038 HTTP header is restricted by policy
crs_35_bad_robots
RULEID DESCRIPTION
990002 Request Indicates a Security Scanner Scanned the Site
990012 Rogue web site crawler
crs_40_generic_attacks
RULEID DESCRIPTION
960024 Meta-Character Anomaly Detection Alert - Repetitive Non-

Word Characters
950008 Injection of Undocumented ColdFusion Tags
950010 LDAP Injection Attack
950011 SSI injection Attack
950018 Universal PDF XSS URL Detected.
950019 Email Injection Attack
950012 HTTP Request Smuggling Attack.
950117 Remote File Inclusion Attack
950120 Possible Remote File Inclusion (RFI) Attack = Off-Domain

Reference/Link
981133 Rule 981133
981134 Rule 981134
950009 Session Fixation Attack
950003 Session Fixation
950000 Session Fixation
950005 Remote File Access Attempt

RULEID DESCRIPTION
950002 System Command Access
950006 System Command Injection
959151 PHP Injection Attack
crs_41_sql_injection_attacks
RULEID DESCRIPTION
981231 SQL Comment Sequence Detected.
981260 SQL Hex Encoding Identified
981320 SQL Injection Attack = Common DB Names Detected
981300 Rule 981300
981301 Rule 981301
981302 Rule 981302
981303 Rule 981303
981304 Rule 981304
981305 Rule 981305
981306 Rule 981306
981307 Rule 981307
981308 Rule 981308
981309 Rule 981309
981310 Rule 981310
981311 Rule 981311
981312 Rule 981312
981313 Rule 981313
981314 Rule 981314

RULEID DESCRIPTION
981315 Rule 981315
981316 Rule 981316
981317 SQL SELECT Statement Anomaly Detection Alert
950007 Blind SQL Injection Attack
950908 SQL Injection Attack.
981272 Detects blind sqli tests using sleep() or benchmark().
981250 Detects SQL benchmark and sleep injection attempts

including conditional queries
981241 Detects conditional SQL injection attempts
981276 Looking for basic sql injection. Common attack string for
mysql oracle and others.
981270 Finds basic MongoDB SQL injection attempts
981253 Detects MySQL and PostgreSQL stored procedure/function

injections
981251 Detects MySQL UDF injection and other data/structure

manipulation attempts
crs_41_xss_attacks
RULEID DESCRIPTION
973336 XSS Filter - Category 1 = Script Tag Vector
973338 XSS Filter - Category 3 = Javascript URI Vector
981136 Rule 981136
981018 Rule 981018
958016 Cross-site Scripting (XSS) Attack

RULEID DESCRIPTION

RULEID DESCRIPTION

RULEID DESCRIPTION
973300 Possible XSS Attack Detected - HTML Tag Handler
973301 XSS Attack Detected

RULEID DESCRIPTION
crs_42_tight_security
RULEID DESCRIPTION
950103 Path Traversal Attack
crs_45_trojans
RULEID DESCRIPTION
950110 Backdoor access

Next steps
Learn how to disable WAF rules by visiting: Customize WAF rules
Azure Resource Manager overview
The infrastructure for your application is typically made up of many components – maybe a virtual machine,
storage account, and virtual network, or a web app, database, database server, and third-party services. You don't
see these components as separate entities, instead you see them as related and interdependent parts of a single
entity. You want to deploy, manage, and monitor them as a group. Azure Resource Manager enables you to work
with the resources in your solution as a group. You can deploy, update, or delete all the resources for your solution
in a single, coordinated operation. You use a template for deployment and that template can work for different
environments such as testing, staging, and production. Resource Manager provides security, auditing, and tagging
features to help you manage your resources after deployment.
Consistent management layer

Resource Manager provides a consistent management layer to perform tasks through Azure PowerShell, Azure
CLI, Azure portal, REST API, and client SDKs. All capabilities that are available in the Azure portal are also
available through Azure PowerShell, Azure CLI, the Azure REST APIs, and client SDKs. Functionality initially
released through APIs will be represented in the portal within 180 days of initial release.
Choose the tools and APIs that work best for you - they have the same capability and provide consistent results.
The following image shows how all the tools interact with the same Azure Resource Manager API. The API passes
requests to the Resource Manager service, which authenticates and authorizes the requests. Resource Manager
then routes the requests to the appropriate resource providers.
Terminology
If you're new to Azure Resource Manager, there are some terms you might not be familiar with.
resource - A manageable item that is available through Azure. Some common resources are a virtual machine,
storage account, web app, database, and virtual network, but there are many more.
resource group - A container that holds related resources for an Azure solution. The resource group can
include all the resources for the solution, or only those resources that you want to manage as a group. You
decide how you want to allocate resources to resource groups based on what makes the most sense for your
organization. See Resource groups.
resource provider - A service that supplies the resources you can deploy and manage through Resource
Manager. Each resource provider offers operations for working with the resources that are deployed. Some
common resource providers are Microsoft.Compute, which supplies the virtual machine resource,
Microsoft.Storage, which supplies the storage account resource, and Microsoft.Web, which supplies resources
related to web apps. See Resource providers.
Resource Manager template - A JavaScript Object Notation (JSON ) file that defines one or more resources
to deploy to a resource group. It also defines the dependencies between the deployed resources. The template
can be used to deploy the resources consistently and repeatedly. See Template deployment.
declarative syntax - Syntax that lets you state "Here is what I intend to create" without having to write the
sequence of programming commands to create it. The Resource Manager template is an example of declarative
syntax. In the file, you define the properties for the infrastructure to deploy to Azure.
The benefits of using Resource Manager

Resource Manager provides several benefits:
You can deploy, manage, and monitor all the resources for your solution as a group, rather than handling these
resources individually.
You can repeatedly deploy your solution throughout the development lifecycle and have confidence your
resources are deployed in a consistent state.
You can manage your infrastructure through declarative templates rather than scripts.
You can define the dependencies between resources so they're deployed in the correct order.
You can apply access control to all services in your resource group because Role-Based Access Control (RBAC )
is natively integrated into the management platform.
You can apply tags to resources to logically organize all the resources in your subscription.
You can clarify your organization's billing by viewing costs for a group of resources sharing the same tag.
Resource Manager provides a new way to deploy and manage your solutions. If you used the earlier deployment
model and want to learn about the changes, see Understanding Resource Manager deployment and classic
deployment.
Guidance
The following suggestions help you take full advantage of Resource Manager when working with your solutions.
1. Define and deploy your infrastructure through the declarative syntax in Resource Manager templates, rather
than through imperative commands.
2. Define all deployment and configuration steps in the template. You should have no manual steps for setting up
your solution.
3. Run imperative commands to manage your resources, such as to start or stop an app or machine.
4. Arrange resources with the same lifecycle in a resource group. Use tags for all other organizing of resources.
For guidance on how enterprises can use Resource Manager to effectively manage subscriptions, see Azure
enterprise scaffold - prescriptive subscription governance.
For recommendations on creating Resource Manager templates that you can use across global Azure, Azure
sovereign clouds, and Azure Stack, see Develop Azure Resource Manager templates for cloud consistency.
Resource groups
There are some important factors to consider when defining your resource group:
1. All the resources in your group should share the same lifecycle. You deploy, update, and delete them together. If
one resource, such as a database server, needs to exist on a different deployment cycle it should be in another
resource group.
2. Each resource can only exist in one resource group.
3. You can add or remove a resource to a resource group at any time.
4. You can move a resource from one resource group to another group. For more information, see Move
resources to new resource group or subscription.
5. A resource group can contain resources that reside in different regions.
6. A resource group can be used to scope access control for administrative actions.
7. A resource can interact with resources in other resource groups. This interaction is common when the two
resources are related but don't share the same lifecycle (for example, web apps connecting to a database).
When creating a resource group, you need to provide a location for that resource group. You may be wondering,
"Why does a resource group need a location? And, if the resources can have different locations than the resource
group, why does the resource group location matter at all?" The resource group stores metadata about the
resources. Therefore, when you specify a location for the resource group, you're specifying where that metadata is
stored. For compliance reasons, you may need to ensure that your data is stored in a particular region.
Resource providers
Each resource provider offers a set of resources and operations for working with an Azure service. For example, if
you want to store keys and secrets, you work with the Microsoft.KeyVault resource provider. This resource
provider offers a resource type called vaults for creating the key vault.
The name of a resource type is in the format: {resource-provider}/{resource-type}. For example, the key vault
type is Microsoft.KeyVault/vaults.
Before getting started with deploying your resources, you should gain an understanding of the available resource
providers. Knowing the names of resource providers and resources helps you define resources you want to deploy
to Azure. Also, you need to know the valid locations and API versions for each resource type. For more
information, see Resource providers and types.
Template deployment
With Resource Manager, you can create a template (in JSON format) that defines the infrastructure and
configuration of your Azure solution. By using a template, you can repeatedly deploy your solution throughout its
lifecycle and have confidence your resources are deployed in a consistent state. When you create a solution from
the portal, the solution automatically includes a deployment template. You don't have to create your template from
scratch because you can start with the template for your solution and customize it to meet your specific needs. You
can retrieve a template for an existing resource group by either exporting the current state of the resource group,
or viewing the template used for a particular deployment. Viewing the exported template is a helpful way to learn
about the template syntax.
To learn about the format of the template and how you construct it, see Create your first Azure Resource Manager
template. To view the JSON syntax for resources types, see Define resources in Azure Resource Manager
templates.
Resource Manager processes the template like any other request (see the image for Consistent management
layer). It parses the template and converts its syntax into REST API operations for the appropriate resource
providers. For example, when Resource Manager receives a template with the following resource definition:
"resources": [
{
"apiVersion": "2016-01-01",
"type": "Microsoft.Storage/storageAccounts",
"name": "mystorageaccount",
"location": "westus",
"sku": {
"name": "Standard_LRS"
},
"kind": "Storage",
"properties": {
}
}
]
It converts the definition to the following REST API operation, which is sent to the Microsoft.Storage resource
provider:
PUT
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Micro
soft.Storage/storageAccounts/mystorageaccount?api-version=2016-01-01
REQUEST BODY
{
"location": "westus",
"properties": {
}
"sku": {
},
"kind": "Storage"
}
How you define templates and resource groups is entirely up to you and how you want to manage your solution.
For example, you can deploy your three tier application through a single template to a single resource group.
But, you don't have to define your entire infrastructure in a single template. Often, it makes sense to divide your
deployment requirements into a set of targeted, purpose-specific templates. You can easily reuse these templates
for different solutions. To deploy a particular solution, you create a master template that links all the required
templates. The following image shows how to deploy a three tier solution through a parent template that includes
three nested templates.
If you envision your tiers having separate lifecycles, you can deploy your three tiers to separate resource groups.
Notice the resources can still be linked to resources in other resource groups.
For information about nested templates, see Using linked templates with Azure Resource Manager.
Azure Resource Manager analyzes dependencies to ensure resources are created in the correct order. If one
resource relies on a value from another resource (such as a virtual machine needing a storage account for disks),
you set a dependency. For more information, see Defining dependencies in Azure Resource Manager templates.
You can also use the template for updates to the infrastructure. For example, you can add a resource to your
solution and add configuration rules for the resources that are already deployed. If the template specifies creating a
resource but that resource already exists, Azure Resource Manager performs an update instead of creating a new
asset. Azure Resource Manager updates the existing asset to the same state as it would be as new.
Resource Manager provides extensions for scenarios when you need additional operations such as installing
particular software that isn't included in the setup. If you're already using a configuration management service, like
DSC, Chef or Puppet, you can continue working with that service by using extensions. For information about
virtual machine extensions, see About virtual machine extensions and features.
Finally, the template becomes part of the source code for your app. You can check it in to your source code
repository and update it as your app evolves. You can edit the template through Visual Studio.
After defining your template, you're ready to deploy the resources to Azure. For the commands to deploy the
resources, see:
Deploy resources with Resource Manager templates and Azure PowerShell
Deploy resources with Resource Manager templates and Azure CLI
Deploy resources with Resource Manager templates and Azure portal
Deploy resources with Resource Manager templates and Resource Manager REST API
Tags
Resource Manager provides a tagging feature that enables you to categorize resources according to your
requirements for managing or billing. Use tags when you have a complex collection of resource groups and
resources, and need to visualize those assets in the way that makes the most sense to you. For example, you could
tag resources that serve a similar role in your organization or belong to the same department. Without tags, users
in your organization can create multiple resources that may be difficult to later identify and manage. For example,
you may wish to delete all the resources for a particular project. If those resources aren't tagged for the project,
you have to manually find them. Tagging can be an important way for you to reduce unnecessary costs in your
subscription.
Resources do not need to reside in the same resource group to share a tag. You can create your own tag taxonomy
to ensure that all users in your organization use common tags rather than users inadvertently applying slightly
different tags (such as "dept" instead of "department").
The following example shows a tag applied to a virtual machine.
"resources": [
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2015-06-15",
"name": "SimpleWindowsVM",
"location": "[resourceGroup().location]",
"tags": {
"costCenter": "Finance"
},
...
}
]
To retrieve all the resources with a tag value, use the following PowerShell cmdlet:
Find-AzureRmResource -TagName costCenter -TagValue Finance
Or, the following Azure CLI 2.0 command:
az resource list --tag costCenter=Finance
You can also view tagged resources through the Azure portal.
The usage report for your subscription includes tag names and values, which enables you to break out costs by
tags. For more information about tags, see Using tags to organize your Azure resources.
Access control
Resource Manager enables you to control who has access to specific actions for your organization. It natively
integrates role-based access control (RBAC ) into the management platform and applies that access control to all
services in your resource group.
There are two main concepts to understand when working with role-based access control:
Role definitions - describe a set of permissions and can be used in many assignments.
Role assignments - associate a definition with an identity (user or group) for a particular scope (subscription,
resource group, or resource). The assignment is inherited by lower scopes.
You can add users to pre-defined platform and resource-specific roles. For example, you can take advantage of the
pre-defined role called Reader that permits users to view resources but not change them. You add users in your
organization that need this type of access to the Reader role and apply the role to the subscription, resource group,
or resource.
Azure provides the following four platform roles:
1. Owner - can manage everything, including access
2. Contributor - can manage everything except access
3. Reader - can view everything, but can't make changes
4. User Access Administrator - can manage user access to Azure resources
Azure also provides several resource-specific roles. Some common ones are:
1. Virtual Machine Contributor - can manage virtual machines but not grant access to them, and can't manage the
virtual network or storage account to which they're connected
2. Network Contributor - can manage all network resources, but not grant access to them
3. Storage Account Contributor - Can manage storage accounts, but not grant access to them
4. SQL Server Contributor - Can manage SQL servers and databases, but not their security-related policies
5. Website Contributor - Can manage websites, but not the web plans to which they're connected
For the full list of roles and permitted actions, see RBAC: Built in Roles. For more information about role-based
access control, see Azure Role-based Access Control.
In some cases, you want to run code or script that accesses resources, but you don't want to run it under a user’s
credentials. Instead, you want to create an identity called a service principal for the application and assign the
appropriate role for the service principal. Resource Manager enables you to create credentials for the application
and programmatically authenticate the application. To learn about creating service principals, see one of following
topics:
Use Azure PowerShell to create a service principal to access resources
Use Azure CLI to create a service principal to access resources
Use portal to create Azure Active Directory application and service principal that can access resources
You can also explicitly lock critical resources to prevent users from deleting or modifying them. For more
information, see Lock resources with Azure Resource Manager.
Activity logs
Resource Manager logs all operations that create, modify, or delete a resource. You can use the activity logs to find
an error when troubleshooting or to monitor how a user in your organization modified a resource. You can filter
the logs by many different values including which user initiated the operation. For information about working with
the activity logs, see View activity logs to manage Azure resources.
Customized policies
Resource Manager enables you to create customized policies for managing your resources. The types of policies
you create can include diverse scenarios. You can enforce a naming convention on resources, limit which types and
instances of resources can be deployed, or limit which regions can host a type of resource. You can require a tag
value on resources to organize billing by departments. You create policies to help reduce costs and maintain
consistency in your subscription.
You define policies with JSON and then apply those policies either across your subscription or within a resource
group. Policies are different than role-based access control because they're applied to resource types.
The following example shows a policy that ensures tag consistency by specifying that all resources include a
costCenter tag.
{
"if": {
"not" : {
"field" : "tags",
"containsKey" : "costCenter"
}
},
"then" : {
"effect" : "deny"
}
}
There are many more types of policies you can create. For more information, see What is Azure Policy?.
SDKs
Azure SDKs are available for multiple languages and platforms. Each of these language implementations is
available through its ecosystem package manager and GitHub.
Here are the Open Source SDK repositories.
Azure SDK for .NET
Azure Management Libraries for Java
Azure SDK for Node.js
Azure SDK for PHP
Azure SDK for Python
Azure SDK for Ruby
For information about using these languages with your resources, see:
Azure for .NET developers
Azure for Java developers
Azure for Node.js developers
Azure for Python developers
NOTE
If the SDK doesn't provide the required functionality, you can also call to the Azure REST API directly.
Next steps
For a simple introduction to working with templates, see Export an Azure Resource Manager template from
existing resources.
For a more thorough walkthrough of creating a template, see Create your first Azure Resource Manager
template.
To understand the functions you can use in a template, see Template functions
For information about using Visual Studio with Resource Manager, see Creating and deploying Azure resource
groups through Visual Studio.
For information on migration of resources from Classic to ARM, see Migrate from Classic to Azure Resource
Manager
Here's a video demonstration of this overview:
Understand the structure and syntax of Azure
Resource Manager Templates
This article describes the structure of an Azure Resource Manager template. It presents the different sections of a
template and the properties that are available in those sections. The template consists of JSON and expressions
that you can use to construct values for your deployment. For a step-by-step tutorial on creating a template, see
Create your first Azure Resource Manager template.
Template format
In its simplest structure, a template has the following elements:
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "",
"parameters": { },
"variables": { },
"functions": { },
"resources": [ ],
"outputs": { }
}
ELEMENT NAME REQUIRED DESCRIPTION
$schema Yes Location of the JSON schema file that

describes the version of the template
language. Use the URL shown in the
preceding example.
contentVersion Yes Version of the template (such as

1.0.0.0). You can provide any value for
this element. Use this value to
document significant changes in your
template. When deploying resources
using the template, this value can be
used to make sure that the right
template is being used.
parameters No Values that are provided when

deployment is executed to customize
resource deployment.
variables No Values that are used as JSON fragments

in the template to simplify template
language expressions.
functions No User-defined functions that are available

within the template.
resources Yes Resource types that are deployed or

updated in a resource group.
ELEMENT NAME REQUIRED DESCRIPTION
outputs No Values that are returned after

deployment.
Each element has properties you can set. The following example shows the full syntax for a template:
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "",
"parameters": {
"<parameter-name>" : {
"type" : "<type-of-parameter-value>",
"defaultValue": "<default-value-of-parameter>",
"allowedValues": [ "<array-of-allowed-values>" ],
"minValue": <minimum-value-for-int>,
"maxValue": <maximum-value-for-int>,
"minLength": <minimum-length-for-string-or-array>,
"maxLength": <maximum-length-for-string-or-array-parameters>,
"metadata": {
"description": "<description-of-the parameter>"
}
}
},
"variables": {
"<variable-name>": "<variable-value>",
"<variable-object-name>": {
<variable-complex-type-value>
},
"<variable-object-name>": {
"copy": [
{
"name": "<name-of-array-property>",
"count": <number-of-iterations>,
"input": {
<properties-to-repeat>
}
}
]
},
"copy": [
{
"name": "<variable-array-name>",
"count": <number-of-iterations>,
"input": {
<properties-to-repeat>
}
}
]
},
"functions": [
{
"namespace": "<namespace-for-your-function>",
"members": {
"<function-name>": {
"parameters": [
{
"name": "<parameter-name>",
"type": "<type-of-parameter-value>"
}
],
"output": {
"type": "<type-of-output-value>",
"value": "<function-expression>"
}
}
}
}
}
],
"resources": [
{
"condition": "<boolean-value-whether-to-deploy>",
"apiVersion": "<api-version-of-resource>",
"type": "<resource-provider-namespace/resource-type-name>",
"name": "<name-of-the-resource>",
"location": "<location-of-resource>",
"tags": {
"<tag-name1>": "<tag-value1>",
"<tag-name2>": "<tag-value2>"
},
"comments": "<your-reference-notes>",
"copy": {
"name": "<name-of-copy-loop>",
"count": "<number-of-iterations>",
"mode": "<serial-or-parallel>",
"batchSize": "<number-to-deploy-serially>"
},
"dependsOn": [
"<array-of-related-resource-names>"
],
"properties": {
"<settings-for-the-resource>",
"copy": [
{
"name": ,
"count": ,
"input": {}
}
]
},
"resources": [
"<array-of-child-resources>"
]
}
],
"outputs": {
"<outputName>" : {
"type" : "<type-of-output-value>",
"value": "<output-value-expression>"
}
}
}
This article describes the sections of the template in greater detail.
Syntax
The basic syntax of the template is JSON. However, expressions and functions extend the JSON values available
within the template. Expressions are written within JSON string literals whose first and last characters are the
brackets: [ and ] , respectively. The value of the expression is evaluated when the template is deployed. While
written as a string literal, the result of evaluating the expression can be of a different JSON type, such as an array
or integer, depending on the actual expression. To have a literal string start with a bracket [ , but not have it
interpreted as an expression, add an extra bracket to start the string with [[ .
Typically, you use expressions with functions to perform operations for configuring the deployment. Just like in
JavaScript, function calls are formatted as functionName(arg1,arg2,arg3) . You reference properties by using the dot
and [index] operators.
The following example shows how to use several functions when constructing a value:
"variables": {
"storageName": "[concat(toLower(parameters('storageNamePrefix')), uniqueString(resourceGroup().id))]"
}
For the full list of template functions, see Azure Resource Manager template functions.
Parameters
In the parameters section of the template, you specify which values you can input when deploying the resources.
These parameter values enable you to customize the deployment by providing values that are tailored for a
particular environment (such as dev, test, and production). You don't have to provide parameters in your template,
but without parameters your template would always deploy the same resources with the same names, locations,
and properties.
The following example shows a simple parameter definition:
"parameters": {
"siteNamePrefix": {
"type": "string",
"metadata": {
"description": "The name prefix of the web app that you wish to create."
}
},
},
For information about defining parameters, see Parameters section of Azure Resource Manager templates.
Variables
In the variables section, you construct values that can be used throughout your template. You don't need to define
variables, but they often simplify your template by reducing complex expressions.
The following example shows a simple variable definition:
"variables": {
"webSiteName": "[concat(parameters('siteNamePrefix'), uniqueString(resourceGroup().id))]",
},
For information about defining variables, see Variables section of Azure Resource Manager templates.
Functions
Within your template, you can create your own functions. These functions are available for use in your template.
Typically, you define complicated expression that you don't want to repeat throughout your template. You create
the user-defined functions from expressions and functions that are supported in templates.
When defining a user function, there are some restrictions:
The function can't access variables.
The function can't access template parameters. That is, the parameters function is restricted to function
parameters.
The function can't call other user-defined functions.
The function can't use the reference function.
Parameters for the function can't have default values.
Your functions require a namespace value to avoid naming conflicts with template functions. The following
example shows a function that returns a storage account name:
"functions": [
{
"namespace": "contoso",
"members": {
"uniqueName": {
"parameters": [
{
"name": "namePrefix",
"type": "string"
}
],
"output": {
"type": "string",
"value": "[concat(toLower(parameters('namePrefix')), uniqueString(resourceGroup().id))]"
}
}
}
}
],
You call the function with:
"resources": [
{
"name": "[contoso.uniqueName(parameters('storageNamePrefix'))]",
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2016-01-01",
"sku": {
},
"kind": "Storage",
"location": "South Central US",
"tags": {},
"properties": {}
}
]
Resources
In the resources section, you define the resources that are deployed or updated. This section can get complicated
because you must understand the types you're deploying to provide the right values.
"resources": [
{
"apiVersion": "2016-08-01",
"name": "[variables('webSiteName')]",
"type": "Microsoft.Web/sites",
"location": "[resourceGroup().location]",
"properties": {
"serverFarmId": "/subscriptions/<subscription-id>/resourcegroups/<resource-group-
name>/providers/Microsoft.Web/serverFarms/<plan-name>"
}
}
],
For more information, see Resources section of Azure Resource Manager templates.
Outputs
In the Outputs section, you specify values that are returned from deployment. For example, you could return the
URI to access a deployed resource.
"outputs": {
"newHostName": {
"type": "string",
"value": "[reference(variables('webSiteName')).defaultHostName]"
}
}
For more information, see Outputs section of Azure Resource Manager templates.
Template limits
Limit the size of your template to 1 MB, and each parameter file to 64 KB. The 1-MB limit applies to the final state
of the template after it has been expanded with iterative resource definitions, and values for variables and
parameters.
You're also limited to:
256 parameters
256 variables
800 resources (including copy count)
64 output values
24,576 characters in a template expression
You can exceed some template limits by using a nested template. For more information, see Using linked templates
when deploying Azure resources. To reduce the number of parameters, variables, or outputs, you can combine
several values into an object. For more information, see Objects as parameters.
Next steps
To view complete templates for many different types of solutions, see the Azure Quickstart Templates.
For details about the functions you can use from within a template, see Azure Resource Manager Template
Functions.
To combine multiple templates during deployment, see Using linked templates with Azure Resource Manager.
For recommendations on creating Resource Manager templates that you can use across global Azure, Azure
sovereign clouds, and Azure Stack, see Develop Azure Resource Manager templates for cloud consistency.
Frequently asked questions for Application Gateway
General
Q. What is Application Gateway?
Azure Application Gateway is an Application Delivery Controller (ADC ) as a service, offering various layer 7 load
balancing capabilities for your applications. It offers highly available and scalable service, which is fully managed by
Azure.
Q. What features does Application Gateway support?
Application Gateway supports SSL offloading and end to end SSL, Web Application Firewall, cookie-based session
affinity, url path-based routing, multi site hosting, and others. For a full list of supported features, visit Introduction
to Application Gateway
Q. What is the difference between Application Gateway and Azure Load Balancer?
Application Gateway is a layer 7 load balancer, which means it works with web traffic only
(HTTP/HTTPS/WebSocket). It supports capabilities such as SSL termination, cookie-based session affinity, and
round robin for load balancing traffic. Load Balancer, load balances traffic at layer 4 (TCP/UDP ).
Q. What protocols does Application Gateway support?
Application Gateway supports HTTP, HTTPS, HTTP/2, and WebSocket.
Q. How does Application Gateway support HTTP/2?
HTTP/2 protocol support is available to clients connecting to Application Gateway listeners only. The
communication to backend server pools is over HTTP/1.1.
By default, HTTP/2 support is disabled. The following Azure PowerShell code snippet example shows how you can
enable it:
$gw = Get-AzureRmApplicationGateway -Name test -ResourceGroupName hm

$gw.EnableHttp2 = $true
Q. What resources are supported today as part of backend pool?

Backend pools can be composed of NICs, virtual machine scale sets, public IPs, internal IPs, fully qualified domain
names (FQDN ), and multi-tenant back-ends like Azure Web Apps. Application Gateway backend pool members
are not tied to an availability set. Members of backend pools can be across clusters, data centers, or outside of
Azure as long as they have IP connectivity.
Q. What regions is the service available in?
Application Gateway is available in all regions of global Azure. It is also available in Azure China and Azure
Government
Q. Is this a dedicated deployment for my subscription or is it shared across customers?
Application Gateway is a dedicated deployment in your virtual network.
Q. Is HTTP ->HTTPS redirection supported?
Redirection is supported. Visit Application Gateway redirect overview to learn more.
Q. In what order are listeners processed?
Listeners are processed in the order they are shown. For that reason if a basic listener matches an incoming
request it processes it first. Multi-site listeners should be configured before a basic listener to ensure traffic is
routed to the correct back-end.
Q. Where do I find Application Gateway’s IP and DNS?
When using a public IP address as an endpoint, this information can be found on the public IP address resource or
on the Overview page for the Application Gateway in the portal. For internal IP addresses, this can be found on the
Overview page.
Q. Does the IP or DNS change over the lifetime of the Application Gateway?
The VIP can change if the gateway is stopped and started by the customer. The DNS associated with Application
Gateway does not change over the lifecycle of the gateway. For this reason, it is recommended to use a CNAME
alias and point it to the DNS address of the Application Gateway.
Q. Does Application Gateway support static IP?
No, Application Gateway does not support static public IP addresses, but it does support static internal IPs.
Q. Does Application Gateway support multiple public IPs on the gateway?
Only one public IP address is supported on an Application Gateway.
Q. How big should I make my subnet for Application Gateway?
Application Gateway consumes one private IP address per instance, plus another private IP address if a private
frontend IP configuration is configured. Also, Azure reserves the first four and last IP address in each subnet for
internal usage. For example, if Application Gateway is set to three instances and no private frontend IP, then a /29
subnet size or greater is needed. In this case, Application Gateway uses three IP addresses. If you have three
instances and an IP address for the private frontend IP configuration, then a /28 subnet size or greater is needed as
four IP addresses are required.
Q. Does Application Gateway support x-forwarded-for headers?
Yes, Application Gateway inserts x-forwarded-for, x-forwarded-proto, and x-forwarded-port headers into the
request forwarded to the backend. The format for x-forwarded-for header is a comma-separated list of IP:Port. The
valid values for x-forwarded-proto are http or https. X-forwarded-port specifies the port at which the request
reached at the Application Gateway.
Q. How long does it take to deploy an Application Gateway? Does my Application Gateway still work
when being updated?
New Application Gateway deployments can take up to 20 minutes to provision. Changes to instance size/count are
not disruptive, and the gateway remains active during this time.
Configuration
Q. Is Application Gateway always deployed in a virtual network?
Yes, Application Gateway is always deployed in a virtual network subnet. This subnet can only contain Application
Gateways.
Q. Can Application Gateway talk to instances outside its virtual network?
Application Gateway can talk to instances outside of the virtual network that it is in as long as there is IP
connectivity. If you plan to use internal IPs as backend pool members, then it requires VNET Peering or VPN
Gateway.
Q. Can I deploy anything else in the Application Gateway subnet?
No, but you can deploy other application gateways in the subnet.
Q. Are Network Security Groups supported on the Application Gateway subnet?
Network Security Groups are supported on the Application Gateway subnet with the following restrictions:
Exceptions must be put in for incoming traffic on ports 65503-65534. This port-range is required for Azure
infrastructure communication. They are protected (locked down) by Azure certificates. Without proper
certificates, external entities, including the customers of those gateways, will not be able to initiate any
changes on those endpoints.
Outbound internet connectivity can't be blocked.
Traffic from the AzureLoadBalancer tag must be allowed.
Q. What are the limits on Application Gateway? Can I increase these limits?
Visit Application Gateway Limits to view the limits.
Q. Can I use Application Gateway for both external and internal traffic simultaneously?
Yes, Application Gateway supports having one internal IP and one external IP per Application Gateway.
Q. Is VNet peering supported?
Yes, VNet peering is supported and is beneficial for load balancing traffic in other virtual networks.
Q. Can I talk to on-premises servers when they are connected by ExpressRoute or VPN tunnels?
Yes, as long as traffic is allowed.
Q. Can I have one backend pool serving many applications on different ports?
Micro service architecture is supported. You would need multiple http settings configured to probe on different
ports.
Q. Do custom probes support wildcards/regex on response data?
Custom probes do not support wildcard or regex on response data.
Q. How are rules processed?
Rules are processed in the order they are configured. It is recommended that multi-site rules are configured before
basic rules to reduce the chance that traffic is routed to the inappropriate backend as the basic rule would match
traffic based on port prior to the multi-site rule being evaluated.
Q. What does the Host field for custom probes signify?
Host field specifies the name to send the probe to. Applicable only when multi-site is configured on Application
Gateway, otherwise use '127.0.0.1'. This value is different from VM host name and is in format
<protocol>://<host>:<port><path>.
Q. Can I whitelist Application Gateway access to a few source IPs?
This scenario can be done using NSGs on Application Gateway subnet. The following restrictions should be put on
the subnet in the listed order of priority:
Allow incoming traffic from source IP/IP range.
Allow incoming requests from all sources to ports 65503-65534 for backend health communication. This
port range is required for Azure infrastructure communication. They are protected (locked down) by Azure
certificates. Without proper certificates, external entities, including the customers of those gateways, will not
be able to initiate any changes on those endpoints.
Allow incoming Azure Load Balancer probes (AzureLoadBalancer tag) and inbound virtual network traffic
(VirtualNetwork tag) on the NSG.
Block all other incoming traffic with a Deny all rule.
Allow outbound traffic to the internet for all destinations.
Q. Can the same port be used for both public and private facing listeners?
No, this is not supported.
Performance
Q. How does Application Gateway support high availability and scalability?
Application Gateway supports high availability scenarios when you have two or more instances deployed. Azure
distributes these instances across update and fault domains to ensure that all instances do not fail at the same time.
Application Gateway supports scalability by adding multiple instances of the same gateway to share the load.
Q. How do I achieve DR scenario across data centers with Application Gateway?
Customers can use Traffic Manager to distribute traffic across multiple Application Gateways in different
datacenters.
Q. Is auto scaling supported?
No, but Application Gateway has a throughput metric that can be used to alert you when a threshold is reached.
Manually adding instances or changing size does not restart the gateway and does not impact existing traffic.
Q. Does manual scale up/down cause downtime?
There is no downtime, instances are distributed across upgrade domains and fault domains.
Q. Does application gateway support connection draining?
Yes. You can configure connection draining to change members within a backend pool without disruption. This will
allow existing connections to continue to be sent to their previous destination until either that connection is closed
or a configurable timeout expires. Note that connection draining only waits for current in-flight connections to
complete. Application Gateway is not aware of application session state.
Q. What are application gateway sizes?
Application Gateway is currently offered in three sizes: Small, Medium, and Large. Small instance sizes are
intended for development and testing scenarios.
You can create up to 50 application gateways per subscription, and each application gateway can have up to 10
instances each. Each application gateway can consist of 20 http listeners. For a complete list of application gateway
limits, see Application Gateway service limits.
The following table shows an average performance throughput for each application gateway instance with SSL
offload enabled:
AVERAGE BACK-END PAGE
RESPONSE SIZE SMALL MEDIUM LARGE
6KB 7.5 Mbps 13 Mbps 50 Mbps
100KB 35 Mbps 100 Mbps 200 Mbps
NOTE
These values are approximate values for an application gateway throughput. The actual throughput depends on various
environment details, such as average page size, location of back-end instances, and processing time to serve a page. For exact
performance numbers, you should run your own tests. These values are only provided for capacity planning guidance.
Q. Can I change instance size from medium to large without disruption?

Yes, Azure distributes instances across update and fault domains to ensure that all instances do not fail at the same
time. Application Gateway supports scaling by adding multiple instances of the same gateway to share the load.
SSL Configuration
Q. What certificates are supported on Application Gateway?
Self signed certs, CA certs, and wild-card certs are supported. EV certs are not supported.
Q. What are the current cipher suites supported by Application Gateway?
The following are the current cipher suites supported by application gateway. Visit: Configure SSL policy versions
and cipher suites on Application Gateway to learn how to customize SSL options.
Q. Does Application Gateway also support re-encryption of traffic to the backend?
Yes, Application Gateway supports SSL offload, and end to end SSL, which re-encrypts the traffic to the backend.
Q. Can I configure SSL policy to control SSL Protocol versions?
Yes, you can configure Application Gateway to deny TLS1.0, TLS1.1, and TLS1.2. SSL 2.0 and 3.0 are already
disabled by default and are not configurable.
Q. Can I configure cipher suites and policy order?
Yes, configuration of cipher suites is supported. When defining a custom policy, at least one of the following cipher
suites must be enabled. Application gateway uses SHA256 to for backend management.
Q. How many SSL certificates are supported?
Up to 20 SSL certificates are supported.
Q. How many authentication certificates for backend re-encryption are supported?
Up to 10 authentication certificates are supported with a default of 5.
Q. Does Application Gateway integrate with Azure Key Vault natively?
No, it is not integrated with Azure Key Vault.
Web Application Firewall (WAF) Configuration

Q. Does the WAF SKU offer all the features available with the Standard SKU?
Yes, WAF supports all the features in the Standard SKU.
Q. What is the CRS version Application Gateway supports?
Application Gateway supports CRS 2.2.9 and CRS 3.0.
Q. How do I monitor WAF?
WAF is monitored through diagnostic logging, more information on diagnostic logging can be found at
Diagnostics Logging and Metrics for Application Gateway
Q. Does detection mode block traffic?
No, detection mode only logs traffic, which triggered a WAF rule.
Q. How do I customize WAF rules?
Yes, WAF rules are customizable, for more information on how to customize them visit Customize WAF rule
groups and rules
Q. What rules are currently available?
WAF currently supports CRS 2.2.9 and 3.0, which provide baseline security against most of the top 10
vulnerabilities identified by the Open Web Application Security Project (OWASP ) found here OWASP top 10
Vulnerabilities
SQL injection protection
Cross site scripting protection
Common Web Attacks Protection such as command injection, HTTP request smuggling, HTTP response
splitting, and remote file inclusion attack
Protection against HTTP protocol violations
Protection against HTTP protocol anomalies such as missing host user-agent and accept headers
Prevention against bots, crawlers, and scanners
Detection of common application misconfigurations (that is, Apache, IIS, etc.)
Q. Does WAF also support DDoS prevention?
No, WAF does not provide DDoS prevention.
Diagnostics and Logging

Q. What types of logs are available with Application Gateway?
There are three logs available for Application Gateway. For more information on these logs and other diagnostic
capabilities, visit Backend health, diagnostics logs, and metrics for Application Gateway.
ApplicationGatewayAccessLog - The access log contains each request submitted to the Application Gateway
frontend. The data includes the caller's IP, URL requested, response latency, return code, bytes in and out. Access
log is collected every 300 seconds. This log contains one record per instance of Application Gateway.
ApplicationGatewayPerformanceLog - The performance log captures performance information on per
instance basis including total request served, throughput in bytes, total requests served, failed request count,
healthy and unhealthy back-end instance count.
ApplicationGatewayFirewallLog - The firewall log contains requests that are logged through either detection
or prevention mode of an application gateway that is configured with web application firewall.
Q. How do I know if my backend pool members are healthy?
You can use the PowerShell cmdlet Get-AzureRmApplicationGatewayBackendHealth or verify health through the portal
by visiting Application Gateway Diagnostics
Q. What is the retention policy on the diagnostics logs?
Diagnostic logs flow to the customers storage account and customers can set the retention policy based on their
preference. Diagnostic logs can also be sent to an Event Hub or Log Analytics. Visit Application Gateway
Diagnostics for more details.
Q. How do I get audit logs for Application Gateway?
Audit logs are available for Application Gateway. In the portal, click Activity Log in the menu blade of an
Application Gateway to access the audit log.
Q. Can I set alerts with Application Gateway?
Yes, Application Gateway does support alerts, alerts are configured off metrics. Application Gateway currently has
a metric of "throughput", which can be configured to alert. To learn more about alerts, visit Receive alert
notifications.
Q. Backend health returns unknown status, what could be causing this status?
The most common reason is access to the backend is being blocked by an NSG or custom DNS. Visit Backend
health, diagnostics logging, and metrics for Application Gateway to learn more.
Next Steps
To learn more about Application Gateway visit What is Azure Application Gateway?

App Gateway PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

App Gateway PDF

Transféré par

Droits d'auteur :

Formats disponibles

Contents

Application Gateway Documentation

Secure Sockets Layer (SSL) termination

Web application firewall

Websocket and HTTP/2 traffic

Create an application gateway

6. Click OK to create the virtual network and subnet.

Create backend servers

2. Run the following command to install IIS on the virtual machine:

Test the application gateway

Launch Azure Cloud Shell

Click Try It in the upper right corner of a code block.

Open Cloud Shell in your browser.

Create a resource group

New-AzureRmResourceGroup -Name myResourceGroupAG -Location eastus

Create network resources

Create backend servers

Create an application gateway

Create the backend pool

$address1 = Get-AzureRmNetworkInterface -ResourceGroupName myResourceGroupAG -Name myNic1

Create the listener and add a rule

Create the application gateway

Test the application gateway

Get-AzureRmPublicIPAddress -ResourceGroupName myResourceGroupAG -Name myAGPublicIPAddress

Remove-AzureRmResourceGroup -Name myResourceGroupAG

Open Azure Cloud Shell

Select Try It in the upper-right corner of a code block.

Open Cloud Shell in your browser.

Select the Cloud Shell button on the menu in the upper-right

Create a resource group

az group create --name myResourceGroupAG --location eastus

Create network resources

Create backend servers

for i in `seq 1 2`; do

Create the application gateway

Test the application gateway

az network public-ip show \

az group delete --name myResourceGroupAG

Open Azure Cloud Shell

Select Try It in the upper-right corner of a code block.

Open Cloud Shell in your browser.

Select the Cloud Shell button on the menu in the upper-right

Create a resource group

az group create --name myResourceGroupAG --location eastus

Create network resources

az network vnet create \

az network vnet subnet create \

az network public-ip create \

Create an application gateway

az network application-gateway create \

Create a Virtual Machine Scale Set

az vmss extension set \

Test the application gateway

az network public-ip show \

az group delete --name myResourceGroupAG --location eastus

Open Azure Cloud Shell

Select Try It in the upper-right corner of a code block.

Open Cloud Shell in your browser.

Select the Cloud Shell button on the menu in the upper-right

Create a resource group

az group create --name myResourceGroupAG --location eastus

Create network resources

az network vnet create \