azure - 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启动 webapp。

2. 08:30使用默认设置启用 Front Door 服务（间隔 = 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. 明智地选择你的间隔。双倍间隔 = 双倍带宽成本。