Savings Plans与Reserved Instances到底怎么选？本文从折扣率、灵活性、断点分析和自动化工具四个维度做对比，附Cost Explorer CLI脚本，给出2026年最实用的分层承诺策略。
更新时间：2026年6月25日
AWS Savings Plans与Reserved Instances的核心区别在于灵活性与适用范围：Savings Plans基于"每小时承诺消费金额"覆盖EC2、Fargate和Lambda，更灵活；Reserved Instances则锁定具体实例属性（实例类型、区域、操作系统），灵活性低但在RDS、ElastiCache、Redshift等服务上是唯一的长期折扣选项。说实话，我去年帮一家电商客户做FinOps审计时就踩过这个坑：他们买了一堆3年Standard RI，结果半年后业务全面迁移到Graviton，转售在Marketplace吃了12%价差。2026年大多数纯EC2工作负载应优先选Compute Savings Plans，可节省最高72%；但如果你大量使用RDS/ElastiCache/OpenSearch，还是得混合使用Reserved Instances。本文基于AWS最新计费模型，从折扣率、灵活性、断点分析、自动化工具四个维度做对比，并附上能直接跑起来的Cost Explorer分析脚本。
2019年AWS推出Savings Plans时，定位就是"更灵活的RI替代品"。两者本质都是"用承诺换折扣"，但承诺的对象不同：Reserved Instances承诺一个具体的实例规格（例如"3年内每小时使用1台us-east-1的m5.xlarge Linux实例"），而Savings Plans承诺的是金额（例如"3年内每小时消费10美元的计算资源"）。一字之差，决定了二者在自动化和长期演进上的天壤之别。
当你升级到新一代实例族（例如从m5迁移到m7g Graviton）时，Standard RI需要在RI Marketplace卖掉再买新的，可能损失5-15%的转售价差；Convertible RI允许交换但只能交换为等值或更高价的实例；而Compute Savings Plans完全无感知，只要总计算消费没下降，折扣自动应用到新实例上。这也是为什么2026年AWS官方文档里已经把Compute Savings Plans列为"大多数客户的首选承诺工具"。
但Savings Plans有一个关键限制：它只覆盖EC2（含EC2 for SQL/Windows）、Fargate和Lambda。如果你的TCO里RDS、ElastiCache、Redshift、OpenSearch或DynamoDB预留吞吐占比超过30%，那么忽略Reserved Instances/Reserved Capacity就意味着主动放弃这部分服务的最高72%折扣。这也是2026年大多数企业最终采用"SP + RI混合"策略的根本原因。
下表汇总了两种承诺工具在2026年6月时点的关键差异。注意：折扣率会随实例族、区域和承诺期不同而浮动，表中数字为AWS官方公布的最高节省范围。
| 维度 | Compute Savings Plans | EC2 Instance Savings Plans | Standard RI | Convertible RI |
|---|---|---|---|---|
| 最高折扣 | 72% | 72% | 72% | 66% |
| 承诺单位 | $/小时 | $/小时 | 实例小时数 | 实例小时数 |
| 覆盖服务 | EC2、Fargate、Lambda | 仅EC2（指定实例族+区域） | EC2、RDS、ElastiCache、Redshift、OpenSearch、DynamoDB等 | 仅EC2 |
| 跨区域 | 是 | 否 | 否（区域RI跨AZ） | 否 |
| 跨实例族 | 是 | 否 | 否 | 是（交换） |
| 跨操作系统 | 是 | 是（同实例族内） | 否 | 是（交换） |
| 承诺期 | 1年或3年 | 1年或3年 | 1年或3年 | 1年或3年 |
| 付款选项 | No/Partial/All Upfront | No/Partial/All Upfront | No/Partial/All Upfront | No/Partial/All Upfront |
| 可转售（Marketplace） | 否 | 否 | 是 | 否 |
| 提前取消 | 否 | 否 | 否 | 否 |
2026年AWS提供两种Savings Plans：Compute Savings Plans和EC2 Instance Savings Plans。第三种SageMaker Savings Plans覆盖机器学习训练和推理实例，虽属同一家族但用例较窄，本文就不展开了。
Compute SP最高节省72%，覆盖任何区域、任何实例族、任何操作系统、任何租约的EC2实例，外加Fargate和Lambda。如果你今天承诺每小时10美元，明天把工作负载从us-east-1的m5迁到eu-west-1的c7g Graviton，折扣依然自动应用。对于云原生、容器化、跨区域多活的架构，这几乎是唯一合理的选择。
EC2 Instance SP的折扣率通常比Compute SP高出几个百分点（具体取决于实例族），但你必须锁定一个区域和一个实例族（例如"us-east-1的m5系列"）。在该实例族内你可以自由更换大小（m5.large升级到m5.4xlarge）、操作系统（Linux切到Windows）和租约（Shared切到Dedicated），但不能跨实例族或跨区域。适合工作负载稳定、有明确容量规划的传统应用。
RI是2009年推出的"老牌"承诺工具，2026年仍是RDS、ElastiCache、Redshift、OpenSearch、MemoryDB、DocumentDB等数据库类服务唯一的长期折扣选项。EC2的RI已基本被Savings Plans取代，但RDS等服务的Reserved Instances依旧是FinOps必修课。
Standard RI折扣最高72%，但必须锁定实例类型、区域、租约、平台（操作系统）。一旦购买，无法更改实例属性，但可以在AWS Reserved Instance Marketplace转售（仅限部分区域和Linux）。适合工作负载长期不变的"基线"容量。
Convertible RI折扣约66%（比Standard低约6个百分点），但允许在承诺期内交换为不同实例族、不同操作系统、不同租约的RI，前提是交换后的RI总价值等于或大于原值。适合中长期工作负载演进路径不明确的场景。在Savings Plans推出后，Convertible RI的使用率快速下降，2026年AWS官方推荐："如果你考虑Convertible RI，请优先考虑Compute Savings Plans"。
这三类服务的RI规则与EC2 Standard RI类似：锁定实例类型、区域、引擎（MySQL/PostgreSQL/Aurora等）、部署类型（Single-AZ/Multi-AZ）。折扣最高70%。RDS Aurora的Reserved Instances在2024年增加了对I/O优化集群的支持，2026年是Aurora成本优化最重要的杠杆。可以延伸阅读我们的云成本标签与成本分摊实战指南，把RI节省正确分摊到业务线。
下面这套决策树覆盖了90%的实际场景。先回答上层问题再决定下层：
关于工作负载稳定性的判断，参考我们的Kubernetes成本优化实战指南里关于HPA波动幅度的分析方法。一个经验法则：过去90天每小时EC2消费的P10与P90差值低于30%的部分，全部值得用Savings Plans覆盖。
损益平衡点（Break-even point）回答的是"我至少需要使用多少时间，承诺折扣才比按需便宜？"以us-east-1 m7i.xlarge Linux为例（2026年6月价格）：
以3年All Upfront为例，预付金额约为$1,490。每小时节省约$0.144。要回本需要使用约10,300小时，即如果100%运行需约14个月。换言之：
在购买任何承诺之前，必须先理解现有Savings Plans和RI的覆盖率（Coverage）和利用率（Utilization）。AWS Cost Explorer提供的Savings Plans推荐引擎是首选工具，但通过CLI你可以做更深入的多账户分析。下面这段脚本会输出过去30天的Savings Plans覆盖率：
# 需要AWS CLI v2.15+ 和ce:GetSavingsPlansCoverage权限
# 输出过去30天按服务汇总的SP覆盖率，未覆盖部分即为新的承诺候选
aws ce get-savings-plans-coverage \
--time-period Start=2026-05-25,End=2026-06-25 \
--granularity MONTHLY \
--group-by Type=DIMENSION,Key=SERVICE \
--metrics SpendCoveredBySavingsPlans OnDemandCost \
--query 'SavingsPlansCoverages[].{
Service:Attributes.SERVICE,
Covered:Coverage.SpendCoveredBySavingsPlans,
OnDemand:Coverage.OnDemandCost,
CoveragePct:Coverage.CoveragePercentage
}' \
--output table
接下来运行AWS官方推荐引擎，获取针对3年All Upfront Compute SP的建议承诺金额：
# 获取Compute Savings Plans推荐，3年All Upfront
# EstimatedROI和EstimatedSavingsAmount是核心决策字段
aws ce get-savings-plans-purchase-recommendation \
--savings-plans-type COMPUTE_SP \
--term-in-years THREE_YEARS \
--payment-option ALL_UPFRONT \
--lookback-period-in-days SIXTY_DAYS \
--query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationDetails[].{
Commitment:HourlyCommitmentToPurchase,
EstSavings:EstimatedSavingsAmount,
EstROI:EstimatedROI,
UpfrontCost:UpfrontCost,
BreakEvenInMonths:EstimatedSavingsPercentage
}' \
--output table
建议每个月在月初运行一次以上脚本，把输出作为承诺采购评审会的输入。对于多账户Organization，把上述命令加上--filter参数按Linked Account拆分，识别哪些子账户是承诺采购的最大候选。如果你对多账户成本归因还不熟悉，可以先读我们的AI驱动的FinOps实战指南。
2026年成熟FinOps团队普遍采用"三层承诺策略"，避免把所有鸡蛋放在一个篮子里。
覆盖永远不会消失的基线负载：生产数据库、永久在线的API网关、共享中间件等。优先选择Compute SP获取最高灵活性。如果有非EC2服务，搭配对应的3年RI。
覆盖年度规划内但路线图存在不确定性的负载，例如正在快速演进的新产品线、计划在年底迁移到Graviton的x86工作负载。1年期No Upfront不需要现金支出，是控制风险的最佳工具。
覆盖突发流量、批处理、CI/CD构建、可中断的ML训练。Spot最高节省90%，但需要工作负载具备容错能力。对于Kubernetes上的批处理负载，结合Karpenter的Spot感知调度可以实现"自动顶峰用Spot、低谷用承诺覆盖"的混合模式。
2026年第三方FinOps自动化工具的成熟度大幅提升，可以代替人工每周/每月动态调整承诺组合。三大主流工具的差异：
是否使用第三方工具，取决于你的年度承诺采购金额。一般经验法则：年承诺金额低于50万美元，AWS Cost Explorer自带的推荐引擎+月度评审即可；50万-500万美元，可考虑Vantage或ProsperOps；超过500万美元，CloudHealth或自建FinOps平台。
核心区别在于承诺单位和灵活性。Savings Plans承诺的是每小时消费金额（$/小时），自动应用到任何EC2、Fargate和Lambda实例；Reserved Instances承诺的是具体实例规格（实例类型、区域、操作系统），仅适用于该规格的实例。Savings Plans更灵活，适合现代化云原生工作负载；RI在RDS/ElastiCache等数据库服务上仍是唯一长期折扣选项。
对于EC2、Fargate、Lambda工作负载，Compute Savings Plans几乎总是更优，它的最高折扣（72%）与Standard RI相同，但灵活性高得多。仅当你确信工作负载在3年内不会更换实例族或区域时，EC2 Instance SP或Standard RI的折扣率会略高1-3个百分点。对于RDS、ElastiCache、Redshift、OpenSearch，Savings Plans根本不覆盖，必须使用Reserved Instances。
不可以。2023年6月起，AWS取消了Savings Plans的队列购买和退回功能。所有Savings Plans一经购买即不可取消、不可退款。Reserved Instances同样不可取消，但Standard RI可以通过AWS Reserved Instance Marketplace在美东/美西区域转售给其他客户（仅限Linux）。因此首次购买务必从1年No Upfront的小额试水开始，控制风险。
Savings Plans到期后，被它覆盖的实例自动按按需价格计费，账单会立即出现"应承诺未承诺"的成本激增。AWS会在到期前30天、7天、1天发送账单提醒。建议提前60天评估续约，使用Cost Explorer的"Savings Plans Recommendation"重新生成承诺建议，避免到期日成本断崖。最佳实践是把所有承诺到期日分散到不同月份，避免续约谈判和现金支出过度集中。
理想覆盖率是85-95%，剩余5-15%保留按需作为业务波动缓冲。低于80%意味着承诺不足，正在白白支付按需溢价；高于95%但利用率（Utilization）低于95%意味着承诺过度，部分承诺金额未被使用。每月运行aws ce get-savings-plans-coverage和aws ce get-savings-plans-utilization同时监控两项指标。
S3、Azure Blob、GCS三大云存储成本优化实战指南：Intelligent-Tiering、Autoclass、Cold层选型、Lifecycle策略与TCO计算器，30天内砍掉40%到70%月账单，附十条FinOps落地清单。
生成式AI在2026年已成为企业云账单上膨胀最快的支出项。本文从GPU实例选型、推理优化、Token经济学到向量数据库成本，给出AWS/Azure/GCP三大平台可立即落地的省钱方案，并附完整代码示例与FinOps监控策略，帮你在30天内把LLM账单砍掉40%-65%。
数据出口费用通常占云账单的 6%–12%，可大多数团队连"我的 Egress 花在哪里"都答不上来。本指南拆解 2026 年 AWS/Azure/GCP 出口真实价格、NAT Gateway 等隐藏成本，并给出 10 种可立即落地的优化策略。