Skip to main content
Seán Braeken-Gray
7 min read

Azure Front Door: A Global Front End for HTTP

Why Azure Front Door exists, how it can sit in front of your applications, and when it helps even if you are not ‘global’ yet.

TechnicalAzureNetworking

If you have spent any time around Azure networking, you have probably seen Azure Front Door mentioned alongside Traffic Manager, Application Gateway, and Azure Load Balancer. They all sound vaguely similar in marketing materials, and the differences are not always obvious until you need them. This post is an attempt to cut through that and explain what Front Door actually is, where it fits, and why it might be worth reaching for even if you are running a modest single-region workload.

A Light Touch on the OSI Model

You do not need a deep dive into the OSI model here, but a quick frame of reference helps. The model describes networking as a stack of layers, each with a specific job and a clear contract with the layers above and below it.

The layers most relevant to web infrastructure are:

  • Layer 4 (Transport): TCP and UDP. It knows about connections, ports, and delivery guarantees. It does not know what the data means.
  • Layer 7 (Application): HTTP, HTTPS, DNS. It understands the content of the request. It can read headers, inspect paths, and make decisions based on what the user is actually asking for.

This distinction matters because it tells you what a given tool can and cannot do. A Layer 4 load balancer can route TCP connections based on IP and port. A Layer 7 tool can route based on the URL path, the hostname, or a cookie value. Azure Front Door operates at Layer 7, specifically over HTTP and HTTPS, which is what gives it the flexibility to do useful things with web traffic.

What Azure Front Door Actually Does

Front Door is Microsoft's globally distributed reverse proxy. When a user's browser makes an HTTPS request to your application, Front Door is the first hop on Microsoft's network. The connection terminates at the nearest Front Door point of presence, and from there Front Door makes a routing decision about where to send the request.

At its core, Front Door handles:

  • Routing: Directing traffic to the correct origin based on rules you define, with support for path-based and host-based routing.
  • Custom domains and managed certificates: You can attach your own domain names and Front Door will handle certificate provisioning and renewal automatically.
  • Health probes: Front Door continuously checks the health of your origin servers and will stop sending traffic to any that are unhealthy.
  • Edge caching: Static content can be cached at the point of presence, reducing load on your origins and improving response times for users.

It is worth being clear about what Front Door is not. It is not a replacement for internal network plumbing. It is the internet-facing front door for HTTP traffic, and it hands off to whatever sits behind it.

The Two Current Tiers

Front Door has a Classic tier, which is the legacy offering. Do not use it for new work. It exists for backwards compatibility and nothing more.

The tiers worth knowing about are Standard and Premium.

Standard covers the core use cases: custom domains, managed certificates, routing rules, health probes, and caching. For the majority of workloads, it is the right starting point.

Premium adds two significant capabilities. The first is private connectivity to origins via Private Link, which means your origin servers do not need a public IP address at all. The second is a stronger edge security posture, including managed rule sets for the Web Application Firewall and more advanced threat intelligence.

The honest advice is to start on Standard. Move to Premium only when a specific requirement makes it necessary, such as a compliance obligation around public exposure, or a security team asking for WAF managed rules. Do not pay for Premium on the assumption you might eventually need it.

How Front Door Compares to Its Neighbours

This is the table that nobody seems to publish clearly enough. These four services overlap in ways that confuse things, but they are not interchangeable.

ServiceLayerScopeProtocol AwarenessTypical Role
Azure Traffic ManagerDNSGlobalNone (DNS only)Route users to a regional endpoint via DNS
Azure Load BalancerLayer 4RegionalTCP/UDPDistribute connections across VMs within a region
Azure Application GatewayLayer 7RegionalHTTP/HTTPSWAF, path routing, TLS termination within a region
Azure Front DoorLayer 7GlobalHTTP/HTTPSGlobal entry point, routing, certs, caching

