别再被忽悠啦！揭秘 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，分别是：
[*]Compute Savings Plans
[*]适用范围广：支持所有 EC2 实例类型（跨区域、跨操作系统、跨实例家族）、Fargate 和 Lambda。
[*]折扣较高，最多降低66%，但不及 EC2 Instance Savings Plans。
[*]适合计算需求不固定的企业，因为它允许随意更换实例类型和区域。
[*]EC2 Instance Savings Plans
[*]仅适用于特定区域的特定实例家族（如 m5.large，且只能在指定区域内）。
[*]折扣最高，最多可省72%，比 Compute Savings Plans 便宜。
[*]适合计算需求非常稳定的企业，因为它要求 instance family 和区域保持不变。
为什么企业不要 All in Savings Plans？
问题1：预测计算需求？太难了
AWS Savings Plans 要求用户承诺 1 年或 3 年的最低计算支出，以换取折扣，就像是饭店包厢里的“低消”。但问题是，有多少企业能准确预测未来1~3年的计算需求？
https://cloudpilotai.feishu.cn/space/api/box/stream/download/asynccode/?code=ZjA4OTg4MTMyZjNmNzIyMmQwZDhmYzk2YWQzMDlmMGFfOThLMkNhanBUZWdtYnphQ2ZEazFyUHlhTWVTeTVvcVlfVG9rZW46QlBuTmI0NGhjb28xYUV4ZUM1NGNUQVl3bmRoXzE3NDE5MzQxMDk6MTc0MTkzNzcwOV9WNA
举个例子：
[*]一家 SaaS 创业公司在快速增长期购买了大量 Savings Plans，认为自己未来一定会用到这些计算资源。结果，市场变化或技术升级导致计算需求减少，但已经承诺的费用无法调整，白白浪费。
[*]另一家游戏公司在假期流量高峰期测算了自己的计算需求，购买了足够的 Savings Plans，但到了淡季，这些计算承诺成为了一种沉没成本，企业无法削减支出。
现实是，计算需求是动态变化的，而 Savings Plans 却是固定的——它无法随业务变化灵活调整，最终可能让企业花冤枉钱。
问题2：计算需求是弹性的，而 Savings Plans 是刚性的
大多数企业的计算需求都会随着业务增长、市场变化或者突发情况发生波动，但 AWS Savings Plans 一旦购买，就相当于把自己锁死在一个固定的支出承诺里。计算需求是弹性的，而 Savings Plans 是刚性的，两者的错配，会让企业陷入成本困境。
更糟糕的是，大多数企业购买 Savings Plans 时，都是一次性购买大批量的承诺，从而把自己套牢在一个“不灵活的长期合约”里。因此，对于那些计算需求不可预测或频繁变化的企业，Savings Plans 可能会变成一种负担，而不是节省成本的工具。
这就像你每个月都要吃 30 份自助餐，但如果哪天你胃口不好，吃不完这些餐，你还是得付 30 份自助餐的钱。而按需实例则像点外卖，你按自己的需求付费，虽然单价贵一点，但至少不会浪费。
https://cloudpilotai.feishu.cn/space/api/box/stream/download/asynccode/?code=NTdkMmE3YjdhNDAyYmE5MDRmOGM0Y2UxOTU4MTNkNzlfMkl2aUZxSjVsVEpHbzR0QzRFaVBOb09pbmpWUGY3UnBfVG9rZW46S1Z2MWJYQzFrb2cxaVd4angzQWNXQ1NubjNiXzE3NDE5MzQxMDk6MTc0MTkzNzcwOV9WNA
问题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 实例，打造一个灵活、可调的云成本优化方案！
推荐阅读
弹性工具选Karpenter还是Cluster Autoscaler？看这篇就知道啦！
劲省85%云成本！在K8s上使用Karpenter私有部署DeepSeek-R1
Prometheus v2.47+Karpenter：轻松月省4万云成本
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]