Azure Front Door is a scalable and secure entry point for fast delivery of your global web applications. Front Door periodically sends a synthetic HTTP/HTTPS request to all your configured origins to determine health and proximity. Since multiple global locations are each sending health probes to your origins, the volume of traffic and ’egress’ can be quite high. In this post, I will explain why this is important and how you can reduce egress costs using HEAD requests.

At the time of writing, Azure Front Door has 192 edge locations across the globe. An individual edge location will start sending health probes to your origins when it receives traffic from your end users. Using the default probe frequency of 30 seconds, each edge location will send approximately two requests per minute to each origin. That is upwards of 384 requests to each origin per minute - or 552,960 requests per day. If an edge location doesn’t receive real traffic from your end users, the frequency of the health probe from the edge location is decreased from the configured frequency.

Azure egress costs refer to the charges incurred when data is transferred out of Azure data centres to the Internet or to other regions. The cost of egress traffic is dependent on the region and the amount of data transferred. With this in mind, we should consider the volume of traffic generated by health probes. In many cases, the origin server exposes a lightweight ‘health check’ endpoint that can be used to determine the health of the server. Half a million requests per day to such an endpoint is usually insignificant - but it certainly isn’t free. This is especially true if the origin is a static website, where the health probe would typically make a request to the root of the website, or a specific static file such as health.html.

Use HEAD requests for health probes

Azure Front Door supports sending probes over either HTTP or HTTPS protocols and can use either the GET and HEAD methods.

• The GET method means retrieve whatever information is identified by the Request-URI.
• The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.

It is a good practice to use the HEAD method for health probes because the server will respond with the headers only, and not the body of the response. This can significantly reduce the amount of traffic load on your origins, and the cost of egress traffic.

Note: For new Front Door profiles, by default, the probe method is set as HEAD.

In a recent project, our team observed a significant amount of egress traffic from a static website hosted on Azure Blob Storage. The health probe was configured to use the GET method and was making requests to the root of the website (GET index.html). The cost of this egress was a significant portion of the overall cost of the service. By simply changing the probe method to HEAD index.html, we were able to reduce the egress traffic by approximately 90%.

StorageBlobLogs
| where OperationName == "GetWebContent"
| summarize sum(ResponseBodySize) by bin(TimeGenerated, 5m)
| render timechart

How to check

It is possible to check your configuration from the Azure Portal. However, I find it is easier to get a summary of the configuration using the Azure CLI.

$ az afd origin-group list \
    --resource-group [rg] \
    --profile-name [profile] \
    --query "[].{name:name, probePath:healthProbeSettings.probePath, probeMethod:healthProbeSettings.probeRequestType}" \
    -o tsv
default-origin-group  /            HEAD
custom-origin-group   /index.html  GET
another-origin-group  /_health     GET

We could also leverage this command in a straightforward bash script to get a summary across all Front Door profiles in a subscription.

FRONT_DOOR_PROFILES=$( az afd profile list --query "[].{name: name, rg: resourceGroup}" --only-show-errors -o tsv )

echo "$FRONT_DOOR_PROFILES" | while IFS= read -r line; do
    NAME=$(echo "$line" | awk '{print $1}')
    RESOURCE_GROUP=$(echo "$line" | awk '{print $2}')
    az afd origin-group list \
        --resource-group $RESOURCE_GROUP \
        --profile-name $NAME \
        --query "[].{profile:'$NAME', rg: '$RESOURCE_GROUP', group:name, probePath:healthProbeSettings.probePath, probeMethod:healthProbeSettings.probeRequestType}" \
        --only-show-errors -o tsv
done

Disable probes when using a single origin

If your profile is configured with only a single origin, Front Door will always route traffic to that origin. Even if its health probe reports an unhealthy status. The status of the health probe, in this configuration, provides no value and does nothing to change Front Door’s behaviour.

You can (and should) disable health probes when there is only one origin in an origin group. This will reduce the traffic on your origin and the cost of egress traffic.

In this example origin group, we can see only one origin is configured. We have therefore disabled the health probe.

Summary

Azure Front Door health probes are an essential feature to ensure your application is highly available and responsive. However, the volume of traffic generated can be significant and costly. By using the HEAD method for health probes, you can reduce the amount of traffic on your origins and the cost of egress.