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|
|Regular expression in rules engine||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|
|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.
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.
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:
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.
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.