Backends and backend pools in Azure Front Door

This article describes concepts about how to map your web application deployment with Azure Front Door. It also explains the different terminologies used in the Front Door configuration around the application backends.


A backend refers to a web application deployment in a region. Front Door supports both Azure and non-Azure resources in the backend pool. The application can either be in your on-premises datacenter or located in another cloud provider.

Front Door backends refers to the host name or public IP of your application that serves your client requests. Backends shouldn't be confused with your database tier, storage tier, and so on. Backends should be viewed as the public endpoint for your application backend. When you add a backend to a Front Door backend pool, you must also add the following:

  • Backend host type. The type of resource you want to add. Front Door supports autodiscovery of your app backends from app service, cloud service, or storage. If you want a different resource in Azure or even a non-Azure backend, select Custom host.


    During configuration, APIs don't validate if the backend is inaccessible from Front Door environments. Make sure that Front Door can reach your backend.

  • Subscription and Backend host name. If you haven't selected Custom host for backend host type, select your backend by choosing the appropriate subscription and the corresponding backend host name in the UI.

  • Backend host header. The host header value sent to the backend for each request. For more information, see Backend host header.

  • Priority. Assign priorities to your different backends when you want to use a primary service backend for all traffic. Also, provide backups if the primary or the backup backends are unavailable. For more information, see Priority.

  • Weight. Assign weights to your different backends to distribute traffic across a set of backends, either evenly or according to weight coefficients. For more information, see Weights.

Backend host header

Requests forwarded by Front Door to a backend include a host header field that the backend uses to retrieve the targeted resource. The value for this field typically comes from the backend URI that has the host header and port.

For example, a request made for will have the host header If you use Azure portal to configure your backend, the default value for this field is the host name of the backend. If your backend is, in the Azure portal, the autopopulated value for the backend host header will be However, if you use Azure Resource Manager templates or another method without explicitly setting this field, Front Door will send the incoming host name as the value for the host header. If the request was made for, and your backend is that has an empty header field, Front Door will set the host header as

Most app backends (Azure Web Apps, Blob storage, and Cloud Services) require the host header to match the domain of the backend. However, the frontend host that routes to your backend will use a different hostname such as

If your backend requires the host header to match the backend host name, make sure that the backend host header includes the host name of the backend.

Configuring the backend host header for the backend

To configure the backend host header field for a backend in the backend pool section:

  1. Open your Front Door resource and select the backend pool with the backend to configure.

  2. Add a backend if you haven't done so, or edit an existing one.

  3. Set the backend host header field to a custom value or leave it blank. The hostname for the incoming request will be used as the host header value.

Backend pools

A backend pool in Front Door refers to the set of backends that receive similar traffic for their app. In other words, it's a logical grouping of your app instances across the world that receive the same traffic and respond with expected behavior. These backends are deployed across different regions or within the same region. All backends can be in Active/Active deployment mode or what is defined as Active/Passive configuration.

A backend pool defines how the different backends should be evaluated via health probes. It also defines how load balancing occurs between them.

Health probes

Front Door sends periodic HTTP/HTTPS probe requests to each of your configured backends. Probe requests determine the proximity and health of each backend to load balance your end-user requests. Health probe settings for a backend pool define how we poll the health status of app backends. The following settings are available for load-balancing configuration:

  • Path: The URL used for probe requests for all the backends in the backend pool. For example, if one of your backends is and the path is set to /probe/test.aspx, then Front Door environments, assuming the protocol is set to HTTP, will send health probe requests to

  • Protocol: Defines whether to send the health probe requests from Front Door to your backends with HTTP or HTTPS protocol.

  • Method: The HTTP method to be used for sending health probes. Options include GET or HEAD (default).


    For lower load and cost on your backends, Front Door recommends using HEAD requests for health probes.

  • Interval (seconds): Defines the frequency of health probes to your backends, or the intervals in which each of the Front Door environments sends a probe.


    For faster failovers, set the interval to a lower value. The lower the value, the higher the health probe volume your backends receive. For example, if the interval is set to 30 seconds with say, 100 Front Door POPs globally, each backend will receive about 200 probe requests per minute.

For more information, see Health probes.

Load-balancing settings

Load-balancing settings for the backend pool define how we evaluate health probes. These settings determine if the backend is healthy or unhealthy. They also check how to load-balance traffic between different backends in the backend pool. The following settings are available for load-balancing configuration:

  • Sample size. Identifies how many samples of health probes we need to consider for backend health evaluation.

  • Successful sample size. Defines the sample size as previously mentioned, the number of successful samples needed to call the backend healthy. For example, assume a Front Door health probe interval is 30 seconds, sample size is 5, and successful sample size is 3. Each time we evaluate the health probes for your backend, we look at the last five samples over 150 seconds (5 x 30). At least three successful probes are required to declare the backend as healthy.

  • Latency sensitivity (additional latency). Defines whether you want Front Door to send the request to backends within the latency measurement sensitivity range or forward the request to the closest backend.

For more information, see Least latency based routing method.

Next steps