Azure Front Door is one of the most used services in Azure and also one of the most interesting. This post will be the first of a series that will explore the features of the service and provide some architectures that can be deployed.

What is the Front Door

As per Microsoft, “Azure Front Door is Microsoft’s modern cloud Content Delivery Network (CDN) that provides fast, reliable and secure access between your users and your applications’ static and dynamic web content across the globe. Azure Front Door delivers your content using Microsoft’s global edge network with hundreds of global and local POPs distributed around the world close to both your enterprise and consumer end-users.” .

As an architect, I have seen that Azure Front Door can be used in multiple ways and to serve multiple solutions leveraging security, high availability and content delivery issues. In my experience, since the first launch of the service, I have seen it being used to enable multiple organizations to adopt cloud services and safely publish their applications publicly. 

Azure Front Door comes with a lot of benefits and we will drill deeper into the major ones later in this post. The major is the reach to Microsoft Edge and thus enabling the use of the Global Microsoft Network. Furthermore, the WAF capability enables organizations to adopt a secure environment to expose their services publicly and last but not least the ability (latest GA feature) to connect to private endpoints making the deployment totally private and exposing only the Front Door service to the public Internet.


Azure Front Door introduced two new tiers of the service with different characteristics. This way you can choose the tier you need and get the most cost-effective approach for your deployment.

Below a list of the features and supported Tiers.

Features and optimization Classic Standard Premium
Static file delivery Yes Yes Yes
Dynamic site deliver Yes Yes Yes
Custom domains Yes – CNAME based validation Yes – DNS TXT record based domain validation Yes – DNS TXT record based domain validation
Cache manage (purge, rules, and compression) Yes Yes Yes
Origin load balancing Yes Yes Yes
Path-based routing Yes Yes Yes
Rules engine Yes Yes Yes
Server variable No Yes Yes
Regular expression in rules engine No Yes Yes
Expanded metrics No Yes Yes
Advanced analytics/built- in reports No Yes Yes – includes WAF report
Raw logs – access logs and WAF logs Yes Yes Yes
Health probe log No Yes Yes
Custom Web Application Firewall (WAF) rules Yes Yes Yes
Microsoft managed rule set Yes – Only default rule set 1.1 or below No Yes
Bot protection No No Yes
Private link support No No Yes
Simplified price (base + usage) No Yes Yes
Azure Policy integration No Yes Yes
Azure Advisory integration No Yes Yes


Acceleration (Split TCP)

Going into some of the features of the service, one of the least mentioned is the connection acceleration through the use of Split TCP. As it can be seen in the diagram below the connectivity to Azure Front Door and eventually to the exposed application uses a less common pattern.

split tcp

After the request goes out from the consumer, a short TCP connection is established with the closest Edge point of the Front Door. From there a long TCP connection is established with the web application or any service exposed by the organisation. The long TCP connection is established through the Microsoft Global Network further taking advantage of the speed. Finally the Long TCP connection can be reused by other short ones and thus make the whole process faster.  The acceleration is achieved because the initial TCP connection take some roundtrips to be established but until the Microsoft Edge (close to the origin) while the long TCP connection although it takes the same amount of round trips to be established can be reused for further traffic.

In the case that a service is exposed from a local datacentre the long TCP connection will be established over the Internet as the endpoint is outside MS Global network.

For example (as can be seen above), a client from Athens will establish  the first connection to the Greek edge of the Azure Front Door and then a long connection will be established to the endpoint exposed in the enterprise region. This long TCP connection can be reused by further customers that use the Greek edge. 

A simple Architecture (multiple origins)

Starting to drill deeper into the Front Door the following architecture can serve as an example to explore the functionality of the service.

Azure front door

In the architecture shown above, a Front Door is configured to serve a number of origins that are in different regions and hosts. From  left to right the Front Door will serve an application on a VM, a web application that is hosted in 2 regions and a website that is hosted locally in a company’s data centre.

As the Front Door can send the traffic to origins that are exposed either by a DNS record or a public IP address there is no limit for the traffic to be in Azure. This feature enables organizations to use the Front Door as the entry point for services that they expose publicly and that they are in need of global reach.

The flow for the design above will be:

flow design

The above flow shows the main steps that need to be taken for a connection to reach the origin. 

Connecting to the private Link service


In most cases there is a need for increased security and the least exposure of public endpoints to the Internet. The latest introduced feature from Azure is the ability of the Front Door to connect to a private endpoint and in this way minimize the attack surface of an application.

azure front door_new

The design above shows this capability. Examining the architecture we see that the front door is connected through a private link to  the internal IP of a load balancer. This results in a number of benefits. Primarily there is no public endpoint used apart from the Front Door. Furthermore, the fact that a load balancer is used 

Coming up next we will discuss some of the features such as CDN, SSL and WAF capabilities.