Azure Front Door允许基于池中应用程序的运行状况在Web应用程序组（所谓的“池”）之间进行快速故障转移。典型的故障转移方案是在不同区域之间进行故障转移。如果一个区域出现问题，则故障转移到另一个区域。
Front Door确定应用程序健康状况的机制是发送一个HTTP请求，其中200 OK结果被视为健康。
当您在后端启用Azure Front Door时，它会开始检查后端应用程序的运行状况，您可能会开始付费，因此我执行了一些分析，以下是我的发现：
x1c 0d1x [范围4小时，粒度1分钟]
1.08：05已启动Web应用程序。
1.08：30使用默认设置启用了前门服务（间隔= 30秒，样本大小=4，所需成功样本=2）。请注意，请求数立即从每分钟0增长到约140。
1.09：03已将运行状况探测间隔从30秒减少到15秒。请注意请求数立即增加。
1.09：40将运行状况探测终结点的主体大小从30 KB增加到119 KB。请注意带宽的即时增长。
1.09：55已将运行状况探测终结点的主体大小减少到0 KB。请注意带宽立即下降。
1.10：08已将运行状况探测间隔从15秒增加到90秒。请注意，请求立即减少。
带宽似乎是作为应用服务（或使用的任何端点服务）的传出带宽在前门服务的带宽之上收费的。我认为这是因为Azure前门是一项全球服务，因此不受区域限制。定价页面上没有提到这些“隐藏”费用
Azure Function应用程序的默认登录页为126 KB：

要点

1.默认情况下，Azure Front Door似乎每分钟访问你的终结点140次，每分钟生成20 MB流量（主体为30 KB）。即每天27 GB或1，90欧元（欧盟/美国地区）。
1.不要使用默认的函数应用程序登录页作为健康探测端点（或任何大型主页）。我不确定最佳实践，但我认为实际上做一些健康检查并返回空正文的自定义端点是最好的。
1.明智地选择间隔时间。间隔时间加倍=带宽成本加倍。

在应用服务配置中将AzureWebJobsDisableHomepage设置为true以从/中删除登录页面，这将节省响应大小，从而节省出口成本。