Frequently asked questions for Azure Front Door

Azure Front Door is a cloud-based service that delivers your applications faster and more reliably. It uses layer 7 load balancing to distribute traffic across multiple regions and endpoints. It also offers dynamic site acceleration (DSA) to optimize web performance and near real-time failover to ensure high availability. Azure Front Door is a fully managed service, so you don't have to worry about scaling or maintenance.

Azure Front Door is a service that offers many benefits for your web applications, such as dynamic site acceleration (DSA), which improves the performance and user experience of your sites. Azure Front Door also handles TLS/SSL offloading and end to end TLS, which enhances the security and encryption of your web traffic. Additionally, Azure Front Door provides Web Application Firewall, cookie-based session affinity, url path-based routing, free certificates and multiple domain managements, and more. To learn more about the features and capabilities of Azure Front Door, see tier comparison.

Azure Front Door and Azure Application Gateway are both load balancers for HTTP/HTTPS traffic, but they have different scopes. Front Door is a global service that can distribute requests across regions, while Application Gateway is a regional service that can balance requests within a region. Azure Front Door works with scale units, clusters or stamp units, while Azure Application Gateway works with VMs, containers or other resources in the same scale unit.

Application Gateway behind Front Door is useful in these situations:

• You want to balance the traffic not only globally, but also within your virtual network. Front Door can only do path-based load balancing at the global level, but Application Gateway can do it within your virtual network.
• You need Connection Draining, which Front Door doesn't support. Application Gateway can enable Connection Draining for your VMs or containers.
• You want to offload all the TLS/SSL processing and use only HTTP requests in your virtual network. Application Gateway behind Front Door can achieve this setup.
• You want to use session affinity at both the regional and the server level. Front Door can send the traffic from a user session to the same backend in a region, but Application Gateway can send it to the same server in the backend.

Chaining two CDNs is generally not a recommended approach, it would work but comes with the following cons

1. CDN’s last mile acceleration utilizes keeping the connection stream with the origin, and finding optimal path to the origin to achieve best results. Chaining two CDNs together typically negates some of the benefits from last mile acceleration.
2. Security controls become less effective at the second CDN. Any client IP based ACLing will not work at the second CDN as the second CDN will see the first CDN’s exit node as Client IPs. Content payload will still be inspected.
3. Many organizations can’t handle the complexity of troubleshooting two CDNs being chained and when a problem it becomes hard to figure out which CDN is having the issue.

To use Azure Front Door, you must have a public VIP or a DNS name that is publicly accessible. Azure Front Door uses the public IP to route the traffic to your origin. A common scenario is to deploy an Azure Load Balancer behind Front Door. You can also use Private Link with Azure Front Door Premium 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.

Azure Front Door supports HTTP/2 protocol for client connections. However, the backend pool communication uses HTTP/1.1 protocol. HTTP/2 support is on by default.

You can use different types of origins for Azure Front Door, such as:

• Storage (Azure Blob, Classic, Static websites)
• Cloud service
• App Service
• Static Web App
• API Management
• Application Gateway
• Public IP address
• Azure Spring Apps
• Container Instances
• Container Apps
• Any custom hostname with public access.

The origin must have a public IP or a DNS hostname that can be resolved publicly. You can mix and match backends from different zones, regions, or even outside of Azure, as long as they're publicly accessible.

Azure Front Door isn't limited to any Azure region, but operates globally. The only location you have to choose when you create a Front Door is the location of the resource group, which determines where the resource group's metadata get stored. The Front Door profile is a global resource and its configuration is distributed to all edge locations worldwide.

For the complete list of points of presence (POPs) that provide global load balancing and content delivery for Azure Front Door, see Azure Front Door POP locations. This list is updated regularly as new POPs are added or removed. You can also use the Azure Resource Manager API to query the current list of POPs programmatically.

Azure Front Door is a service that distributes your application globally across multiple regions. It uses a common infrastructure that gets shared by all its customers, but you can customize your own Front Door profile to configure your application's specific requirements. Other customers' configurations can't affect your Front Door configuration, which is isolated from theirs.

You can redirect host, path, and query string components of a URL with Azure Front Door. To learn how to configure URL redirection, refer to URL redirection.

Front Door doesn't sort the routes for your web application. Instead, it chooses the route that best fits the request. To find out how Front Door matches requests to routes, see How Front Door matches requests to a routing rule.

To ensure optimal performance of Front Door's features, you should only allow traffic that comes from Azure Front Door to reach your origin. As a result, unauthorized or malicious requests encounter the security and routing policies of Front Door and are denied access. To learn how to secure your origin, see Secure traffic to Azure Front Door origins.

