AWS Savings Plans 和预留实例怎么选：折扣逻辑、适用场景与避坑建议

## 为什么要在 Savings Plans 和预留实例之间做选择

在 AWS 上运行稳定业务时，很多团队都会遇到同一个问题：EC2、Fargate、Lambda 或数据库资源已经长期使用，继续按需付费是否划算？AWS 提供了多种承诺型折扣工具，其中最常被比较的是 Savings Plans 和 Reserved Instances，中文通常称为 Savings Plans 节省计划与预留实例。

二者的共同点是：用户承诺在一定期限内持续使用或支付一定规模的资源，从而获得低于按需价格的计费结果。它们都不是充值优惠券，也不是一次性抵扣码，而是绑定到 AWS 账单体系中的计费折扣机制。差异在于，Savings Plans 更关注每小时承诺消费金额，预留实例更关注具体实例规格、区域或容量属性。

对云服务采购者、开发者和企业技术负责人来说，选择哪一种不只是看折扣高低，还要看业务是否稳定、实例是否频繁调整、是否需要容量保障、账单归集方式是否清晰，以及账户充值和付款安排是否能覆盖后续承诺。本文从实际采购和运维角度，梳理两种方案的区别与使用建议。

## 先理解两种折扣的基本机制

Savings Plans 的核心是承诺每小时花费。例如用户承诺未来一年或三年内，每小时在符合条件的计算服务上消费一定金额，AWS 会自动将 Savings Plans 折扣应用到匹配的用量上。只要实际用量符合计划类型和适用范围，就会按折扣价计费；超过承诺部分仍按按需价格计费；低于承诺部分，未使用的承诺通常不会退回。

预留实例的核心是预先锁定某类实例的使用权益。传统 EC2 Reserved Instances 会涉及区域、实例族、操作系统、租期、付款方式等维度。某些类型还可能提供容量预留能力，适用于需要保证特定可用区实例可启动的场景。它更像是对具体资源形态的长期约定。

因此可以先用一句话区分：Savings Plans 适合用量稳定但实例形态可能变化的计算负载；预留实例适合规格明确、长期不变，或对容量保障有特殊要求的负载。

## 折扣差异：不要只看最高折扣

AWS 官方页面通常会展示 Savings Plans、预留实例相对按需价格可获得的折扣范围，但实际可获得多少，取决于区域、实例类型、操作系统、租期、付款方式、计划类型和购买时的价格表。采购时不建议只根据宣传页上的最高折扣做预算，而应以 AWS Cost Explorer、Savings Plans 推荐、Reserved Instance 推荐或报价页面中的实际测算为准。

影响折扣的常见因素包括：

- 租期：一年期通常灵活性较好，三年期通常折扣更高，但对业务稳定性要求更高。

- 付款方式：全预付、部分预付、无预付会影响最终有效价格和现金流压力。

- 资源类型：不同实例族、不同操作系统、不同区域之间价格差异明显。

- 灵活性：越灵活的方案，折扣未必越高；越精确绑定资源的方案，通常要求也更严格。

- 账户结构：在 AWS Organizations 下，折扣可能在合并账单范围内应用，但具体效果需要结合组织设置、共享开关和账单归属确认。

对于企业采购，建议把折扣理解为长期资源规划的结果，而不是单纯的促销。只要业务未来有变化，折扣收益就可能被闲置承诺、规格不匹配或迁移成本抵消。

## Savings Plans 的三种常见选择

Savings Plans 主要面向计算资源，常见类型包括 Compute Savings Plans、EC2 Instance Savings Plans，以及用于 SageMaker 的相关 Savings Plans。日常 EC2 采购中，前两类最常被讨论。

Compute Savings Plans 灵活性较高。它可覆盖符合条件的 EC2、AWS Fargate 和 AWS Lambda 使用，并允许在实例族、实例大小、可用区、区域、操作系统或租赁选项等方面保持较大弹性。对于业务仍在迭代、实例可能从 x86 切换到 Graviton、或一部分负载未来可能容器化的团队，这类计划更容易适配变化。

EC2 Instance Savings Plans 通常绑定某一区域内的某个实例族。它相比 Compute Savings Plans 灵活性低一些，但在符合条件时可能有更好的折扣表现。适合已经确定会长期在某一区域使用某一实例族的业务，例如长期运行的 Web 服务集群、固定规格的中间件节点、稳定的后台计算任务等。

SageMaker Savings Plans 则用于 Amazon SageMaker 相关机器学习使用场景，不应与通用 EC2 负载混淆。AI 推理或训练业务如果使用的是 EC2 自建环境，需要看 EC2 或 Compute Savings Plans；如果使用 SageMaker 托管服务，则应查看 SageMaker 对应计划。

## 预留实例的典型特点

