避免巨额账单，详解 AWS 负载均衡器计费中的“坑”

最新推荐文章于 2024-05-22 16:18:37 发布

Jeff_fz

最新推荐文章于 2024-05-22 16:18:37 发布

阅读量1.1k

点赞数 9

文章标签： aws 负载均衡云计算

本文链接：https://blog.csdn.net/zhaifangqing/article/details/136880212

版权

负载均衡对于一个系统的高可用性和可靠性起着关键作用。当后端服务器出现故障或不可用时，负载均衡器可以智能地将请求重定向到其他可用的服务器上，从而确保服务的持续运行。同时，在分布式部署的场景中，负载均衡器确实是一个重要的组件，因为它可以帮助处理大量的并发请求，并确保各个服务器之间的负载得到均衡。

目前，大多数云服务平台都提供负载均衡，例如 AWS、Google、Azure、DigitalOcean 等。不过计费方式都不同，有些计费规则非常复杂，很容易出现高额费用。我们举个例子大家就明白了。

这个例子是来自于 Reddits 上的案例。一个博主的团队开始使用 AWS，然后将 4 个container 迁移到 AWS，设置如下：

其中 3 个是AWS Fargate Spot上托管的Node.js Web应用程序。
另 1 个容器是始终与另一个网站保持 WebSocket 连接的服务，托管在AWS Fargate（非Spot）上。这个 WebSocket 连接传输的数据量约为每天 6 MB。

同时，他还有 4 个负载均衡器，每个负载均衡器都连接了一个 container。

3 个 Application Load Balancer 连接 Node.js web应用
1 个 Network Load Balancer 连接 websocket

一切都看起来不错，只是负载均衡器的费用似乎比他预期的要高得多。平均而言，他在AWS上的费用中有50%来自4个负载均衡器。平均每天要为负载均衡器花费 1.50 美元。但是网站流量并不高，根据负载均衡器上的监控选项卡显示，每个网站平均每小时的请求量不到80次（每天不到2000次请求）。

如果你熟悉 AWS 负载均衡器，这时候你或许已经找到解决这个问题的答案：就是将三个 ALB 整合为一个。

为什么负载均衡会花这么多钱？

我们以 AWS Elastic Load Balancing 为例。AWS Elastic Load Balancing（后面简称：ELB）在计费规则上有一些需要注意的“坑”，下面是一些关键点：

1、计费规则复杂

首先 AWS ELB 是按照LCU （负载均衡器容量单位）计费的，LCU 的计费指标包括四个：

新连接数：每秒新建连接的数量。通常，每个连接可发送多个请求。
活跃连接数：每分钟内活跃连接的数量。
已处理的字节数：负载均衡器为 HTTP(S) 请求和响应处理的字节数（以 GB 为单位）。
规则评估数：负载均衡器处理的规则数量与请求率的乘积。免费处理前 10 个规则（规则评估数 = 请求率 * (处理的规则数量 – 10 个免费规则)）。

以Application Load Balancer为例，每个 LCU 包括：

每秒 25 个新连接。
使用双向 TLS 时，每分钟 3000 个活跃连接或每分钟 1500 个活跃连接。
Amazon Elastic Compute Cloud（EC2）实例、容器和 IP 地址作为目标时为每小时 1GB，Lambda 函数作为目标时为每小时 0.4GB。使用双向 TLS 功能时，处理的数据包括证书元数据的字节，负载均衡器会在路由到目标的每个请求的标头中插入这些字节。
每秒 1000 个规则评估

官方提示道“用户需要按使用量最高的指标付费”。也就是说，以上任何一个指标超过额度上限的时候，都会触发新增一个 LCU，那么用户就需要为此付费。所以一些流量较高的场景肯定会产生巨额的费用。

即使你的 ELB 在一个小时内没有处理任何请求，你也需要为该小时支付费用。所以如果你是在全球多个区域都做了部署，并配置了负载均衡，如果在某些地区还没有什么流量，那么也要为此支付费用。这对于一些希望发展业务的中小公司来讲，可能是逃不开的一笔成本。

除了基本费用外，某些类型的 ELB（如 Application Load Balancer 和 Network Load Balancer）还会根据通过它们的数据量收取费用。这通常是以每MB为单位来计费。这一点来讲，大型的云服务都会收取流量费，比如 Azure 也会按照每 GB 0.01 美元收取费用（实际费用，建议参考官网）

同时，ELB 会定期向注册在其后的目标（例如 EC2 实例）发送健康检查请求。这些健康检查请求虽然很小，但也会产生一些流量费用，特别是当你有大量的目标实例时。

另外，还存在一个跨区传输的情况，也就是我们刚刚提到的。如果你的 ELB 和其后端实例位于不同的 AWS 区域，那么跨区域的流量可能会产生额外的费用。在设计架构时，应尽量将 ELB 和其后端实例放在同一个区域内，以避免不必要的跨区流量费用。

最后，AWS 支持 Automatic scaling，你可以给ELB设置在不同条件下EC2实例的个数。ELB 会监控有多少个实例运行在 ELB 中，当达到某个条件的时候，ELB就会自动创建一个新的EC2 instance满足需求。尽管Automatic scaling是不收费的，但是如果你频繁地创建和删除 ELB，那你可能会遇到一些额外的费用。这是因为即使 ELB 被删除了，AWS 也可能会继续为你在删除前的部分小时计费。因此，在创建和删除 ELB 时要谨慎，尽量避免不必要的操作。

总之，AWS的计费模型非常复杂，包括按使用时间、数据传输量、新连接数等多个计费条件。如果用户没有充分理解（注意，还不是简单了解而已），是很有可能一不小心就产生巨额费用的。

2、流量费昂贵

刚刚我们也提到了 AWS 是会根据流量收取费用的。这一点在AWS 其他产品中也不例外，比如这篇讲 S3 计费的就有提到。一般来讲，大部分用户的巨额账单，都是由于流量产生的。

二、如何避免产生巨额的 AWS ELB 账单

1、设置账单提醒

这一点很重要。你可以使用AWS成本管理工具，如AWS Budgets和成本和使用报告（CUR）。你可以通过通知提醒及时发现是否近期出现了大额账单，及时止损。

2、根据需求来配置

AWS 提供了多种负载均衡器。虽然这也是导致计费规则复杂的原因，但是作为用户，如果适当选择负载均衡器类型，以及规模，可以有效控制成本，避免浪费。

3、及时删除不需要的负载均衡器

这一点不用多说了吧？因为AWS 的负载均衡器是按照时间来计费的。如果有空闲的资源，每多存在一分钟就多计费一分钟，最好尽快删除。

三、也可以考虑更换云服务

首先 AWS 肯定是产品矩阵最完善的代表之一。但相比 AWS 来讲，也有很多云服务可以选择，比如DigitalOcean。DigitalOcean ，它的计价模型更加简单。用户每个月只需要支付 12 美元，就可以获得每秒10000请求数、10000 同时连接、每秒 255 个 SSL 连接，而且没有流量费用。与此同时，DigitalOcean 也有云主机、Function（相当于 Lambda）等配套产品。