Azure Front Door 产生大量带宽

Sil*_*Sil 8 bandwidth azure cost-management azure-front-door

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

我将在下面提供我对“问题”的分析,希望能避免其他人犯我犯的错误。

Sil*_*Sil 9

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

Front Door 确定应用程序健康状况的机制是通过发送 HTTP 请求,其中 200 OK 结果被认为是健康的。

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

Azure 前门请求和带宽 【范围4小时,粒度1分钟】

  1. 08:05启动webapp。

  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. 明智地选择你的间隔。双倍间隔 = 双倍带宽成本。