预留实例主要围绕实例属性展开。以 EC2 Reserved Instances 为例，购买时通常需要关注实例类型、区域或可用区、平台、租期、付款方式等。它的好处是规则明确，适用于长期稳定、规格少变的负载；不足是灵活性不如 Savings Plans，业务调整时可能出现利用率下降。

预留实例还分为不同类别。标准预留实例通常折扣较好，但修改和转换能力有限；可转换预留实例允许在一定规则下调整实例族、操作系统或租赁属性等，灵活性较高，但折扣可能不同。具体可改哪些内容，应以 AWS 当前文档和控制台规则为准。

预留实例的另一个重要价值是容量预留能力。区域型预留实例更多体现为账单折扣；可用区型预留实例在满足条件时可提供容量预留。这对高峰期必须保证实例可启动的业务有意义，例如固定时间窗口的批处理、关键业务灾备环境、或对特定可用区部署有严格要求的系统。若只是为了降低账单，而并不需要容量保证，Savings Plans 往往更容易管理。

## 场景一：业务稳定但架构还会变化

如果你的团队已经有较稳定的月度 EC2 账单，但仍在进行实例优化、容器化改造、Graviton 迁移或区域调整，优先评估 Compute Savings Plans。它的优势在于能覆盖更广的计算用量，减少因规格变化导致折扣失效的风险。

例如，一个 SaaS 服务当前主要使用 m 系列和 c 系列 EC2，未来计划将部分后台任务迁移到 Fargate，同时尝试把部分实例切换到 ARM 架构。在这种情况下，过早购买绑定实例族的预留实例，可能限制后续优化。选择较保守金额的 Compute Savings Plans，更符合渐进式改造节奏。

但这并不代表 Compute Savings Plans 可以随意购买。每小时承诺金额一旦超过长期稳定基线，低峰期或迁移期仍可能产生闲置承诺。因此建议只覆盖过去一段时间中持续存在、且未来大概率保留的基础用量，而不是把所有峰值都纳入承诺。

## 场景二：实例族和区域长期固定

如果你的业务已经运行成熟，实例族、区域、操作系统和规模都比较固定，可以重点比较 EC2 Instance Savings Plans 与标准预留实例。二者都适合稳定负载，但管理方式不同。

EC2 Instance Savings Plans 按每小时承诺金额应用到指定区域和实例族下的用量，对实例大小有一定灵活性。对于同一实例族内存在多种规格、但总用量稳定的集群，它比逐个规格规划预留实例更简单。

标准预留实例则适合非常明确的资源形态。例如某数据库代理层长期使用固定规格 EC2，部署区域长期不变，并且三年内没有明显架构调整计划。此时预留实例可能是可比较的方案。但购买前仍要确认操作系统、租赁方式和可用区设置，避免因属性不匹配导致折扣没有应用。

## 场景三：需要容量保障

很多采购者容易把折扣和容量保障混在一起。Savings Plans 主要是计费折扣机制，并不自动保证实例容量。即使购买了 Savings Plans，如果目标可用区在高峰期没有足够容量，仍可能无法启动特定实例。

如果业务必须确保某个可用区在特定时间拥有容量，应查看可用区型预留实例或 On-Demand Capacity Reservations 等容量相关能力。预留实例是否提供容量保障，取决于其类型和配置方式。对于关键系统，建议把成本优化和容量管理分开设计：折扣用于降低长期账单，容量预留用于保障资源可用性，二者可组合但不能互相替代。

## 场景四：开发测试和短期项目

开发测试环境、临时活动、短期项目通常不适合大额长期承诺。即使短期内看起来用量较高，也应先判断项目是否会持续。对于生命周期不确定的环境，更推荐使用按需实例、Spot 实例、自动关机策略、实例规格优化和预算告警等方式控制成本。

如果确实有一部分开发测试资源长期存在，例如固定的 CI 构建节点、基础测试环境或共享中间件，可以只对稳定基线购买少量 Savings Plans。不要为了追求账面折扣而覆盖全部临时峰值，否则项目结束后容易留下不可退的承诺成本。

## 购买前的测算步骤

第一步，查看历史用量。建议至少按服务、区域、实例族、操作系统和账户维度查看账单。Cost Explorer 可以帮助识别持续运行的计算用量。若组织内有多个成员账户，应明确哪些用量属于生产、测试、临时项目或客户环境。

第二步，定义稳定基线。稳定基线不是平均值，也不是最高峰，而是未来一段时间几乎确定会持续存在的最低用量。对于波动明显的业务，可以先覆盖较低比例，再定期复盘，而不是一次性买满。

第三步，比较方案。分别查看 Compute Savings Plans、EC2 Instance Savings Plans 和预留实例的推荐结果，关注有效成本、适用范围、租期和付款方式。推荐结果是辅助工具，不应代替业务判断。若未来半年有迁移、重构或区域调整计划，应把这些变化纳入测算。