The IP address of your Front Door's frontend anycast is fixed and might not change as long as you use the Front Door. However, the fixed IP address of your Front Door's frontend anycast isn't a guarantee. Avoid relying on the IP directly.

Azure Front Door is a dynamic service that routes traffic to the best available backend. It doesn't offer static or dedicated frontend anycast IPs at this time.

Yes. Refer to the MatchedRulesSetName property under Access Logs.

Yes. For more information, see Microsoft response to DDoS attacks against HTTP/2.

Azure Front Door supports the X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto headers. These headers help Front Door identify the original client IP and protocol. If X-Forwarded-For is already present, Front Door adds the client socket IP to the end of the list. Otherwise, it creates the header with the client socket IP as the value. For X-Forwarded-Host and X-Forwarded-Proto, Front Door replaces the existing values with its own.

For more information, see Front Door supported HTTP headers.

The deployment time for new Front Door configurations varies depending on the type of change. Typically, it takes between 3 and 20 minutes for the changes to propagate to all our edge locations worldwide.

Updates to routes or origin groups/backend pools are seamless and don't cause any downtime (assuming the new configuration is correct). Certificate updates are also done atomically, so there's no risk of outage.

No. Currently, Azure Front Door only supports HTTP/1.1 from the edge to the origin. For gRPC to work, HTTP/2 is required.

• Front Door Standard/Premium and Azure CDN profiles can be moved between resource groups or subscriptions without any downtime. To execute the move, follow these instructions.
• Front Door Classic doesn't support move between resource groups or subscriptions. You can instead migrate the Classic profile to Standard/Premium and then execute the move.
• If the customer has WAF associated to the Front Door Standard/Premium, then move operation will fail. Customer has to disassociate WAF policies first, move and then associate.

To use Azure Front Door Standard, Premium or (classic) tier, you need a public IP or a DNS name that can be resolved publicly. This requirement of a public IP or a DNS name that can be resolved publicly allows Azure Front Door to route traffic to your backend resources. You can use Azure resources like Application Gateways or Azure Load Balancers to route traffic to resources in a virtual network. If you use Front Door Premium tier, you can use Private Link to connect to origins behind an internal load balancer with a private endpoint. For more information, see Secure origins with Private Link.

An origin group is a collection of origins that can handle similar types of requests. You need a different origin group for each application or workload that is different.

In an origin group, you create an origin for every server or service that can serve requests. If your origin has a load balancer, like Azure Application Gateway, or is hosted on a PaaS that has a load balancer, then the origin group only has one origin. Your origin takes care of failover and load balancing between origins that Front Door doesn't see.

For example, if you host an application on Azure App Service, how you set up Front Door depends on how many application instances you have:

• Single-region deployment: Make one origin group. In that origin group, make one origin for the App Service app. Your App Service app might scale out across workers, but Front Door sees one origin.
• Multi-region active/passive deployment: Make one origin group. In that origin group, make an origin for each App Service app. Set each origin's priority so that the main application has a higher priority than the backup application.
• Multi-region active/active deployment: Make one origin group. In that origin group, make an origin for each App Service app. Set each origin's priority to be the same. Set each origin's weight to control how many requests go to that origin.

To learn more, see Origins and origin groups in Azure Front Door.

Azure Front Door is a service that provides fast and reliable web delivery for your applications. It offers features such as caching, load balancing, security, and routing. However, you need to be aware of some timeouts and limits that apply to Azure Front Door. These timeouts and limits include the maximum request size, the maximum response size, the maximum header size, the maximum number of headers, the maximum number of rules, and the maximum number of origin groups. You can find the detailed information about these timeouts and limits in the Azure Front Door documentation.

The configuration updates for most rule sets are done in less than 20 minutes. The rule will be applied right after the update is finished.

Azure Front Door and Azure CDN are two services that provide fast and reliable web delivery for your applications. However, they aren't compatible with each other, because they share the same network of Azure edge sites to deliver content to your users. This shared network causes conflicts between their routing and caching policies. Therefore, you have to choose either Azure Front Door or Azure CDN for your application, depending on your performance and security requirements.

The fact that both profiles would use the same Azure edge sites to handle incoming requests causes this limitation that prevents you from nesting one Azure Front Door profile behind another. This setup would cause routing conflicts and performance issues. Therefore, you should ensure that your Azure Front Door profiles are independent and not chained together, if you need to use multiple profiles for your applications.

Azure Front Door uses three service tags to manage the traffic between your clients and your origins:

