Introduction
With the statement “Scalable and secure entry point for fast delivery of your global applications”, Azure Front Door (Service) saw the lights of dawn! The features it promises to bring to the table?
- SSL offload and application acceleration at the edge close to end users
- Global HTTP load balancing with instant failover
- Actionable insights about your users and back ends
- Application firewall and DDoS protection
- Central control plane for traffic orchestration
My first thought was… Does this fill the gap where I’m currently leveraging CloudFlare for my personal deployments? So today’s post will be to see what the process of creating the service looks like in real life!
Let’s take it for a spin!
After browsing through the marketplace, we select the “Azure Front Door” and press the button to create one. Here I must say that the configuration flow here is a pleasant surprise. First we enter the “basics”…
Next up we can directly configure our Azure Front Door Service. Step 1) Add the front end host(s)
So let’s create one for the preview environment of VMchooser!
Next up… Step 2! Who would have thought that after step 1, it would be step 2… 😉 Anyhow, here we’ll be adding our back-end pool.
For this I can directly select my app service.
As part of the backend pool.
Now on to step 3) … the routing rules.
Where in the “Advanced”, mode, I enabled the caching mode.
And now we have all our three steps done!
Let’s validate and let the deployment start to create the service.
And we’re off…
It’s being deployed.
Where the portal will show that the service is in a “Creating” state.
In meantime… we can see that the “Front Door designer” is the same view as we had during the creation.
And after about 5 and a half minutes, the deployment finishes.
And there it is!
Quick & Dirty Performance Test
Having it online is already a nice thing. Now let’s see what it means in terms of performance? For this I did a quick & dirty performance tests between three scenario’s ;
- Scenario A) App Service with CloudFlare in front of it
- Scenario B) App Service without anything in front of it
- Scenario C) App Service with the Azure Front Door in front of it
- Test One
- Test Two – As I was a bit puzzled by the first result, I did another one to see if the trend would be validated.
- Test One
Now what can we see here?
- Both CloudFlare & Azure Front Door reduce the latency of the responses.
- Using the Azure Front Door service almost doubles the ability of the # requests per second.
(At this time, I have no info to support why this is the case.)
Closing Thoughts
At the start the Azure Front Door service was a bit “vague” too me. Having looked into it, in a very simplistic (and partially incorrect) summary, I would say that it’s the combination of Azure Traffic Manager + CDN + Azure Application Gateway. When looking towards the process, it is VERY easy to setup and put in front of any service. So to link back to the initial thought of mind (“What is the gap with CloudFlare in my deployments?”), then I must say this is surely the case. This makes me really happy to see that Azure now has a service that fills this gap for me!
Karim Vaes 
Get-AzureRMFrontDoorFirewallPolicy I am getting an error that I never had a policy.
https://docs.microsoft.com/en-us/powershell/module/azurerm.frontdoor/New-AzureRmFrontDoorFireWallPolicy?view=azurermps-6.12.0
I guess I am missing a module or something. Would you mind sharing the way using powershell
HI Karim,
I’m struggling to get up an running with FrontDoor. my azurefd.net address works, but I keep getting an error with the custom domain. I keep getting an error: Our services aren’t available right now. We’re working to restore all services as soon as possible. Please check back soon.
0tEdHXAAAAAADUxvBayGtQLDTjRthnz9XTE9OMjFFREdFMDMyMQBFZGdl
Any ideas why this is happening?
I have posted the full question here: https://stackoverflow.com/questions/54312954/azure-frontdoor-configured-site-is-returning-services-not-available
Am I correct that you are experiencing this on your custom domain and not on your azurefd.net domain? If so, check your routing rules. You need to have both your frontend hosts selected. This is a bit of an odd visualization in the portal imho… Though click on it, and select all your frontend hosts (custom dns).
In essence, the error is there to state that front-end cannot reach your backend. This is typically either your backend that isn’t responding to the request (check your hostname), or that it is not processing requests due to the routing rules (as described above).
Hi Karim, nice article! I’ve done a test deploying Azure Front door for Azure Storage and tested the Latency with and without AFD. Here is the script if anyone want to test it as well.
the URL has to be change to reflect the file uploaded. The larger the file and clearer the difference would be.
AFD URL example: https://example.azurefd.net/example/example.jpg
Storage URL example: https://example.blob.core.windows.net/example/example.jpg
for i in {1..50}; do echo -n “Run # $i :: “; curl -w ‘Return Code: %{http_code}; Bytes received: %{size_download}; Response Time: %{time_total}\n’ https://example.blob.core.windows.net/example/example.jpg -m 2 -o /dev/null -s; done|tee /dev/tty|awk ‘{ sum += $NF; n++ } END { if (n > 0) print “Average Resp time =”,sum / n; }’
Thanks to Sharad Agrawal for the script!