Azure Front Door with App Service

Azure Front Door service was recently released.

Azure Front Door is an interesting service combining the capabilities of:

The pricing model also is also interesting as it is based on consumption (per outbound data transfer) as opposed to compute unit as for appliances.

Azure Front Door is meant to route public traffic to public endpoints. It doesn’t integrate with Azure Virtual Networks.

In this article, I wanted to show how to connect it to a Web App deployed on an Azure App Service. For simplicity’s sake, we do not activate the WAF in here.

As usual, code is in GitHub.


Here is the solution we are going to ground the conversation around:


This is a typical reverse proxy use case.

We can easily deploy the solution:

Deploy button

The ARM template has 4 parameters:

Parameter Mandatory Description
frontDoorHostPrefix X The DNS prefix for the default front door domain name (in the diagram, that is the 'X' variable)
webAppName X The name of the web app, also DNS prefix for its default domain name (in the diagram, the 'Y' variable)
webAppSKU Sku of the web app (actually App Service): Free, Shared, Basic or Standard. Default to Standard because life is too short.
workerSize Size of the App Service: 0 (small), 1(medium), 2(large). Default to 0 because we won't deploy a real web app.

As usual, to author the ARM template, we looked at the online documentation, reverse engineered a deployment made from the portal, checked out some Azure Quickstart Templates and use our imagination.

Blocking App Service

A typical concern in a reverse proxy scenario is to block traffic coming directly to the back-end service, in this case the Web App.

It is possible to do that. In the FAQ, we can find the CIDR for Front Door service:

So we can easily configure this in the Web App firewall.

Now it is important to note that this IP range is for all Front Door instances. Azure Front Door is a multi-tenant global service. So, we do not get an IP range for our instance of Front Door.

This means the rule we put in place discriminate against traffic coming for elsewhere than Azure Front Door (e.g. a browser) but not against traffic coming from another Azure Front Door instance.

If that is a concern, we would need to layer another access control. For instance, we could enforce authentication on the Web App (not done in this deployment).

Testing the deployment

Let’s test the deployment.

We can see there are three resources deployed by the ARM template:

Resource Group

(Yes, we are in the UK today)

The App Service Plan is akin to a server farm while the App Service is akin to an application running on that farm.

We can see the Front Door service isn’t in a specific region but is a global service (with a %99.99 SLA).

Let’s open the Front Door resource.

Front Door

In the top-right corner we find a URL to the main front-end. If we browse on that URL we get the following page:

Front Door page

This is the App Service default page, since we didn’t deploy any code for the Web App.

It might take a few seconds for the service to be up and running.

Let’s now open the App Service resource.

App Service

We also have the URL of the web app in the top right corner. If we browse to that page though, we are denied access:

App Service page

This is because, as mentioned in the previous section, we blocked requests not coming from Azure Front Door.


Something that isn’t possible to do today is to easily redirect HTTP traffic to HTTPS.

What we did though is to enforce that the traffic between Front Door and App Service is always in HTTPS, regardless of the incoming request on Azure Front Door.


We looked at a simple deployment of Azure Front Door in front of Azure App Service.

This deployment allows us to front an App Service with Azure Front Door. That gives us the following possibilities:

In future articles, we’ll dive deeper into the inner works of Azure Front Door and consider more complex scenarios.

3 responses

  1. Frank 2019-06-24 at 13:48

    I’ve managed to do HTTP to HTTP redirection using a redirect rule.

    Accept protocol: HTTP only Route type: redirect Redirect protocol: HTTPS only

  2. Mahesh Panchal 2020-07-19 at 01:29

    Hello Vincent

    It is a great post but I have one query about web app restrictions. Added ip of azure frontdoor in app restriction may change later ?

  3. Vincent-Philippe Lauzon 2020-07-20 at 14:26

    Hi Manesh,

    That is a good point. Yes, they may change. For that reason you should automate those IP assignment / testing connection. Hopefully this will be integrated in a service tag down the line.

Leave a comment