Spot 最高能省九成，但会被回收。讲清两分钟中断机制、四类能用与三类不能用的场景，以及混合部署怎么配。
几乎所有 AWS 折扣文章讲到 Spot（竞价实例）时都只有一句话：利用闲置资源，成本最高可降 90%，但需注意资源供应的稳定性。
这句话没有错，但它缺了最关键的两个半截：90% 是怎么来的（什么条件下能到这个幅度），以及中断到底怎么发生（会提前多久、能不能优雅收尾）。不知道这两点，你既不敢用，也不知道该怎么用。
本文把这两件事讲透，并给出四类适合与三类绝不能放的判断清单。闲置算力这一层五家都有，差别在中断通知时长与折扣幅度，横向对比见 五家云厂商折扣机制对比。
「最高省九成」这句话缺了哪两个半截
第一个半截：幅度是浮动的，而且是别人定的。 Spot 的价格由各区域、各实例类型的供需实时决定，不是固定折扣。官方口径里「最高可低约九成」是观察到的上限，不是你能拿到的保证。热门实例类型在紧张时段可能只有很小的折扣。
第二个半截：你付出的不是钱，是确定性。 按需实例贵在「随时都有」；Spot 便宜在「随时可能被收回」。所以 Spot 的折扣本质是中断风险的定价，理解这点之后，剩下的问题就变成：你的工作负载能承受多大中断风险。
| 维度 | 按需（On-Demand） | 预留 / 节省计划 | Spot |
|---|---|---|---|
| 单价 | 最高 | 中等（承诺换折扣） | 最低（区间大，最高可低约九成） |
| 会不会被中断 | 不会 | 不会 | 会，提前约两分钟通知 |
| 需要承诺吗 | 不需要 | 需要（1 年或 3 年） | 不需要 |
| 适合什么 | 不确定、临时、不能中断 | 稳态基线 | 可中断、可重试的算力 |
一句话定位：预留实例和节省计划是「承诺换便宜」，Spot 是「认了风险换便宜」。两者不冲突，甚至应该同时用——先用承诺覆盖稳态基线，剩下的弹性部分交给 Spot。
Spot 到底是什么：不是打折的 EC2，是别人的退货窗口
把 Spot 理解成「打折的 EC2」会误导判断。更准确的类比是：某个区域的 AWS 容量池里，暂时没人要的那部分算力，被拿出来按供需定价出售。 一旦有出价更高、或按需/预留的需求出现，这部分容量会被收回。
由此产生的三条性质，决定了它的用法：
- 价格随供需波动。 同一个实例类型，不同区域、不同时段价格可能差很多。选冷门实例类型、多区域分散，往往能同时拿到更低价格和更低的中断率。
- 容量不保证。 你想开 100 台，可能只拿到 70 台。请求本身可能部分失败。
- 中断是设计的一部分，不是故障。 它不是「偶尔出问题」，而是这套机制的正常行为——设计系统时必须默认它会发生。
因此 Spot 的使用前提是「工作负载可以被打断」，而不是「希望它别被打断」。这是绝大多数误用的根源：把一个不能中断的服务放上 Spot，然后祈祷它别被回收。
中断是怎么发生的：两分钟通知与三种回收原因
Spot 被回收时，AWS 会提前约两分钟发出中断通知（历史上是两分钟，具体以官方文档为准）。这两分钟是你能做的全部收尾时间，用法见本节末尾。
触发回收大致有几种情况，理解它们有助于选对配置：
| 触发原因 | 含义 | 能做什么 |
|---|---|---|
| 容量需求上升 | 有更高优先级的需求要占用这部分容量 | 换实例类型或换可用区；多类型分散可显著降低命中率 |
| 价格超过你的最高出价 | 当前 Spot 价高于你设的上限 | 合理设置上限（很多场景设为按需价即可，仍能拿到折扣） |
| 实例类型/池容量枯竭 | 该容量池短期没有可分配的量 | 多可用区 + 多实例类型是最有效的应对 |
两分钟该做哪三件事（按优先级）：① 停止接收新请求（从负载均衡里摘掉）；② 把进度写到外部存储（检查点 / 消息队列回退）；③ 跑完手上的这批或主动放弃。这三件事要提前写进应用逻辑，中断时没有时间做决策。
还有一条常被忽略的：中断不代表工作白做。 把任务设计成「小分片 + 可重试 + 幂等」，一次中断只损失一个分片，而不是整批。这是让 Spot 真正可用的工程前提，比选哪个实例类型重要得多。
四类适合 Spot 的工作负载
判断标准只有一条：中断之后，重新跑一遍的代价是否可接受。 代价越小越适合。按这个标准，以下四类通常都合适。
| 类型 | 例子 | 为什么适合 |
|---|---|---|
| 批处理 / 离线计算 | 日志分析、报表生成、ETL、视频转码 | 任务可分片、可重试，中断只影响当前分片 |
| CI/CD 与测试 | 编译、自动化测试、压测 | 天然短生命周期，跑完即弃，断了重跑即可 |
| 无状态弹性算力 | 可随时扩缩的 Web 层、队列消费者 | 节点消失时请求会被重新调度到其他节点 |
| 可容错的训练 / 渲染 | 带检查点的模型训练、渲染农场 | 有检查点就能断点续跑，损失可控 |
- 共同点：都不依赖「这台机器必须一直在」。
- 一个可量化的判断：如果一次中断的平均损失 < 折扣省下的钱的 5%–10%，就可以放心用。
最容易被低估的一类是无状态 Web 层。 很多人只把 Spot 用在批处理上，其实「一部分固定容量（预留/按需）+ 一部分 Spot 弹性容量」的组合，对有明显波峰的 Web 服务性价比极高——峰值用便宜的 Spot 扛，基线用承诺价扛。
具体的实例选择与容量规划见 EC2 实例怎么选。
三类绝对不要放上 Spot 的东西
下面三类是真实的踩坑高发区。它们的共同点是中断会造成数据损失或对外可见的故障，而不是「慢一点」。
- 有状态数据库的主节点。 数据库被回收意味着写盘中段、主从关系需要重建。即使有副本，主节点被打断也会触发故障切换，代价远大于省下的钱。数据库的成本问题应该用预留实例或存储层优化解决，见 AWS 折扣不只在 EC2。
- 没有外部状态、又不能重跑的服务。 比如把会话、临时文件、中间结果放在本机磁盘的服务——机器一回收，数据就没了。判断标准：本机磁盘上有没有「丢了就得从头来」的东西。
- 有硬性交付时窗的任务。 必须在某个时间点前完成、且重跑来不及的任务（如结算截止前的批处理）。Spot 的中断不可预测，不能赌。
⛔ 一个常被忽略的中间地带：「可以中断，但中断后需要人工介入」的任务。这类不要放 Spot——省下的钱会被运维成本吃掉。能自动重试才叫可中断，需要人来处理就不叫。
还有一类边界情况值得单独提：长期运行的、有对外 SLA 的服务，即使它是无状态的。如果 Spot 大面积回收导致容量不足、响应变慢，那也是 SLA 事故。这类服务的基线部分应该用预留/按需保证，Spot 只作为峰值的补充。
怎么用才稳：多实例类型 + 多可用区 + 混合底座
Spot 的稳定性不是靠「选对实例」，而是靠分散。三个动作按有效性排序：
- 多实例类型。 不要只请求一种实例，请求一组算力相近的类型。这样某个池紧张时会自动落到其他池，中断率通常显著下降。
- 多可用区。 把请求分散到同区域的多个可用区，单个 AZ 的容量波动不会打垮整体。
- 混合底座（Mixed instances policy）。 在自动伸缩组里同时配置按需/预留的基线容量 + Spot 的弹性部分。基线保证下限，Spot 吃弹性——这是生产环境最稳的形态。
| 组合方式 | 适用 | 风险 |
|---|---|---|
| 纯 Spot | 内部工具、纯离线任务 | 中断影响全部容量，只适合可完全重跑 |
| 按需基线 + Spot 弹性 | 生产服务的主流形态 | 基线保底，弹性部分中断只影响峰值能力 |
| 预留基线 + Spot 弹性 | 稳态明显、且有波峰的业务 | 最省钱，但需要准确估算基线（见预留实例那篇） |
分配策略也值得一说：容量优化（capacity-optimized）类的策略会优先从当前最不容易被回收的容量池分配，通常比「选最便宜的池」更稳——因为最便宜的池往往正是最紧张的池。别只盯价格选池。
与承诺折扣的关系：Spot 用量不在预留实例和节省计划的覆盖范围内（那两者覆盖的是按需类的计算用量）。所以它们不冲突，而是分工：稳态走承诺、弹性走 Spot。
预留实例怎么买（买多少、买几年、买错怎么办）写在 AWS 预留实例怎么买；两条省钱路径怎么叠加见 AWS 折扣与代理定价。
常见问题
Spot 真的能省 90% 吗？
「最高可低约九成」是官方口径里的观察上限，不是保证值。实际折扣随实例类型、区域、时段大幅波动——热门类型在紧张时段可能只有很小的折扣。判断时不要按 90% 算收益，按你实际拿到的价格算；选冷门实例类型、多区域分散通常能同时改善价格与中断率。
提前多久通知？两分钟够做什么？
约两分钟（具体以官方文档为准）。够做三件事：从负载均衡摘掉不再接新请求、把进度写进外部存储、把手上的分片跑完或主动放弃。前提是这个逻辑提前写好了——中断时没有时间做决策或人工介入。
数据库能放 Spot 上吗？
主节点不建议。被回收意味着写盘中段与故障切换，代价远超省下的钱。有副本也不改变这个结论——故障切换本身就是一次事故。数据库成本应从预留实例、存储层选型与读写分离上解决，见 AWS 折扣不只在 EC2。只读副本、分析型从库在部分场景下可以考虑，但同样要把「重跑代价」算清楚。
怎么降低被回收的概率？
靠分散，不是靠挑实例：请求一组算力相近的实例类型而不是一种、跨多个可用区请求、并用「容量优化」类的分配策略（优先从当前不容易被回收的池分配，而不是最便宜的池）。这三条比任何单个参数都有效。
Spot 和节省计划能一起用吗？
它们不冲突，因为覆盖的是不同用量：节省计划覆盖按需类的计算用量，Spot 用量不在其覆盖范围内。所以合理分工是：稳态基线走预留实例/节省计划，弹性部分走 Spot。把两者当成二选一是常见误解。
生产环境敢用 Spot 吗？
敢，但要用混合底座：用按需或预留保证基线容量，Spot 只承担超出基线的弹性部分。这样即使 Spot 全被回收，服务仍有基线容量可用，只是峰值能力下降。纯 Spot 跑生产服务只在「可完全重跑、无 SLA」的场景下才合适。