Frequently asked questions for 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.

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.

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.

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.

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.

Azure Front Door supports HTTP, HTTPS and 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.

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.

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.

For the complete list of, see Azure Front Door POP locations.

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.

Yes. Azure Front Door supports host, path, and query string redirection and part of URL redirection. For more information, see URL redirection.

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.

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.

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.

No, Azure Front Door currently doesn't support static or dedicated frontend anycast IPs.

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.

Most new Front Door creates and updates take about 3 to 20 minutes to deploy across all our edge location 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.

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.

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.

Learn about all the documented timeouts and limits for Azure Front Door.

Most rules engine configuration updates complete under 20 minutes. You can expect the rule to take effect as soon as the update is completed.

Azure Front Door and Azure CDN can't be configured together because both services utilize the same Azure edge sites when responding to requests.

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.

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.

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.

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.

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.

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.

Azure Front Door resources, like Front Door profiles, routing rules aren't billed in disabled. WAF policies and rules are billed even if disabled.

For information on logs and other diagnostic capabilities, see Monitoring metrics and logs for Front Door.

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.

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.

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.

Next steps

• Learn how to create a Front Door.
• Learn about Azure Front Door architecture.