• The AzureFrontDoor.Backend service tag contains the IP addresses that Front Door uses to access your origins. You can apply this service tag when you configure security for your origins.
• The AzureFrontDoor.Frontend service tag contains the IP addresses that clients use to reach Front Door. You can apply the AzureFrontDoor.Frontend service tag when you want to control the outbound traffic that can connect to services behind Azure Front Door.
• The AzureFrontDoor.FirstParty service tag is reserved for a select group of Microsoft services hosted on Azure Front Door.

For more information on Azure Front Door service tags scenarios, see available service tags.

Azure Front Door has a 5-second timeout for receiving headers from client. The connection is terminated if the client doesn't send headers within 5 seconds to Azure Front Door after establishing TCP/TLS connection. You can't configure this timeout value.

Azure Front Door has a 90-second HTTP keep-alive timeout. The connection is terminated if the client doesn't send data for 90 seconds, which is the HTTP keep-alive timeout for Azure Front Door. You can't configure this timeout value.

You can't use the same domains for more than one Front Door endpoint, because Front Door needs to distinguish the route (protocol + host + path combination) for each request. If you have duplicate routes across different endpoints, Azure Front Door can't process the requests correctly.

At this time, we don't offer the option to move domains from one endpoint to another without any interruption in service. You need to plan for some downtime if you want to migrate your domains to a different endpoint.

Azure Front Door Private Link feature is region agnostic and will work even if you choose a region that is different from the region where your origin is located. In such cases, to ensure lower latency, you should always pick an Azure region closest to your origin when choosing to enable Azure Front Door Private Link endpoint. We are in the process of enabling support for more regions. Once a new region is supported, you can follow these instructions to gradually shift traffic to the new region.

Azure Front Door is a platform that distributes traffic across the world and can scale up to meet your application's demands. It uses Microsoft's global network edge to deliver global load-balancing capability that lets you switch your entire application or specific microservices to different regions or clouds if there was failure.

To avoid errors when delivering large files, make sure your origin server includes the Content-Range header in the response, and that the header value matches the actual size of the response body.

You can find more details on how to configure your origin and Front Door for large file delivery in Delivery of large files.

Domain fronting is a network technique that enables an attacker to conceal the actual destination of a malicious request by using a different domain name in the TLS handshake and the HTTP host header.

Azure Front Door (Standard, Premium and Classic tier) or Azure CDN Standard from Microsoft (classic) resources created after November 8, 2022, have domain fronting blocking enabled. Rather than blocking a request with mismatched SNI and host headers, we permit the discrepancy if the two domains belong to the same subscription and are included in the routes/routing rules. Domain fronting blocking enforcement will start on January 22, 2024, for all existing domains. The enforcement may require up to two weeks to propagate to all regions.

When Front Door blocks a request due to a mismatch:

• The client receives an HTTP 421 Misdirected Request error code response.
• Azure Front Door records 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 and Prohibiting domain fronting on Azure Front Door and Azure CDN Standard from Microsoft (classic).

Front Door uses TLS 1.2 as the minimum version for all profiles created after September 2019.

You can choose to use TLS 1.0, 1.1, 1.2 or 1.3 with Azure Front Door. To learn more, read the Azure Front Door end-to-end TLS article.

Azure Front Door is a service that provides fast and secure web delivery. It allows you to define how your web traffic is routed and optimized across multiple regions and endpoints. Azure Front Door resources, such as Front Door profiles and routing rules, are only charged when they're enabled. However, web application firewall (WAF) policies and rules are charged regardless of their status. Even if you disable a WAF policy or rule, it still incurs costs for you.

No.

No.

AFD does not support dynamic compression for content greater than 8 MB. However, if the content has been already compressed by the origin, Front Door supports serving static compressed content over 8 MB as long as range request is supported and chunked transfer encoding is not enabled.

No.

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

You can store diagnostic logs in their own storage account and choose how long to keep them. Alternatively, diagnostic logs can be sent to Event Hubs or Azure Monitor logs. For more information, see Azure Front Door diagnostics.

To access the audit logs of Azure Front Door, you need to visit the portal. Select your Front Door from the menu page and select on Activity Log. The Activity Log provides you with the records of your Azure Front Door’s operations.

You can set up alerts for Azure Front Door based on metrics or logs. By doing so, you can monitor the performance and health of your front-end hosts.

To learn how to create alerts for Azure Front Door Standard and Premium, see configure alerts.

Next steps

• Learn how to create an Azure Front Door profile.
• Learn about the Azure Front Door architecture.