Azure Front Door allows for quick failover between groups (so called "pools") of web applications based on the health of the applications in the pool. A typical failover scenario would be between different regions. If one region has an issue, you failover to the other region.
The mechanism by which Front Door determines the health of an application is by sending a HTTP request where a 200 OK result is considered healthy.
The moment you enable Azure Front Door on your backend, it starts checking the health of your backend application and you potentially start paying so I performed some analysis and these are my findings:
[Range 4 hours, granularity 1 minute]
08:05 Started the webapp.
08:30 Enabled Front Door Service with default settings (Interval=30sec, Sample size=4, Successful samples required=2). Notice the immediate growth in number of requests from 0 to ~140 per minute.
09:03 Decreased the health probe interval from 30sec to 15sec. Notice the immediate growth in requests.
09:40 Quadrupled the body size of the health probe endpoint from 30KB to 119KB. Notice the immediate growth in bandwidth.
09:55 Reduced the body size of the health probe endpoint to 0KB. Notice the immediate drop in bandwidth.
10:08 Increased the health probe interval from 15sec to 90sec. Notice the immediate drop in requests.
It seems like the bandwidth is charged as outgoing bandwidth of the App Service (or whatever endpoint service is used) on top of the bandwidth of the Front Door service. I think this is because the Azure Front Door is a global service and therefore not region bound. These "hidden" charges are not mentioned on the pricing page
This default landing page of an Azure Function App is 126KB:
Takeaways
By default, Azure Front Door seems to visit your endpoint 140 times per minute and generates 20MB of traffic per minute (with a 30KB body). That is 27GB, or, EUR 1,90 per day (EU/US regions).
Don't use the default function app landing page as your health probe endpoint (or any large home page). I'm not sure about the best practices but I would think a custom endpoint that actually does some health checking and returns an empty body would be best.
Choose your interval wisely. Double the interval = double the bandwidth costs.