第四步，确认付款和账户安排。Savings Plans 和预留实例会影响后续账单，购买前需要确保账户付款方式、充值余额、预算审批和财务归属清晰。对于使用 AWS 国际站但没有国际信用卡，或需要代充值、账户代理、产品代购协助的团队，可在购买前先确认充值路径和账单结算周期，避免因付款问题影响业务连续性。

第五步，小步购买并复盘。尤其是第一次使用承诺型折扣时，建议先从一年期或较低承诺金额开始，观察覆盖率和利用率，再决定是否追加。对成本管理成熟的团队，也应建立月度复盘机制，持续检查是否存在未覆盖的稳定用量或闲置承诺。

## 常见避坑点

一是把峰值当成长期基线。很多业务在促销、发布或压测期间出现短期峰值，如果按峰值购买三年承诺，后续很可能利用率不足。承诺型折扣应覆盖长期稳定部分，峰值部分可继续按需、Spot 或弹性扩缩容处理。

二是忽略实例迁移计划。企业经常在成本优化中更换实例族，例如从上一代实例迁移到新一代实例，或从 x86 迁移到 Graviton。如果已经购买了绑定实例族的计划，迁移可能导致折扣覆盖下降。购买前应与架构团队确认路线图。

三是误以为折扣自动覆盖所有服务。Savings Plans 和预留实例都有适用范围，不会覆盖所有 AWS 产品。S3、数据传输、EBS、NAT Gateway、CloudWatch 等费用通常需要通过各自的优化方式处理。账单下降不明显时，应检查成本大头是否真的来自可覆盖的计算用量。

四是没有区分账户和组织共享。合并账单环境下，折扣共享可能带来便利，也可能造成部门成本归属不清。采购前应确认组织内共享设置、成员账户责任和内部结算规则。对于代充值或账户代理场景，也要在操作前明确由哪个账户购买、由哪些用量受益。

五是只看折扣不看现金流。全预付可能降低有效成本，但会增加一次性付款压力；无预付现金流更平滑，但整体价格可能不同。企业采购应结合预算周期、审批流程和业务确定性选择付款方式。

六是购买后不再管理。承诺型折扣不是一次设置永久最优。业务扩容、实例升级、区域迁移、项目下线都会改变覆盖率。建议至少按月检查 Savings Plans 或预留实例的利用率、覆盖率和未覆盖按需费用。

## 与 AWS 国际站充值和账户代理相关的注意事项

对于使用 AWS 国际站的团队，Savings Plans 和预留实例购买前还应关注账户支付能力。承诺型折扣会持续影响账单，如果账户余额、付款方式或充值流程不稳定，可能给后续运营带来不必要风险。

进化云面向 AWS 国际站用户提供账户注册、代充值、折扣代理及全系列产品代购相关服务。对于没有国际信用卡、需要人民币付款或希望由专人协助核对账单项目的采购者，可以在购买 Savings Plans 或预留实例前，先整理当前账户 ID、目标区域、历史用量、预计承诺周期和预算范围，再进行方案确认。涉及具体价格、折扣和可购买产品时，应以 AWS 控制台、正式账单和当期报价为准。

需要注意的是，代充值服务解决的是账户付款和采购协助问题，不能替代云成本规划。是否购买 Savings Plans 或预留实例，仍应由企业结合业务稳定性、技术路线和财务预算判断。合理的做法是先完成用量分析，再安排充值或采购动作，避免先付款后发现折扣工具并不适合当前业务。

## 选型建议：用稳定性和灵活性做判断

可以按以下思路快速判断：

- 业务长期稳定，但实例族、区域、部署方式可能变化：优先评估 Compute Savings Plans。

- 某一区域、某个实例族长期稳定使用：评估 EC2 Instance Savings Plans。

- 规格非常确定，且可能需要容量保障：评估预留实例及容量预留相关能力。

- 项目周期短、用量波动大或未来不确定：暂缓长期承诺，优先做按需优化和弹性管理。

- 账单中非计算费用占比高：不要只盯 Savings Plans，应同时优化存储、网络、日志和托管服务费用。

如果无法确定，通常更稳妥的策略是先小额、短周期、覆盖基础用量，再根据实际覆盖率逐步追加。云成本优化的目标不是获得看起来最高的折扣，而是在业务可持续、架构可调整、账单可解释的前提下降低长期总成本。

## 结语

AWS Savings Plans 和预留实例都能帮助长期用户降低计算成本，但适合的前提不同。Savings Plans 强在灵活，适合用量稳定但技术形态可能变化的团队；预留实例强在精确和容量相关能力，适合资源属性明确、长期不变的场景。购买前应先看历史用量和未来规划，再比较折扣、租期、付款方式和账户结算安排。

对于 AWS 国际站用户，如果还涉及账户注册、代充值或产品代购，建议在购买承诺型折扣前完成账单梳理和充值规划。这样既能避免承诺闲置，也能让采购、财务和技术团队对后续成本有更清晰的预期。