The key distinctions:

  • Traffic Manager operates purely at DNS. It returns a different IP address depending on your routing policy. It has no concept of HTTP, cannot inspect requests, and does not terminate connections. It is a DNS-level global redirector.
  • Azure Load Balancer sits at Layer 4. It distributes TCP connections across backend pool members within a region. It is fast and efficient, but it cannot read HTTP headers or make routing decisions based on URL structure.
  • Application Gateway is the regional Layer 7 option. It understands HTTP, can do path-based routing, terminates TLS, and includes a WAF. Its scope is a single region.
  • Front Door is the globally distributed Layer 7 option. It shares some surface area with Application Gateway, but its reach is global and it sits at the edge of Microsoft's network.

These tools complement each other. Running Front Door in front of Application Gateway is not redundancy, it is a sensible division of responsibility.

Front Door in Front of Application Gateway

This is the pattern worth paying attention to, because it is practical even before you have any multi-region ambitions.

The combination looks like this: Front Door sits at the edge, handling the public internet-facing concerns. Application Gateway sits in your region, handling WAF, path routing, and backend pool management for your internal services. Front Door sends traffic to Application Gateway, which distributes it appropriately.

Two operational reasons make this worth doing even for a single-region setup.

Certificate Management

Custom domain certificates are an operational burden. If you have a handful of custom hostnames, managing them on Application Gateway is workable. If you have ten, twenty, or more, tracking renewal dates and deploying updated certificates becomes a genuine risk. Front Door manages certificates automatically. You attach a custom domain, verify ownership, and Front Door handles the rest. Moving certificate responsibility to the edge reduces the operational surface considerably.

DNS Stability

When you use Front Door, your customers point a CNAME record at a stable Front Door hostname. That CNAME does not change. What sits behind it can change completely. You could migrate regions, swap out Application Gateway for a different backend, or add a second region for resilience, and your customers' DNS configuration never needs to move. Architectural changes happen behind a stable public address, which removes a class of change that would otherwise require customer-facing coordination.

Private Back Ends (Premium Only)

If you are on the Premium tier, Front Door can route to origins that have no public IP address at all, using Azure Private Link. The connection between the Front Door point of presence and your origin runs over Microsoft's private network rather than the public internet.

This is worth knowing about, but it adds complexity. You will need to approve Private Link connections and ensure your origin is set up to accept them. For most workloads, accepting traffic from Front Door's known service tags and locking down your origin at the network level achieves an acceptable security posture without the overhead of Private Link. Consider it when a compliance requirement specifically demands it.

When Front Door Is and Is Not Worth It

Front Door is not free, and it is not zero-overhead to operate. It is worth being honest about when it earns its place.

It earns its place when:

  • You are managing a significant number of custom domains and certificates, and the operational cost of tracking them manually is becoming a risk.
  • You want DNS stability so that future infrastructure changes do not require customer-facing coordination.
  • You have or anticipate genuine multi-region requirements and want global traffic routing and failover.
  • You want edge caching to reduce load on your origins and improve performance for geographically distributed users.

It probably does not earn its place when:

  • You have a small single-region application with one or two domains and no plans to grow significantly.
  • Your team is small and the additional service in the chain adds more complexity than it removes.
  • Cost is a hard constraint and the use case does not justify the spend.

A single-region, single-domain internal tool probably does not need Front Door in front of it. The honest answer is to assess the operational problem you are actually solving, not the one you might someday have.

Closing Summary

Azure Front Door is the shared public doorway for HTTP traffic on Microsoft's network. It operates at the application layer, sits at the global edge, and handles the concerns that belong at the edge: custom domains, managed certificates, health-aware routing, and optional caching.

Pairing it with Application Gateway is a normal and sensible pattern. The two services are not competitors. Front Door handles the global, internet-facing layer. Application Gateway handles the regional, application-layer concerns behind it. Each one does its job, and the boundary between them is clean.

The region-level tools, Load Balancer and Application Gateway, still do exactly what they always did. Front Door simply sits in front of them, handling everything before the request reaches your region.