别再被忽悠啦！揭秘 AWS Savings Plans 的糖衣炮弹：省钱不成，反被“绑架”？

在之前的文章《咨询公司CEO暴论：AWS 转售是个坑，早该凉了！》中，我们提到 AWS 将于今年 6 月 1 日起，仅为单一最终用户提供 RI 和 SP，MSP 和经销商将不再能够在多个最终客户之间共享 RI 和 SP 折扣。

今天，我们进一步拆解 Savings Plans，看清那些套路，以及为什么它可能并不像你想象的那样省钱。

什么是 Savings Plans？

AWS Savings Plans 是 AWS 于 2019 年 11 月 推出的一个长期承诺型折扣计划，旨在帮助用户降低计算成本。它的计费方式类似于 Reserved Instances (RIs)，但提供了更高的灵活性。

AWS Savings Plans 被宣传为云成本优化的终极解决方案，承诺提供比按需实例更便宜的价格，并且比传统的 Reserved Instances 更简单易用。然而，单靠 Savings Plans 来优化云成本，就像吃薯条不蘸番茄酱一样——缺少了关键的灵活性，最终可能让你省钱不成，反被“绑架”！

尽管 Savings Plans 提供了一定的折扣，并且适用于所有计算类型（如 EC2、Fargate、Lambda），但它的最大问题在于灵活性不足，容易导致过度承诺（overcommitment）。

这也是为什么大多数企业不会100%使用 Savings Plans 覆盖所有计算支出，而是选择更灵活的方式进行优化。如果你只依赖 Savings Plans，而不结合其他策略，最终可能支付的费用比你想象的还要高！

计费原理

Savings Plans 允许用户承诺在 1 年或 3 年期限内，以一个固定的最低消费金额（如 ¥6/小时）使用 AWS 计算资源，AWS 便会按照折扣价格进行计费。无论用户实际运行的是哪种 EC2 实例，或者使用的是 Fargate、Lambda，AWS 都会按照折扣率计算，只要符合承诺的最低消费额度，超出部分则按正常按需价格收费。

Savings Plans 主要类型

AWS 提供两种 Savings Plans，分别是：

1. Compute Savings Plans

• 适用范围广：支持所有 EC2 实例类型（跨区域、跨操作系统、跨实例家族）、Fargate 和 Lambda。
• 折扣较高，最多降低66%，但不及 EC2 Instance Savings Plans。
• 适合计算需求不固定的企业，因为它允许随意更换实例类型和区域。

2. EC2 Instance Savings Plans

• 仅适用于特定区域的特定实例家族（如 m5.large，且只能在指定区域内）。
• 折扣最高，最多可省72%，比 Compute Savings Plans 便宜。
• 适合计算需求非常稳定的企业，因为它要求 instance family 和区域保持不变。

为什么企业不要 All in Savings Plans？

问题1：预测计算需求？太难了

AWS Savings Plans 要求用户承诺 1 年或 3 年的最低计算支出，以换取折扣，就像是饭店包厢里的“低消”。

但问题是，有多少企业能准确预测未来1~3年的计算需求？

举个例子：

• 一家 SaaS 创业公司在快速增长期购买了大量 Savings Plans，认为自己未来一定会用到这些计算资源。结果，市场变化或技术升级导致计算需求减少，但已经承诺的费用无法调整，白白浪费。
• 另一家游戏公司在假期流量高峰期测算了自己的计算需求，购买了足够的 Savings Plans，但到了淡季，这些计算承诺成为了一种沉没成本，企业无法削减支出。

现实是，计算需求是动态变化的，而 Savings Plans 却是固定的——它无法随业务变化灵活调整，最终可能让企业花冤枉钱。

问题2：计算需求是弹性的，而 Savings Plans 是刚性的

大多数企业的计算需求都会随着业务增长、市场变化或者突发情况发生波动，但 AWS Savings Plans 一旦购买，就相当于把自己锁死在一个固定的支出承诺里。

计算需求是弹性的，而 Savings Plans 是刚性的，两者的错配，会让企业陷入成本困境。

更糟糕的是，大多数企业购买 Savings Plans 时，都是一次性购买大批量的承诺，从而把自己套牢在一个“不灵活的长期合约”里。

因此，对于那些计算需求不可预测或频繁变化的企业，Savings Plans 可能会变成一种负担，而不是节省成本的工具。

这就像你每个月都要吃 30 份自助餐，但如果哪天你胃口不好，吃不完这些餐，你还是得付 30 份自助餐的钱。而按需实例则像点外卖，你按自己的需求付费，虽然单价贵一点，但至少不会浪费。

问题3：未覆盖的计算支出？贵到离谱！

由于计算需求难以准确预测，大多数企业不会用 Savings Plans 覆盖 100% 的计算支出，而是留出一定的“机动预算”。

但问题是，未覆盖的计算部分使用按需实例，价格昂贵得惊人！

一个矛盾点：

• 用 Savings Plans 绑定太多 -> 计算需求下降时，就会有大量浪费的承诺。
• 用 Savings Plans 绑定太少 -> 计算需求上升时，就只能用按需实例，价格爆炸。

最终，企业被逼进了一个“死循环”——想节省成本，却被 AWS 套路！

解决方案：弹性调度 + Spot 实例

我们设定一个简单粗暴的前提：

• 假设一家公司，每天有12个小时处于流量高峰期需要至少3个实例，夜间（0am-12am）为空闲时段。
• 该公司为3个实例购买了1年期全额预付的Savings Plans。
• 假设实例类型为 m6a.large，地区在 us-east-2，系统是 Linux。

那么使用 Savings Plans 的价格为：
$0.05925×3×24小时×365天=$1,557.09（相较于全年使用按需实例节省31%）。

如果采用弹性调度策略，并且在空闲时段采用 Spot 实例，成本为：

• $0.0864（按需价格）×12小时×3×365天=$1,135.296
• $0.0323（Spot 价格） ×12小时×365天=$141.474
• 总成本为：$1,276.77 （相较 Savings Plans 节省18%，相较于全年使用按需实例节省45%）

可见，在购买了 Savings Plans 之后，企业陷入了某种成本困境，即使在夜间业务负载很低，依然需要支付和高峰期相同的费用。这导致资源利用率低，资金浪费。

而弹性调度 + Spot 实例的优化方式结合了高峰时段按需保障性能 + 低谷时段 Spot 省钱，企业可以仅为使用的资源付费，实现最大化节省（相较Savings Plans 节省18%，相较于全年使用按需实例节省44%），并且无需长期锁定计算资源、更具弹性，在确保性能的同时，提供更低的计算成本。

结论：AWS Savings Plans 是“糖衣炮弹”，不能单独承担优化任务

AWS Savings Plans 看似是一个简单易用的云成本优化工具，但如果企业不加思考地全盘采用，就会陷入“过度承诺 + 缺乏灵活性 + 未覆盖支出昂贵”三重陷阱，最终让企业花得比预期更多。

聪明的企业不会把所有鸡蛋放在一个篮子里，Savings Plans 只是成本优化的一部分，而不是全部。

真正的优化策略，是结合弹性伸缩策略和 Spot 实例，打造一个灵活、可调的云成本优化方案！

推荐阅读

CA 不够用了？Azure 推 Karpenter + Spot，让 AKS 便宜 80%！

逐层优化！网安独角兽如何在 AWS 上削减 60% 的 K8s 成本

新手攻略！手把手教你安装配置 Karpenter