Configure App Service with Application Gateway
Application gateway allows you to have an App Service app or other multi-tenant service as a backend pool member. In this article, you learn to configure an App Service app with Application Gateway. The configuration for Application Gateway will differ depending on how App Service will be accessed:
- The first option makes use of a custom domain on both Application Gateway and the App Service in the backend.
- The second option is to have Application Gateway access App Service using its default domain, suffixed as ".azurewebsites.net".
This configuration is recommended for production-grade scenarios and meets the practice of not changing the host name in the request flow. You are required to have a custom domain (and associated certificate) available to avoid having to rely on the default ".azurewebsites" domain.
By associating the same domain name to both Application Gateway and App Service in the backend pool, the request flow doesn't need to override the host name. The backend web application will see the original host as was used by the client.
In this article you'll learn how to:
- Configure DNS
- Add App Service as backend pool to the Application Gateway
- Configure HTTP Settings for the connection to App Service
- Configure an HTTP Listener
- Configure a Request Routing Rule
Application Gateway: Create an application gateway without a backend pool target. For more information, see Quickstart: Direct web traffic with Azure Application Gateway - Azure portal
App Service: If you don't have an existing App Service, see App Service documentation.
A custom domain name and associated certificate (signed by a well known authority), stored in Key Vault. For more information on how to store certificates in Key Vault, see Tutorial: Import a certificate in Azure Key Vault
In the context of this scenario, DNS is relevant in two places:
- The DNS name, which the user or client is using towards Application Gateway and what is shown in a browser
- The DNS name, which Application Gateway is internally using to access the App Service in the backend
Route the user or client to Application Gateway using the custom domain. Set up DNS using a CNAME alias pointed to the DNS for Application Gateway. The Application Gateway DNS address is shown on the overview page of the associated Public IP address. Alternatively create an A record pointing to the IP address directly. (For Application Gateway V1 the VIP can change if you stop and start the service, which makes this option undesired.)
App Service should be configured so it accepts traffic from Application Gateway using the custom domain name as the incoming host. For more information on how to map a custom domain to the App Service, see Tutorial: Map an existing custom DNS name to Azure App Service To verify the domain, App Service only requires adding a TXT record. No change is required on CNAME or A-records. The DNS configuration for the custom domain will remain directed towards Application Gateway.
To accept connections to App Service over HTTPS, configure its TLS binding. For more information, see Secure a custom DNS name with a TLS/SSL binding in Azure App Service Configure App Service to pull the certificate for the custom domain from Azure Key Vault.
Add App service as backend pool
In the Azure portal, select your Application Gateway.
Under Backend pools, select the backend pool.
Under Target type, select App Services.
Under Target select your App Service.
The dropdown only populates those app services which are in the same subscription as your Application Gateway. If you want to use an app service which is in a different subscription than the one in which the Application Gateway is, then instead of choosing App Services in the Targets dropdown, choose IP address or hostname option and enter the hostname (example.azurewebsites.net) of the app service.
Edit HTTP settings for App Service
An HTTP Setting is required that instructs Application Gateway to access the App Service backend using the custom domain name. The HTTP Setting will by default use the default health probe. While default health probes will forward requests with the hostname in which traffic is received, the health probes will utilize 127.0.0.1 as the hostname to the Backend Pool since no hostname has explicitly been defined. For this reason, we need to create a custom health probe that is configured with the correct custom domain name as its host name.
We will connect to the backend using HTTPS.
- Under HTTP Settings, select an existing HTTP setting or add a new one.
- When creating a new HTTP Setting, give it a name
- Select HTTPS as the desired backend protocol using port 443
- If the certificate is signed by a well known authority, select "Yes" for "User well known CA certificate". Alternatively Add authentication/trusted root certificates of backend servers
- Make sure to set "Override with new host name" to "No"
- Select the custom HTTPS health probe in the dropdown for "Custom probe".
Configure an HTTP listener
To accept traffic we need to configure a Listener. For more info on this see Application Gateway listener configuration.
- Open the "Listeners" section and choose "Add listener" or click an existing one to edit
- For a new listener: give it a name
- Under "Frontend IP", select the IP address to listen on
- Under "Port", select 443
- Under "Protocol", select "HTTPS"
- Under "Choose a certificate", select "Choose a certificate from Key Vault". For more information, see Using Key Vault where you find more information on how to assign a managed identity and provide it with rights to your Key Vault.
- Give the certificate a name
- Select the Managed Identity
- Select the Key Vault from where to get the certificate
- Select the certificate
- Under "Listener Type", select "Basic"
- Click "Add" to add the listener
Configure request routing rule
Using the earlier configured Backend Pool and the HTTP Settings, the request routing rule can be set up to take traffic from a listener and route it to the Backend Pool using the HTTP Settings. For this, make sure you have an HTTP or HTTPS listener available that is not already bound to an existing routing rule.
- Under "Rules", click to add a new "Request routing rule"
- Provide the rule with a name
- Select an HTTP or HTTPS listener that is not bound yet to an existing routing rule
- Under "Backend targets", choose the Backend Pool in which App Service has been configured
- Configure the HTTP settings with which Application Gateway should connect to the App Service backend
- Select "Add" to save this configuration
Before we do so, make sure that the backend health shows as healthy:
Open the "Backend health" section and ensure the "Status" column indicates the combination for HTTP Setting and Backend Pool shows as "Healthy".
Now browse to the web application using the custom domain which you associated with both Application Gateway and the App Service in the backend.
The web apps deployed in these examples use public IP addresses that can be accessed directly from the Internet. This helps with troubleshooting when you're learning about a new feature and trying new things. But if you intend to deploy a feature into production, you'll want to add more restrictions. Consider the following options:
- Configure Access restriction rules based on service endpoints. This allows you to lock down inbound access to the app making sure the source address is from Application Gateway.
- Use Azure App Service static IP restrictions. For example, you can restrict the web app so that it only receives traffic from the application gateway. Use the app service IP restriction feature to list the application gateway VIP as the only address with access.