计海龄 发表于 2025-6-1 20:54:24

别再被忽悠啦!揭秘 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]
查看完整版本: 别再被忽悠啦!揭秘 AWS Savings Plans 的糖衣炮弹:省钱不成,反被“绑架”?