Azure Front Door: Global load balancer & CDN

Learn how Azure Front Door combines global HTTP routing, CDN caching and application protection, and how origin groups support application availability.

Updated 8 September 2026

What Azure Front Door does

Azure Front Door provides a global entry point for web applications. It combines delivery and routing capabilities, including caching, TLS and integration with a web application firewall. Origins can be in Azure or elsewhere, so the public entry point and the application’s hosting location do not have to be the same.

For example, a business with application deployments in two regions could use one public hostname. The delivery layer decides where to forward eligible requests while visitors continue using that stable address.

Origin routing and health probes

Front Door uses origin health monitoring to support routing decisions. Its rules engine can also change request handling at the edge. These functions sit between the browser and the application, so a routing change can affect the site without a new application release.

A meaningful health endpoint should represent readiness to serve the intended traffic. A process that responds to a simple ping might still be unable to reach the database needed by a checkout request.

Security, private origins and rules

Front Door combines global delivery with a web application firewall integration, network-level DDoS protection and configurable routing rules. Rules can modify request handling without changing the application itself. Private Link supports private origin connectivity in supported configurations. Feature availability differs by tier, so a Standard deployment should not be assumed to include Premium capabilities.

Monitoring and integration with Azure

Request logs, health probe logs, reports and Azure Monitor integration help diagnose traffic and backend health. Front Door can route to origins inside or outside Azure. It is a global HTTP application entry point, whereas regional services such as Application Gateway have a different architectural role.

Planning failover and caching

Test how your own application behaves when one origin is unavailable. Verify sessions, database dependencies and redirects as well as HTTP status codes. Moving traffic to another region cannot repair an application dependency shared by both regions.

Separate reusable content from private responses when configuring caching. Review which Front Door tier supports the required security and connectivity features before treating an architecture diagram as a deployable design.

How DNSTrace.dev detects Azure Front Door

Detection correlates independent public signals. A single match is reported as strong evidence; agreement between a response header and the announcing network is reported as confirmed.

x-azure-ref — Per-request reference identifier used by Azure support.
x-azure-fdid — The Front Door instance identifier.
CNAME targets under azurefd.net — The Front Door endpoint hostname.
AS8075 — The Microsoft autonomous system commonly announcing the edge address.

What a detection proves

The response passed through an Azure Front Door profile.

What it does not prove

Which backend pool answered, or whether that backend is hosted in Azure. Front Door can route to origins outside Microsoft's network.

Common questions about Azure Front Door

Can Azure Front Door use origins outside Azure?

Yes. Front Door can route to supported origins outside Azure. An origin’s location and a site’s public delivery network are separate architectural choices.

Does AS8075 by itself prove Azure Front Door?

No. AS8075 announces a very large amount of Microsoft infrastructure. DNSTrace.dev only reports Front Door when a response header or endpoint hostname supports it.

CDN