Azure Front Door with App ServiceSolution ·
Azure Front Door service was recently released.
Azure Front Door is an interesting service combining the capabilities of:
- Reverse Proxy (SSL Termination, URL based routing, URL rewrite & session affinity)
- Web Application Firewall (WAF)
- Accelerated Global routing
- Global Load Balancing between geo-distributed backend
- Some bits of Content Delivery Network (CDN, in the form of caching requests)
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:
The ARM template has 4 parameters:
|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:
- IPv4 - 22.214.171.124/16
- IPv6 - 2a01:111:2050::/44
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:
(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.
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:
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.
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:
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:
- Accelerate traffic
- Implement WAF (not done in this article)
- Add App Service deployments in multiple regions
- Cache elements at Azure Front Door level, akin to a CDN
In future articles, we’ll dive deeper into the inner works of Azure Front Door and consider more complex scenarios.