Front Door
The presented resiliency recommendations in this guidance include Front Door and associated Front Door settings.
Summary of Recommendations
The below table shows the list of resiliency recommendations for Front Door and associated resources.
Recommendations Details
AFD-1 - Avoid combining Traffic Manager and Front Door
Category: Networking
Impact: High
Guidance
For most solutions, we recommend to use either Front Door or Traffic Manager, but not both. Azure Traffic Manager is a DNS-based load balancer. It sends traffic directly to your origin’s endpoints. In contrast, Azure Front Door terminates connections at points of presence (PoPs) near to the client and establishes separate long-lived connections to the origins. The products work differently and are intended for different use cases.
If you need content caching and delivery (CDN), TLS termination, advanced routing capabilities, or a web application firewall (WAF), consider using Front Door. For simple global load balancing with direct connections from your client to your endpoints, consider using Traffic Manager.
However, as part of a complex architecture that requires high availability, you can put an Azure Traffic Manager in front of an Azure Front Door. In the unlikely event that Azure Front Door is unavailable, Azure Traffic Manager can then route traffic to an alternative destination, such as Azure Application Gateway or a partner content delivery network (CDN).
Don’t put Azure Traffic Manager behind Azure Front Door. Azure Traffic Managers should always be in front of Azure Front Door.
Resources
- Azure Load Balancing Options
- Azure Traffic Manager
- Azure Front Door
- Mission-critical global content delivery
Resource Graph Query
// Azure Resource Graph Query
// Avoid combining Traffic Manager and Front Door
resources
| where type == "microsoft.network/trafficmanagerprofiles"
| mvexpand(properties.endpoints)
| extend endpoint=tostring(properties_endpoints.properties.target)
| project name, trafficmanager=id, matchname=endpoint, tags
| join (
resources
| where type =~ "microsoft.cdn/profiles/afdendpoints"
| extend matchname= tostring(properties.hostName)
| extend splitid=split(id, "/")
| extend frontdoorid=tolower(strcat_array(array_slice(splitid, 0, 8), "/"))
| project name, id, matchname, frontdoorid, type
| union
(cdnresources
| where type =~ "Microsoft.Cdn/Profiles/CustomDomains"
| extend matchname= tostring(properties.hostName)
| extend splitid=split(id, "/")
| extend frontdoorid=tolower(strcat_array(array_slice(splitid, 0, 8), "/"))
| project name, id, matchname, frontdoorid, type)
)
on matchname
| project
recommendationId = "afd-1",
name=split(trafficmanager, "/")[-1],
id=trafficmanager,
tags,
param1=strcat("hostname:", matchname),
param2=strcat("frontdoorid:", frontdoorid)
AFD-2 - Restrict traffic to your origins
Category: Access & Security
Impact: High
Guidance
Front Door’s features work best when traffic only flows through Front Door. You should configure your origin to block traffic that hasn’t been sent through Front Door.
Resources
Resource Graph Query
// under-development
AFD-3 - Use the latest API version and SDK version
Category: Networking
Impact: Medium
Guidance
When you work with Front Door by using APIs, ARM templates, Bicep, or Azure SDKs, it’s important to use the latest available API or SDK version. API and SDK updates occur when new functionality is available, and also contain important security patches and bug fixes.
Resources
Resource Graph Query
// under-development
AFD-4 - Configure logs
Category: Monitoring
Impact: Medium
Guidance
Front Door tracks extensive telemetry about every request. When you enable caching, your origin servers might not receive every request, so it’s important that you use the Front Door logs to understand how your solution is running and responding to your clients.
Resources
Resource Graph Query
// under-development
AFD-5 - Use end-to-end TLS
Category: Security
Impact: High
Guidance
Front Door terminates TCP and TLS connections from clients. It then establishes new connections from each point of presence (PoP) to the origin. It’s a good practice to secure each of these connections with TLS, even for origins that are hosted in Azure. This approach ensures that your data is always encrypted during transit.
Resources
Resource Graph Query
// Azure Resource Graph Query
// Use end-to-end TLS
cdnresources
| where type == "microsoft.cdn/profiles/afdendpoints/routes"
| extend forwardingProtocol=tostring(properties.forwardingProtocol),supportedProtocols=properties.supportedProtocols
| project id,name,forwardingProtocol,supportedProtocols,tags
| where forwardingProtocol !~ "httpsonly" or supportedProtocols has "http"
| project recommendationId= "afd-5", name,id,tags,param1=strcat("forwardingProtocol:",forwardingProtocol),param2=strcat("supportedProtocols:",supportedProtocols)
AFD-6 - Use HTTP to HTTPS redirection
Category: Access & Security
Impact: High
Guidance
It’s a good practice for clients to use HTTPS to connect to your service. However, sometimes you need to accept HTTP requests to allow for older clients or clients who might not understand the best practice.
You can configure Front Door to automatically redirect HTTP requests to use the HTTPS protocol. You should enable the Redirect all traffic to use HTTPS setting on your route.
Resources
Resource Graph Query
// Azure Resource Graph Query
// Use HTTP to HTTPS redirection
cdnresources
| where type == "microsoft.cdn/profiles/afdendpoints/routes"
| extend httpsRedirect=tostring(properties.httpsRedirect)
| project id,name,httpsRedirect,tags
| where httpsRedirect !~ "enabled"
| project recommendationId= "afd-6", name,id,tags,param1=strcat("httpsRedirect:",httpsRedirect)
AFD-7 - Use managed TLS certificates
Category: Access & Security
Impact: High
Guidance
When Front Door manages your TLS certificates, it reduces your operational costs, and helps you to avoid costly outages caused by forgetting to renew a certificate. Front Door automatically issues and rotates the managed TLS certificates.
Resources
Resource Graph Query
// under-development
AFD-8 - Use latest version for customer-managed certificates
Category: Access & Security
Impact: Medium
Guidance
If you decide to use your own TLS certificates, then consider setting the Key Vault certificate version to ‘Latest’. By using ‘Latest’, you avoid having to reconfigure Front Door to use new versions of your certificate and waiting for the certificate to be deployed throughout Front Door’s environments.
Resources
Resource Graph Query
// under-development
AFD-9 - Use the same domain name on Front Door and your origin
Category: Networking
Impact: Medium
Guidance
Front Door can rewrite the Host header of incoming requests. This feature can be helpful when you manage a set of customer-facing custom domain names that route to a single origin. This feature can also help when you want to avoid configuring custom domain names in Front Door and at your origin. However, when you rewrite the Host header, request cookies and URL redirections might break. In particular, when you use platforms like Azure App Service, features like session affinity and authentication and authorization might not work correctly.
Before you rewrite the Host header of your requests, carefully consider whether your application is going to work correctly.
Resources
Resource Graph Query
// under-development
AFD-10 - Enable the WAF
Category: Access & Security
Impact: Medium
Guidance
For internet-facing applications, we recommend you enable the Front Door web application firewall (WAF) and configure it to use managed rules. When you use a WAF and Microsoft-managed rules, your application is protected from a wide range of attacks.
Resources
Resource Graph Query
// under-development
// Azure Resource Graph Query
// AFD-10 - Enable the WAF
resources
| where type =~ "microsoft.cdn/profiles" and sku has "AzureFrontDoor"
| project name, cdnprofileid=tolower(id), tostring(tags), resourceGroup, subscriptionId,skuname=tostring(sku.name)
| join kind= fullouter (
cdnresources
| where type == "microsoft.cdn/profiles/securitypolicies"
| extend wafpolicyid=tostring(properties['parameters']['wafPolicy']['id'])
| extend splitid=split(id, "/")
| extend cdnprofileid=tolower(strcat_array(array_slice(splitid, 0, 8), "/"))
| project secpolname=name, cdnprofileid, wafpolicyid
)
on cdnprofileid
| project name, cdnprofileid, secpolname, wafpolicyid,skuname
| join kind = fullouter (
resources
| where type == "microsoft.network/frontdoorwebapplicationfirewallpolicies"
| extend
managedrulesenabled=iff(tostring(properties.managedRules.managedRuleSets) != "[]", true, false),
enabledState = tostring(properties.policySettings.enabledState)
| project afdwafname=name, managedrulesenabled, wafpolicyid=id, enabledState, tostring(tags)
)
on wafpolicyid
| where name != ""
| summarize
associatedsecuritypolicies=countif(secpolname != ""),
wafswithmanagedrules=countif(managedrulesenabled == 1)
by name, id=cdnprofileid, tags,skuname
| where associatedsecuritypolicies == 0 or wafswithmanagedrules == 0
| project
recommendationId = "afd-10",
name,
id,
todynamic(tags),
param1 = strcat("associatedsecuritypolicies:", associatedsecuritypolicies),
param2 = strcat("wafswithmanagedrules:", wafswithmanagedrules),
param3 = strcat("skuname:",skuname)
AFD-11 - Disable health probes when there is only one origin in an origin group
Category: Availability
Impact: Low
Guidance
Front Door’s health probes are designed to detect situations where an origin is unavailable or unhealthy. When a health probe detects a problem with an origin, Front Door can be configured to send traffic to another origin in the origin group.
If you only have a single origin, Front Door always routes traffic to that origin even if its health probe reports an unhealthy status. The status of the health probe doesn’t do anything to change Front Door’s behavior. In this scenario, health probes don’t provide a benefit and you should disable them to reduce the traffic on your origin.
Resources
Resource Graph Query
// Azure Resource Graph Query
// AFD-11 - Disable health probes when there is only one origin in an origin group
cdnresources
| where type =~ "microsoft.cdn/profiles/origingroups"
| extend healthprobe=tostring(properties.healthProbeSettings)
| project origingroupname=name, id, tags, resourceGroup, subscriptionId, healthprobe
| join (
cdnresources
| where type =~ "microsoft.cdn/profiles/origingroups/Origins"
| extend origingroupname = tostring(properties.originGroupName)
)
on origingroupname
| summarize origincount=count(), enabledhealthprobecount=countif(healthprobe != "") by origingroupname, id, tostring(tags), resourceGroup, subscriptionId
| where origincount == 1 and enabledhealthprobecount != 0
| project
recommendationId = "afd-11",
name=origingroupname,
id,
todynamic(tags),
param1 = strcat("origincount:", origincount),
param2 = strcat("enabledhealthprobecount:", enabledhealthprobecount)
AFD-12 - Select good health probe endpoints
Category: Availability
Impact: Medium
Guidance
Consider the location where you tell Front Door’s health probe to monitor. It’s usually a good idea to monitor a webpage or location that you specifically design for health monitoring. Your application logic can consider the status of all of the critical components required to serve production traffic including application servers, databases, and caches. That way, if any component fails, Front Door can route your traffic to another instance of your service
Resources
Resource Graph Query
// under-development
AFD-13 - Use HEAD health probes
Category: System Efficiency
Impact: Medium
Guidance
Health probes can use either the GET or HEAD HTTP method. It’s a good practice to use the HEAD method for health probes, which reduces the amount of traffic load on your origins.
Resources
Resource Graph Query
// under-development
AFD-14 - Use geo-filtering in Azure Front Door
Category: Access & Security
Impact: Medium
Guidance
By default, Azure Front Door will respond to all user requests regardless of the location where the request is coming from. In some scenarios, you may want to restrict the access to your web application by countries/regions. The Web application firewall (WAF) service in Front Door enables you to define a policy using custom access rules for a specific path on your endpoint to either allow or block access from specified countries/regions.
A WAF policy contains a set of custom rules. The rule consists of match conditions, an action, and a priority. In a match condition, you define a match variable, operator, and match value. For a geo filtering rule, a match variable is either RemoteAddr or SocketAddr. RemoteAddr is the original client IP that is usually sent via X-Forwarded-For request header. SocketAddr is the source IP address WAF sees. If your user is behind a proxy, SocketAddr is often the proxy server address. The operator in the case of this geo filtering rule is GeoMatch, and the value is a two letter country/region code of interest. “ZZ” country code or “Unknown” country captures IP addresses that are not yet mapped to a country in our dataset. You may add ZZ to your match condition to avoid false positives. You can combine a GeoMatch condition and a REQUEST_URI string match condition to create a path-based geo-filtering rule.
Resources
Resource Graph Query
// under-development
AFD-15 - Secure your Origin with Private Link in Azure Front Door
Category: Access & Security
Impact: Medium
Guidance
Azure Private Link enables you to access Azure PaaS services and services hosted in Azure over a private endpoint in your virtual network. Traffic between your virtual network and the service goes over the Microsoft backbone network, eliminating exposure to the public Internet.
Azure Front Door Premium can connect to your origin using Private Link. Your origin can be hosted in a virtual network or hosted as a PaaS service such as Azure App Service or Azure Storage. Private Link removes the need for your origin to be accessed publicly.
Resources
Resource Graph Query
// under-development