Azure Front Door 生成大量带宽

Question

上个月，我注意到由于传出带宽，我的 Azure 账单大幅增加。我使用了 1800GB 的传出数据，而之前的时期使用了约 200GB。经过一番研究，我发现这是由我上个月启用的 Azure Front Door 服务引起的，并且我不知道与该服务相关的额外间接成本。

我将在下面提供我对“问题”的分析，希望防止其他人犯我所犯的错误。

Answer 1

Azure Front Door 允许根据池中应用程序的运行状况在 Web 应用程序组(所谓的“池”)之间进行快速故障转移。典型的故障转移场景是在不同区域之间。如果一个区域出现问题，您可以将故障转移到另一区域。

Front Door 确定应用程序运行状况的机制是通过发送 HTTP 请求，其中 200 OK 结果被视为运行状况良好。

当您在后端启用 Azure Front Door 时，它就会开始检查后端应用程序的运行状况，并且您可能会开始付费，因此我进行了一些分析，以下是我的发现:

【范围4小时，粒度1分钟】

1. 08:05 启动网络应用程序。

2. 08:30 使用默认设置启用前门服务(间隔 = 30 秒，样本大小 = 4，需要成功样本 = 2)。请注意，请求数量立即从每分钟 0 增加到约 140。

3. 09:03 将运行状况探测间隔从 30 秒减少到 15 秒。请注意请求的立即增长。

4. 09:40 将运行状况探测端点的主体大小从 30KB 扩大到 119KB，增加了四倍。请注意带宽的立即增长。

5. 09:55 将运行状况探测端点的正文大小减小至 0KB。请注意带宽立即下降。

6. 10:08 将运行状况探测间隔从 15 秒增加到 90 秒。请注意请求立即下降。

似乎带宽是在 Front Door 服务的带宽之上作为应用服务(或使用的任何端点服务)的传出带宽进行收费的。我认为这是因为 Azure Front Door 是一项全局服务，因此不受区域限制。定价页面上没有提及这些“隐藏”费用

Azure Function App 的默认登录页面为 126KB:

要点

1. 默认情况下，Azure Front Door 似乎每分钟访问您的端点 140 次，每分钟生成 20MB 的流量(主体大小为 30KB)。即 27GB，即每天 1.90 欧元(欧盟/美国地区)。

2. 请勿使用默认函数应用登录页面作为运行状况探测端点(或任何大型主页)。我不确定最佳实践，但我认为实际上执行一些运行状况检查并返回空主体的自定义端点是最好的。

3. 明智地选择您的时间间隔。双倍间隔 = 双倍带宽成本。