This article outlines one of the many ways to implement Azure Front Door, emphasising best practices and key considerations to ensure a successful deployment.
As is known, Azure Front Door operates at Layer 7, which is the Application Layer. It means that it facilitates tasks such as global load balancing, integrated security with a WAF, URL routing, app acceleration, custom domain & SSL management, and access control.
In this simple implementation, I aim to demonstrate how the Azure Front Door service can be used to load balance requests to your website (in this example, a static page), provide security with the integrated Web Application Firewall (WAF) service, and apply failover capabilities.
This design uses two Azure Blob Storage containers, which contain the same HTML file ( the famous 🙂 index.html) to simulate static web workloads in two regions. The Azure Front Door Premium tier acts as the gateway and has a web application firewall policy (WAF) to protect against common attacks. The storage accounts are not accessible via the internet and connect through Azure Private Link. In addition, the configuration includes one endpoint with a route to an origin group that points to each storage account. Each origin requests Private Link access, and health probes check the index.html file (page) in the storage accounts.
I will provide a brief breakdown of the configuration and components that we used.
Route
Route Settings determine how requests are handled when they match specific routing rules. In my demo, I used one Route (default-route – I didn’t rename it) that routes traffic to the origin group (default-origin-group, which I also didn’t rename).
Origin Group
The Origin Group directs traffic to backend services and monitors the health of those services.
Now, by editing the origin group, you can see two origin host names, one for each storage account that stores the index.html. A health probe is also configured for the path where the index.html file is stored (I have created a container named “web” and uploaded the index.html). Finally, I have set the load balancing configuration so that an origin is considered healthy if three out of the last four probes are successful. Traffic will only then be directed to the second healthy origin.
Reference: Origin group
Origin Host Name
The origin group includes two Storage Accounts (Azure Blobs), one located in West Europe and the other in North Europe. The important setting to note in this context is that the “Enable private link service” setting is checked. This means that the connection between Azure Front Door and Azure storage accounts is secure, and the traffic between them is not exposed to the public internet.
After checking the “Enable private link service” setting, you have to go to each storage account and approve the Private Endopoint creation. This can be done from Security + networking – networking – Private endpoints
At the beginning of this article, I also mentioned that I used Web Application Firewall policies to secure my endpoint hostname. To be honest, in this section, I simply associated my domain with the WAF policy, using only the managed rules provided by default. These rules are based on the Open Worldwide Application Security Project (OWASP).
Testing the configuration
At the end of the article, I’ve included an interesting section that will give you an idea of what all the above provides to you and your web resources, and why choosing to use Azure Front Door Premium with WAF policies is essential, making it easier for you to chill out.
Access the Analytics section, Reports and Security reports
Reports
To access the AFD reports, navigate to the AFD’s left-hand side blade and choose Analytics > Reports.
Traffic by domain
This report highlights the domains in the profile, showing data transferred from the AFD edge to clients, total requests, and counts of 3XX, 4XX, and 5XX response codes for each domain.
Usage
This report includes data transfer and bandwidth from the AFD edge to clients and from the origin to the AFD edge, along with request counts, total latency, and HTTP status code trends.
Traffic by location
This report displays a map of requests and usage by top countries, along with a directional view.
Cache
This report shows the cache hit ratio by request count and includes trends for hit and miss requests. The data only counts cacheable requests and is available when caching is enabled.
Top url
This report lists the 50 most popular assets that people are asking for.
Top referrer
This report highlights the top 50 origins getting traffic to AFD.
Top user agent
This report lists the top 50 user agents that generate traffic.
Security Reports
This report provides a detailed examination of WAF rule patterns from various angles.
To access the AFD Security reports, navigate to the AFD’s left-hand side blade and choose Analytics > Security reports.
Let’s see how it works now!
To test if the failover capability works and can switch successfully between working and non-working sources, I blocked public access to the storage accounts. The video below shows that this setup works perfectly.
The video below demonstrates how Web Application Firewall policies prevent SQL injection attempts.
Related links