Azure Front Door is a relatively new offering from Microsoft Azure. It is the Azure Reverse Proxy, WAF solution and offers many similar options to competitors like CloudFlare, MaxCDN and Fastly. Front Door is designed specifically for Web Sites and provides a suite of features to improve performance and security of Azure web architectures.
Some of the features offered by Front Door include:
I like to keep my service subscriptions to a minimum and Front Door is a great way to add web protection to a web site all under one roof.
For this configuration I went with 2 identical web app services. This looks like the simplest type of setup, and with default settings, super quick to setup. I went with the S1 service size after a few tries with the free sizes which gave me a lot of grief. The S1 also allowed me to take advantage of ‘Always On’ service feature.
I stuck with the default settings on the app service and uploaded some simple html and css files to create a simple static site. The 2 web app services were named as follows:
In order to support ‘Apex domains’, an ‘A’ record domain like ‘pageboy.ca’ I needed to host the nameservers in Azure. This Microsoft Guide explains the details. Needless to say, my domain registrar was unable to support CName flattening allowing an ‘A’ record to reference another domain.
To support CName flattening I created an Azure DNS service. Make sure it has the name of the domain that it will be hosting. Creating the DNS Zone will instantiate 4 nameservers, I have the following DNS Zone with nameservers:
In my Domain Registrar DNS settings for the pageboy.ca domain I update the nameservers to the list above and published my DNS records. It took about an hour for this change to propagate. I would occasionally clear my DNS cache with an ipconfig /flushdns and run nslookup to check the primary nameserver for my domain.
In this response to nslookup you can see that the primary nameserver is coming back as ns1-05.azure-dns.com so the records have been successfully updated.
In the Azure Portal add the Front Door service to the resource group with the Web App services. Front Door Configuration is done using the Front Door Designer, a sort of wizard style UI.
Front Door has to be referenced through a CName. Unlike Application Gateway that exposes a public IP, Front created the subdomain “pageboy.azurefd.net”. In order to add Front End Hosts, I had to add DNS records. The Apex record can be added with the name “@”. Azure allows you to select an Azure resource to point it to instead of an IP address - this is the CName flattening in action.
Once the DNS records were added and propagated I was able to proceed with adding the FrontEnd hosts to Front Door. To start, I’ve kept HTTPS out of the equation as well as keeping the WAF disabled.
One thing to note regarding HTTPS is that Azure can be setup to manage your SSL certificates automatically. HOWEVER, this can only be setup for sub-domains not for Apex domains. In the case of Apex domains you have to supply and manage the certificate yourself.
The web app services will service the back end pool. To set those up I added a backend pool with the following settings.
Each of the web apps uses index.html as the home page. This file is also used by the health probe to determine if the end point can receive requests. HTTP or HTTPS? This setting is on my list of outstanding questions, I don’t really see the point of HTTPS unless the backend only allows HTTPS. There is additional configuration to manage the load balancing logic.
The latency sensitivity can be used to route requests to the least busy app service in the pool. Leaving it set to zero routes to the fastest backend apparently, but I don’t trust that I understand this description. If I have the latency sensitivity set to 100 does it only send to that service if it responds faster than 100 ms? What if no services respond faster than 100ms, is that when round robin kicks in? In which case what is the point of applying a number to this setting?
Front Door allows you to route traffic to specific backend services if needed, thus, a routing rule must be configured even if you just want all traffic to be handled by all backend services.
For this setup I have the routing rule accepting both HTTP and HTTPS from the front end, forwarding traffic as HTTP to the backend services and so terminating the SSL. Patterns to match allows for routing traffic by path to specific back ends. Maybe you have a server specified to handle all media so you will then configure Front Door to send all media requests to that backend. With routing rule in place, I know have a simple Front Door setup ready to provide the benefits of a WAF and a reverse proxy.