Frequently asked questions for Azure Front Door

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):

  1. The comments section of this article.
  2. Azure Front Door UserVoice.
  3. 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 is a highly available and scalable service, which is fully 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 management, and others. For a full list of supported features, see Overview of Azure Front Door.

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 global 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 key scenarios why one should use Application Gateway behind Front Door are:

  • 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 cannot 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.

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 is not 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 basically specifying where the metadata for the resource group will be stored. Front Door resource itself is created as a global resource and the configuration is deployed globally to all edge locations.

Where are the edge locations for Azure Front Door?

For the complete list of Azure Front Door edge locations, see Azure Front Door edge 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. So, 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 impact other Front Door configurations.

Is HTTP->HTTPS redirection supported?

Yes. In fact, Azure Front Door supports host, path, and query string redirection as well as part of URL redirection. Learn more about URL redirection.

In what order are routing rules processed?

Routes for your Front Door are not 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?


New SKU Front Door Premium provides a more recommended way to lock down your application via Private Endpoint. Learn more about Private Endpoint

To lock down your application to accept traffic only from your specific Front Door, you will need to set up IP ACLs for your backend and then restrict the traffic on your backend to the specific value of the header 'X-Azure-FDID' sent by Front Door. These steps are detailed out as below:

  • Configure IP ACLing for your backends to accept traffic from Azure Front Door's backend IP address space and Azure's infrastructure services only. Refer the IP details below for ACLing your backend:


    Front Door's backend IP space may change later, however, we will ensure that before that happens, that we would have integrated with Azure IP Ranges and Service Tags. We recommend that you subscribe to Azure IP Ranges and Service Tags for any changes or updates.

  • Look for the Front Door ID value under the Overview section from Front Door portal page. You can then filter on the incoming header 'X-Azure-FDID' sent by Front Door to your backend with that value to ensure only your own specific Front Door instance is allowed (because the IP ranges above are shared with other Front Door instances of other customers).

  • Apply rule filtering in your backend web server to restrict traffic based on the resulting 'X-Azure-FDID' header value. Note that some services like Azure App Service provide this header based filtering capability without needing to change your application or host.

    Here's an example for Microsoft Internet Information Services (IIS):

    <?xml version="1.0" encoding="UTF-8"?>
                    <rule name="Filter_X-Azure-FDID" patternSyntax="Wildcard" stopProcessing="true">
                        <match url="*" />
                            <add input="{HTTP_X_AZURE_FDID}" pattern="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" negate="true" />
                        <action type="AbortRequest" />
  • Azure Front Door also supports additional service tags, AzureFrontDoor.Frontend and AzureFrontDoor.FirstParty, to integrate internally with other Azure services. See available service tags for more details on Azure Front Door service tags use cases.

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 do not 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 backend pools etc. are seamless and will cause zero downtime (if the new configuration is correct). Certificate updates are also atomic and will not cause any outage, unless switching from 'AFD Managed' to 'Use your own cert' or vice versa.


Can Azure Front Door load balance or route traffic within a virtual network?

Azure Front Door (AFD) requires a public IP or publicly resolvable DNS name to route traffic. So, the answer is no AFD directly cannot route within a virtual network, but using an Application Gateway or Azure Load Balancer in between will solve this scenario.

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 utilizes the same Azure edge sites when responding to requests.


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. 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.

TLS configuration

What TLS versions are supported by 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 is not yet supported.

What certificates are supported on Azure Front Door?

To enable the HTTPS protocol for securely delivering content on a Front Door custom domain, you can choose to use a certificate that is managed by Azure Front Door or use your own certificate. The Front Door managed option provisions a standard TLS/SSL certificate via Digicert and stored in Front Door's Key Vault. If you choose to use your own certificate, then you can onboard a certificate from a supported CA and can be a standard TLS, extended validation certificate, or even a wildcard certificate. Self-signed certificates are not supported. Learn how to enable HTTPS for a custom domain.

Does Front Door support autorotation of certificates?

