Considerations when using private endpoint for communication between Azure Application Gateway and Azure App Services.

An App Service has a public internet facing endpoint. An Application Gateway can communicate with an app service over a service endpoint which allows traffic from a specific subnet within an Azure Virtual Network to which the gateway is deployed and blocks everything else. Enabling the service endpoint in that subnet and setting an access restriction on the app service ensures that the communication is private and secure.

The above configuration can be achieved using various tools such as CLI, portal and SDK.  A sample command would like this:

az webapp config access-restriction add --resource-group myRG --name myWebApp --rule-name AppGwSubnet --priority 200 --subnet mySubNetName --vnet-name myVnetName

The service endpoint helps to tag all the traffic leaving the subnet towards the app service to be tagged with the specific subnet id.

A similar effect can be achieved with an alternative that uses a private endpoint but there are a few things we need to establish first. We need to ensure that the application gateway can DNS resolve the private IP address in the backend pool and override the hostname in the http settings.

The Gateway caches the DNS lookup results, so if we use FQDNs and rely on the DNS lookup to get the private ip address, then we may need to restart the Application Gateway if the DNS update or link to Azure private DNS zone was done after the backend pool. The application gateway can be restarted by starting and stopping the instance such as with the commands shown below.

az network application-gateway stop --resource-group myRG --name myAppGw

az network application-gateway start --resource-group myRG --name myAppGw

Since it is customary for the resources to be succinctly described with an IaC code for deployment, the following section illustrates how to do that.