This article answers common questions about Azure Front Door features and functionality. If you don't see the answer to your question, you can contact us through the following channels (in escalating order):
The comments section of this article.
Microsoft Support: To create a new support request, in the Azure portal, on the Help tab, select the Help + support button, and then select New support request.
What is Azure Front Door?
Azure Front Door is an Application Delivery Network (ADN) as a service, offering various layer 7 load-balancing capabilities for your applications. It provides dynamic site acceleration (DSA) along with global load balancing with near real-time failover. It's a highly available and scalable service, which is completed managed by Azure.
What features does Azure Front Door support?
Azure Front Door supports dynamic site acceleration (DSA), TLS/SSL offloading and end to end TLS, Web Application Firewall, cookie-based session affinity, url path-based routing, free certificates and multiple domain managements, and many other features. For a full list of supported features, see tier comparison.
What is the difference between Azure Front Door and Azure Application Gateway?
While both Front Door and Application Gateway are layer 7 (HTTP/HTTPS) load balancers, the primary difference is that Front Door is a nonregional service whereas Application Gateway is a regional service. While Front Door can load balance between your different scale units/clusters/stamp units across regions, Application Gateway allows you to load balance between your VMs/containers etc. that is within the scale unit.
When should we deploy an Application Gateway behind Front Door?
The following scenarios are where an Application Gateway behind Front Door gets used:
- Front Door can perform path-based load balancing only at the global level but if one wants to load balance traffic even further within their virtual network (VNET) then they should use Application Gateway.
- Since Front Door doesn't work at a VM/container level, so it can't do Connection Draining. However, Application Gateway allows you to do Connection Draining.
- With an Application Gateway behind Front Door, one can achieve 100% TLS/SSL offload and route only HTTP requests within their virtual network (VNET).
- Front Door and Application Gateway both support session affinity. While Front Door can direct subsequent traffic from a user session to the same cluster or backend in a given region, Application Gateway can direct affinitize the traffic to the same server within the cluster.
Can we deploy Azure Load Balancer behind Front Door?
Azure Front Door needs a public VIP or a publicly available DNS name to route the traffic to. Deploying an Azure Load Balancer behind Front Door is a common use case. If you're using Azure Front Door Premium, you can enable Private Link to connect to an internal load balancer. For more information, see enable Private Link with internal load balancer.
What protocols does Azure Front Door support?
Azure Front Door supports HTTP, HTTPS and HTTP/2.
How does Azure Front Door support HTTP/2?
HTTP/2 protocol support is available to clients connecting to Azure Front Door only. The communication to backends in the backend pool is over HTTP/1.1. HTTP/2 support is enabled by default.
What resources are supported today as part of backend pool?
Backend pools can be composed of Storage, Web App, Kubernetes instances, or any other custom hostname that has public connectivity. Azure Front Door requires that the backends are defined either via a public IP or a publicly resolvable DNS hostname. Members of backend pools can be across zones, regions, or even outside of Azure as long as they have public connectivity.
What regions is the service available in?
Azure Front Door is a global service and isn't tied to any specific Azure region. The only location you need to specify while creating a Front Door is the resource group location, which is specifying where the metadata for the resource group gets stored. The Front Door profile itself is created as a global resource and the configuration is deployed globally to all edge locations.
Where are Azure Front Door POPs (point-of-presences) located?
For the complete list of, see Azure Front Door POP locations.
Is Azure Front Door a dedicated deployment for my application or is it shared across customers?
Azure Front Door is a globally distributed multi-tenant service. The infrastructure for Front Door is shared across all its customers. However, by creating a Front Door profile, you define the specific configuration required for your application and no changes made to your Front Door can affect other Front Door configurations.
Is HTTP->HTTPS redirection supported?
Yes. Azure Front Door supports host, path, and query string redirection and part of URL redirection. For more information, see URL redirection.
In what order are routing rules processed?
Routes for your Front Door aren't ordered and a specific route is selected based on the best match. Learn more about How Front Door matches requests to a routing rule.
How do I lock down the access to my backend to only Azure Front Door?
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. For more information, see Secure traffic to Azure Front Door origins.
Can the anycast IP change over the lifetime of my Front Door?
The frontend anycast IP for your Front Door should typically not change and may remain static for the lifetime of the Front Door. However, there are no guarantees for the same. Kindly don't take any direct dependencies on the IP.
Does Azure Front Door support static or dedicated IPs?
No, Azure Front Door currently doesn't support static or dedicated frontend anycast IPs.
Does Azure Front Door support x-forwarded-for headers?
Yes, Azure Front Door supports the X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto headers. For X-Forwarded-For if the header was already present then Front Door appends the client socket IP to it. Else, it adds the header with the client socket IP as the value. For X-Forwarded-Host and X-Forwarded-Proto, the value is overridden.
Learn more about the Front Door supported HTTP headers.
How long does it take to deploy an Azure Front Door? Does my Front Door still work when being updated?
Most new Front Door creates and updates take about 3 to 20 minutes to deploy across all our edge location globally.
Most custom TLS/SSL certificate updates take from several minutes to an hour to be deployed globally.
Any updates to routes or origin groups/backend pools etc. are seamless and has zero downtime (if the new configuration is correct). Certificate updates are atomic, so there shouldn't be an outage.
Can Azure Front Door load balance or route traffic within a virtual network?
Azure Front Door Standard, Premium and (classic) tier requires a public IP or publicly resolvable DNS name to route traffic to backend resources. Azure resources such as Application Gateways or Azure Load Balancers can enable routing to resources within a virtual network. If you're using a Front Door Premium tier, you can enable Private Link to connect to origins behind an internal load balancer over a private endpoint. For more information, see Secure origins with Private Link.
How many origins and origin groups should I create?
An origin group represents a set of origins that are functionally able to serve the same kinds of requests. You should use a separate origin group for each distinct application or workload.
Within an origin group, create an origin for each distinct server or service instance that can serve requests. If your origin is itself a load balancer, such as an Azure Application Gateway, or gets hosted on a platform as a service (PaaS) offering that includes a load balancer, then the origin group may only contain a single origin. Internally, your origin handles failover and load distribution between origins that is invisible to Front Door.
For example, suppose you host an application on Azure App Service. The way that you configure Front Door depends on how many application instances you deploy:
- Single-region deployment: Create a single origin group. Within that origin group, create a single origin to represent the App Service app. Your App Service app might be configured to scale out across worker instances, but from Front Door's perspective there's a single origin.
- Multi-region active/passive deployment: Create a single origin group. Within that origin group, create an origin for each of the App Service apps. Configure each origin's priority to ensure that the primary application has a higher priority than the secondary application.
- Multi-region active/active deployment: Create a single origin group. Within that origin group, create an origin for each of the App Service apps. Configure each origin's priority to be the same. Configure each origin's weight to set the proportion of requests that should go to that origin.
For more information, see Origins and origin groups in Azure Front Door.
What are the various timeouts and limits for Azure Front Door?
Learn about all the documented timeouts and limits for Azure Front Door.
How long does it take for a rule to take effect after being added to the Front Door Rules Engine?
Most rules engine configuration updates complete under 20 minutes. You can expect the rule to take effect as soon as the update is completed.
Can I configure Azure CDN behind my Front Door profile or vice versa?
Azure Front Door and Azure CDN can't be configured together because both services utilize the same Azure edge sites when responding to requests.
Which network service tags does Front Door support?
Azure Front Door supports three service tags:
- The AzureFrontDoor.Backend service tag provides the list of IP addresses that Front Door uses to connect to your origins. You can use this service tag when you secure traffic to your origins.
- The AzureFrontDoor.Frontend service tag provides the list of IP addresses that clients use when connecting to Front Door. You can use the AzureFrontDoor.Frontend service tag when you’re controlling the outbound traffic that should be allowed to connect to services deployed behind Azure Front Door.
- The AzureFrontDoor.FirstParty service tag is used internally within Azure.
For more information on Azure Front Door service tags use cases, see available service tags.
What is the HTTP keep-alive timeout for Azure Front Door?
The HTTP keep-alive timeout for Azure Front Door is 90 seconds. Which means that if a client doesn't send any data for 90 seconds, the connection is closed. This timeout value can't be configured.
How does Azure Front Door support high availability and scalability?
Azure Front Door is a globally distributed multi-tenant platform with huge volumes of capacity to cater to your application's scalability needs. Traffic is delivered from the edge of Microsoft's global network, Front Door provides global load-balancing capability that allows you to fail over your entire application or even individual microservices across regions or different clouds.
Why aren't ranged responses from my origin getting cached?
Ensure that your origin sends the
Content-Range response header, and that the value matches the actual length of the response body.
For more information, see Delivery of large files.
How does Front Door handle ‘domain fronting’ behavior?
Beginning November 8, 2022, all newly created Azure Front Door (Standard, Premium and Classic tier) or Azure CDN Standard from Microsoft (classic) resources will block any HTTP request that exhibits domain fronting behavior. Requests where the host header in HTTP/HTTPS requests that doesn't match the original TLS SNI extension used during the TLS negotiation gets blocked.
If you wish to block domain fronting for an existing Azure Front Door or Azure CDN Standard from Microsoft (classic) resources, create a support request and provide your subscription and resource information. Once domain fronting gets blocked, Azure Front Door and Azure CDN Standard from Microsoft (classic) resources block any HTTP/HTTPS requests that exhibit this behavior.
When Front Door blocks a request due to a mismatch:
- The client receives an HTTP "421 Misdirected Request" error code response.
- Azure Front Door logs the block in the diagnostic logs under the "Error Info" property with the value SSLMismatchedSNI.
For more information about domain fronting, see Securing our approach to domain fronting within Azure.
What TLS versions are supported with Azure Front Door?
All Front Door profiles created after September 2019 use TLS 1.2 as the default minimum.
Front Door supports TLS versions 1.0, 1.1 and 1.2. TLS 1.3 isn't yet supported. For more information, see Azure Front Door end-to-end TLS.
Do I get billed for the Azure Front Door resources that are disabled?
Azure Front Door resources, like Front Door profiles, routing rules aren't billed in disabled. WAF policies and rules are billed even if disabled.
Diagnostics and logging
What types of metrics and logs are available with Azure Front Door?
For information on logs and other diagnostic capabilities, see Monitoring metrics and logs for Front Door.
What is the retention policy on the diagnostics logs?
Diagnostic logs flow to the customers storage account and customers can set the retention policy based on their preference. Diagnostic logs can also be sent to an Event Hubs or Azure Monitor logs. For more information, see Azure Front Door Diagnostics.
How do I get audit logs for Azure Front Door?
Audit logs are available for Azure Front Door. In the portal, select Activity Log in the menu page of your Front Door to access the audit log.
Can I set alerts with Azure Front Door?
Yes, Azure Front Door does support alerts. Alerts are configured based on metrics or logs.
For information about how to create alerts for Azure Front Door Standard and Premium, see configure alerts.
- Learn how to create a Front Door.
- Learn about Azure Front Door architecture.