For the Front Door managed certificate option, the certificates are autorotated by Front Door. If you are using a Front Door managed certificate and see that the certificate expiry date is less than 60 days away, file a support ticket.
For your own custom TLS/SSL certificate, set the secret version to ‘Latest’ in order for Azure Front Door to automatically rotate to the latest secret version uploaded to your Key Vault. It can take up to 24 hours for the new version of the certificate/secret to be deployed. If you configure the secret version to a specific version, you'll need to point the Front Door to the right certificate version in your Key Vault. Ensure that the service principal for Front Door still has access to the Key Vault. Refer to how to grant access to your key vault. The updated certificate rollout operation by Front Door won't cause any production down time provided the subject name or subject alternate name (SAN) for the certificate isn't changed.

What are the current cipher suites supported by Azure Front Door?

For TLS1.2 the following cipher suites are supported:



For Windows 10 and later versions, we recommend enabling one or both of the ECDHE cipher suites for better security. Windows 8.1, 8, and 7 aren't compatible with these ECDHE cipher suites. The DHE cipher suites have been provided for compatibility with those operating systems.

When using custom domains with TLS1.0/1.1 enabled the following cipher suites are supported:


Can I configure TLS policy to control TLS Protocol versions?

You can configure a minimum TLS version in Azure Front Door in the custom domain HTTPS settings via Azure portal or the Azure REST API. Currently, you can choose between 1.0 and 1.2.

Can I configure Front Door to only support specific cipher suites?

No, configuring Front Door for specific cipher suites is not supported. However, you can get your own custom TLS/SSL certificate from your Certificate Authority (say Verisign, Entrust, or Digicert) and have specific cipher suites marked on the certificate when you have it generated.

Does Front Door support OCSP stapling?

Yes, OCSP stapling is supported by default by Front Door and no configuration is required.

Does Azure Front Door also support re-encryption of traffic to the backend?

Yes, Azure Front Door supports TLS/SSL offload, and end to end TLS, which re-encrypts the traffic to the backend. In fact, since the connections to the backend happen over its public IP, it is recommended that you configure your Front Door to use HTTPS as the forwarding protocol.

Does Front Door support self-signed certificates on the backend for HTTPS connection?

No, self-signed certificates are not supported on Front Door and the restriction applies to both:

  • Backends: You cannot use self-signed certificates when you are forwarding the traffic as HTTPS or HTTPS health probes or filling the cache for from origin for routing rules with caching enabled.
  • Frontend: You cannot use self-signed certificates when using your own custom TLS/SSL certificate for enabling HTTPS on your custom domain.

Why is HTTPS traffic to my backend failing?

For having successful HTTPS connections to your backend whether for health probes or for forwarding requests, there could be two reasons why HTTPS traffic might fail:

  • Certificate subject name mismatch: For HTTPS connections, Front Door expects that your backend presents certificate from a valid CA with subject name(s) matching the backend hostname. As an example, if your backend hostname is set to and the certificate that your backend presents during the TLS handshake neither has nor *myapp-centralus* in the subject name, the Front Door will refuse the connection and result in an error.
    • Solution: While it is not recommended from a compliance standpoint, you can workaround this error by disabling certificate subject name check for your Front Door. This is present under Settings in Azure portal and under BackendPoolsSettings in the API.
  • Backend hosting certificate from invalid CA: Only certificates from valid Certificate Authorities can be used at the backend with Front Door. Certificates from internal CAs or self-signed certificates aren't allowed. The certificate must have a complete certificate chain with leaf and intermediate certificates, and root CA must be part of the Microsoft Trusted CA List.

Can I use client/mutual authentication with Azure Front Door?

No. Although Azure Front Door supports TLS 1.2, which introduced client/mutual authentication in RFC 5246, currently, Azure Front Door doesn't support client/mutual authentication.


Will I be billed for the Azure Front Door resources that are disabled?

Azure Front Door resources, like Front Door profiles, routing rules are not 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 Hub 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, click Activity Log in the menu blade 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 on metrics.

Next steps