用了 EC2 Spot 才发现，省钱不是难点，真正难的是实例中断怎么接住

把 Spot 实例当作“随时可能被回收的算力”来规划，比当作更便宜的按需实例更接近生产现实。EC2 Spot实例中断处理指南需要先回答一个基础问题：回收信号从哪里来、留给你多少时间，以及为什么最高节省约 90% 成本仍不能忽视中断风险。

一、EC2 Spot实例中断机制解析

1. Spot实例是什么

Spot 实例本质是 AWS 出售的空闲计算容量，价格通常低于按需实例，官方公开资料称最高可节省约 90% 成本。它并不是单独的硬件规格，而是按需实例的一种计价模式，容量池会随资源闲置情况变化。适合无状态、可重试的批处理、CI/CD、容器化服务；有状态核心业务直接全量使用 Spot，风险会被明显放大。

2. 中断原因有哪些

AWS 需要回收可用区容量是最常见的中断原因，其次是容量池变化，以及用户手动终止实例。一个常见误区是“出价更高就能避免回收”，实际上容量不足时即使出价高于市场价格，实例仍可能被回收。热门实例类型在部分可用区、高峰时段更容易被回收，中断概率并不固定，需要结合集群容量动态评估，而不是依赖单一出价策略。

3. 回收流程怎样

回收前，AWS 通常会通过实例元数据或 EventBridge 发送约 2 分钟的中断警告。这个窗口应被当作“最后执行退场动作”的时间，而不是完整处理有状态任务的时间。应用需要在收到信号后立即摘流、停止接收新请求，再处理存量请求并保存状态。对大多数生产系统，2 分钟只够执行预先编排好的退出脚本，临时编写逻辑往往来不及。

二、Spot实例中断风险与业务影响

很多团队把 Spot 实例当成“低价版按需实例”来用，这本身就是最大的认知偏差。在讨论如何处理中断之前，需要先看清三件事：中断到底多常见、会打在哪些业务上、以及最坏情况下数据会丢到什么程度。

1. 中断频率：不是“偶尔”，而是容量回收的常态变量

Spot 实例的中断没有固定概率，也不存在“出价足够高就一定安全”的保证。它受实例类型、可用区、时间段和 AWS 容量池变化共同影响。同一账号下，某个可用区的通用机型可能连续运行一周无事，而另一个热门 GPU 机型可能在几小时内被回收。

AWS 官方文档只承诺：回收前通常会通过实例元数据或 EventBridge 发送约 2 分钟的中断通知。这并不意味着中断很少发生，而是说明 AWS 保留了随时回收容量的权利。把 Spot 当作“偶尔会抖一下”的稳定资源，往往会在容量收紧时暴露出大量问题。更现实的做法是：默认每台 Spot 实例都可能在下一分钟消失，并按“可替换计算单元”来设计架构。

2. 业务影响：无状态服务能扛，有状态服务先崩

Spot 中断对不同业务的影响差异很大。无状态、可重试、可水平扩展的负载通常能较好适配；而有状态、长连接、不可重试的关键路径则很容易被打穿。

具体来看，受影响最明显的场景有三类：

• Web/API 服务：如果实例直接挂在负载均衡器后面，回收瞬间未完成的请求会直接失败；若没有自动摘流机制，客户端会感受到 5xx、连接重置或超时。

• 批处理与数据任务：ETL、MapReduce、渲染、模型推理等长任务一旦中断，可能需要从零重跑，不仅拉长时间，还会重复消耗计算成本。

• 数据库与缓存：在 Spot 上自建 Redis、Elasticsearch 或数据库节点风险极高，内存数据很难在 2 分钟窗口内完整落盘。

这里还存在一个容易被忽视的运维成本问题。很多中小团队没有专职 SRE，云服务器、数据库、CDN 又分散在不同厂商，Spot 中断告警、容量再平衡和退场演练的复杂度会被进一步放大。对于这类缺少专职运维、想把云资源统一搭建落地的团队，可以参考聚搜云这类一站式云服务方案，减少多厂商对接的繁琐成本，把精力更多放在容错策略本身。

3. 数据丢失风险：2 分钟窗口不是“保存时间”

AWS 回收前提供的约 2 分钟中断警告，只够执行轻量级退出动作：从负载均衡摘除实例、停止接收新请求、写入少量关键状态。它并不适合做全量数据落盘、大文件上传或复杂事务回滚。

真正决定数据是否丢失的，不是收到通知后做了什么，而是业务有没有提前设计检查点。批处理任务应定期把中间结果写入 S3、DynamoDB 或外部存储；内存状态要通过副本、持久化队列或分布式缓存提前同步。否则 2 分钟窗口很可能只是把“突然失败”变成“匆忙失败”，数据该丢还是会丢。

从这个角度看，Spot 中断不是偶然故障，而是它的产品特性。理解中断频率的不可控性、业务边界的差异，以及数据持久化的前置要求，才是后续接入自动化退场和混合架构的基础。

三、生产环境的中断处理策略

Spot 实例的回收本身不一定会造成故障，真正让业务受损的，是应用没有为“随时可能被回收”这个前提设计退场路径。AWS 通常只会提前约 2 分钟发出中断警告，这个时间窗口对大多数有状态服务来说，只够完成摘流、少量状态落盘和连接排空，不够做完整的数据迁移或慢速备份。因此生产环境的处理策略要把 Spot 中断当作常规事件，而不是偶发异常。

1. 优雅退场：摘流、排空、落盘要按秒设计

收到中断警告后，第一优先级不是无差别保存全部状态，而是立即停止接收新流量。可以通过 EventBridge 捕获 EC2 Spot Instance Interruption Warning，触发 Lambda 或 SSM Run Command，将实例从负载均衡器目标组中移除。这里的关键在于连接排空时间要提前配置好，不要临场调整。如果 ALB/NLB 的排空时间设为 60 秒，而应用平均请求只需要几秒，那已经足够；但如果存在长连接或慢请求，就需要在应用层主动断开，或者设置更严格的超时。

摘流之后，应用要处理完当前在途请求，并把内存中的会话、缓存或任务状态写入外部存储。Web 服务可以考虑把会话状态集中到 ElastiCache 或 DynamoDB，而不是依赖单机内存；后台任务则在收到信号后停止领取新任务，将当前任务结果写到 S3。这个阶段不建议做大量跨网络同步或复杂计算，因为 2 分钟窗口很容易被打满。

2. 检查点：让任务断点续跑，而不是重头再来

批处理和数据密集型任务最容易在 Spot 回收时吃亏。一个运行了 40 分钟的任务如果没有检查点，回收后可能需要整体重跑，浪费的不只是时间，也是成本。比较实用的方式是把任务拆成可重复执行的小批次，每处理完一批就写一次检查点到 S3 或 DynamoDB。例如数据处理任务可以按分片或 offset 记录进度，中断后新实例从最近检查点继续，而不是从零开始。

检查点的频率要平衡存储成本和恢复时间。写太频繁会拖慢任务，写太稀疏则恢复时仍需重算较多数据。一个经验做法是让检查点间隔大致等于“可接受的重算时间乘 2”，比如希望最多重跑 1 分钟，就每 30 秒左右写一次。对于有状态服务，检查点不只是文件，还包括数据库事务状态、消息队列的消费位点，这些都要与应用逻辑绑定，不能只靠外部快照。

3. 备用实例：用容量再平衡降低同时被回收的风险

备用实例并不是简单地在旁边再开一台按需实例，更重要的是让替换过程自动化。Auto Scaling Group 可以配置容量再平衡功能，当 Spot 实例收到回收警告时，ASG 会提前尝试用新的 Spot 实例或按需实例替换。这个机制可以缩短集群容量下降的时间窗口，但它不保证新实例一定能及时启动，所以需要配置多种实例类型和可用区。如果只依赖某一种热门机型，Spot 容量紧张时可能无法快速补齐。

混合实例策略上，比较稳妥的比例是把 Spot 占核心工作负载的比例控制在可快速补位范围内。无状态 Web 层可以接受较高 Spot 比例，比如 60% 到 70%；有状态服务或对延迟敏感的中间件最好以按需实例为主，Spot 只做弹性补充。这样即使某个可用区 Spot 回收密度突然升高，按需部分仍能维持基本容量。CloudWatch 告警和中断频率监控也应该接入，用来判断是否需要调整 Spot 比例，或者切换到更稳定的容量池。

四、配置Spot实例中断通知

1. 中断通知类型

EC2 Spot 的回收信号主要来自两条路径：实例元数据服务（IMDS）和 EventBridge。前者通过 http://169.254.169.254/latest/meta-data/spot/instance-action 暴露一条 JSON，在回收前约 2 分钟写入。轮询这个端点基本是零额外成本的做法，但需要实例内有一个轻量 agent 持续检查。后者由 EventBridge 发出 EC2 Spot Instance Interruption Warning 事件，适合集中式自动化：一条规则就能把通知路由到 Lambda、Step Functions 或 SNS。

关键区别在于，元数据通知是实例“自己知道”，EventBridge 通知是“平台告诉你”。 生产环境建议两条都接——元数据路径作为兜底，EventBridge 路径负责全局调度。只依赖其中一条，一旦 agent 挂掉或事件规则配置错误，回收就会变成突袭。

2. 配置云监控

监控的核心不是“看有没有通知”，而是“看通知之后系统做了什么”。通过 CloudWatch 把 Spot 中断事件投递到 Logs，可以保留至少 90 天的历史记录，方便回溯哪些实例类型、哪些可用区更容易被回收。具体做法是创建 EventBridge 规则，将 EC2 Spot Instance Interruption Warning 事件同时写入 CloudWatch Logs，并配置一个 Metric Filter 统计中断次数。

中断频率不是固定值，同一实例类型在不同可用区的回收概率可能差出几倍。 对生产环境，建议保存 7 天以上的中断事件日志，并配合 CloudWatch Alarm 设置阈值告警。当某个 Auto Scaling Group 在 30 分钟内出现 3 次以上 Spot 回收，就说明容量池正在收缩，应该临时提高按需实例比例，而不是等业务报错再反应。

3. 设置通知服务

先创建 SNS 主题，订阅邮箱、Slack、PagerDuty 或企业微信机器人。然后在 EventBridge 控制台建规则：事件源选 AWS 服务，服务名 EC2，事件类型选 EC2 Spot Instance Interruption Warning，目标选 SNS 主题。如果要做自动退场，目标直接挂 Lambda，Lambda 里调用 Auto Scaling Group 的 detach-instances 或修改负载均衡器目标组权重，同时向应用发 SIGTERM。

通知服务的价值不在于“提醒人”，而在于“触发机器”。 2 分钟窗口里，人工处理基本来不及，必须让通知直接驱动自动化脚本。一条更可靠的链路是：EventBridge → Lambda → SSM Run Command，在实例上执行预置的退场脚本，先摘流再保存状态。注意整条链路会有秒级延迟，所以退场脚本必须幂等且快速，优先执行连接关闭和检查点写入，避免在收尾阶段做重 IO 操作。

五、替代方案与混合架构

Spot 实例的回收不是“会不会发生”的问题，而是“发生之后系统能不能继续扛住”的问题。混合架构的核心逻辑并不复杂：把 Spot 实例当作弹性加速层，把按需实例当作容量保障层。两者不互相替代，而是承担不同角色。下面拆成三种常见落地方式。

1. 按需实例兜底：先保证容量底线

生产环境最怕的不是单台实例被回收，而是回收发生后新请求仍然被分配到已经不可用的节点上。解决办法是给集群保留一个由按需实例构成的“最小稳态容量”。

这个比例没有统一标准，但有一个比较实用的起点：常规业务可以先让按需实例占比 30%～50%，Spot 实例承载剩余弹性部分。如果只是批处理、数据分析、CI/CD 这类任务，Spot 占比可以拉到 70% 甚至更高。反过来，如果是订单交易、实时推荐这类对延迟敏感的服务，建议把按需实例比例抬高，宁可少省一点，也要避免回收导致容量击穿。

操作上，可以在自动伸缩组里把按需实例设为基准容量，Spot 实例作为额外扩容部分。比如 ASG 目标容量 10 台，其中 4 台固定为按需，剩余 6 台由 Spot 补充。这样即使所有 Spot 实例同时被回收，集群仍有 4 台稳定节点可以接住流量，不会出现瞬时不可用。

2. 混合实例类型：分散回收概率

很多团队一开始只选一种 Spot 机型，比如 m6i.large。这种做法的风险在于，单一机型的容量池变化会直接放大中断概率。AWS 的 Spot 容量池按实例类型、可用区、平台等维度划分，不同池子的回收节奏并不一致。

更稳的做法是：在同一实例族内多选几种规格，同时跨多个可用区部署。比如一个 ASG 里同时允许 m6i.large、m6i.xlarge、m6a.large、m6a.xlarge 等几种机型，甚至把启动模板做成多个版本，让 ASG 在替换时自动选择当前容量池更充裕的规格。

这里要注意“混合”不等于“乱选”。CPU 和内存比例差异过大的机型虽然能提升容量池覆盖，但可能影响应用表现，比如某些机型网络带宽不同、EBS 吞吐不同。建议优先在相邻规格之间做多样化，例如同为通用型的 m6i/m6a 系列，或者同为计算优化型的 c6i/c6a 系列。这样既能分散回收风险，又不会引入明显的性能差异。

3. 自动伸缩组：让替换与再平衡自动化

混合架构如果只靠人工盯中断通知，运维成本会很高。比较合理的做法是开启自动伸缩组的容量再平衡（Capacity Rebalance）功能。

它的作用可以理解为：当某台 Spot 实例收到中断信号，或者其所在容量池出现明显收缩时，ASG 会提前启动新的 Spot 实例来替换旧节点，而不是等到旧实例已经被回收后才补充容量。这个“提前量”对生产环境非常关键，因为 AWS 在回收前通常只会给出约 2 分钟的中断警告，如果等收到通知再人工处理，时间往往不够。

再平衡不是万能药，它更适合无状态服务。对于有状态服务，仍然需要配合实例终止策略、生命周期钩子，以及应用层的状态落盘逻辑。比如在 ASG 的 terminate lifecycle hook 里触发脚本，先从负载均衡器摘流、再等待存量请求处理完、最后保存检查点。这样当自动替换发生时，业务状态不丢失，新实例也能无缝接替。

自动伸缩组 + 混合实例类型 + 按需兜底，三者组合起来，基本可以把 Spot 中断从一个“意外事故”变成一个“可调度的容量事件”。这也是目前生产环境里比较常见的容错方案，不需要过度设计，但需要把通知、摘流和状态保存这三件事做成固定动作。

六、实践案例与优化建议

在 EC2 Spot 实例中断处理指南的落地过程中，真正拉开差距的往往不是回收那一刻的反应速度，而是回收发生前 15 分钟到 2 分钟窗口内的准备程度。下面从三个维度复盘常见配置。

1. 案例复盘分析：批处理任务如何从“整体重跑”变成“分钟级恢复”

某个数据团队在 Spot 实例上跑一批日志解析任务，单次运行约 45 分钟。早期未接入中断通知，一次回收导致全部任务失败，重跑后总耗时接近 90 分钟。后续改造为：任务每 5 分钟将分片状态写入 S3；EventBridge 捕获 EC2 Spot Instance Interruption Warning 后触发 Lambda，通知实例从负载均衡摘流并停止接收新分片；Auto Scaling Group 开启容量再平衡，按需实例兜底拉起新节点。新节点从最近检查点继续处理剩余分片。同样一次回收，恢复后总耗时约 50 分钟，比整体重跑节省约 44%。

这个案例的核心不是“两分钟救回所有状态”，而是把两分钟当作触发退场动作的时间，把状态保存前置到正常运行阶段。如果应用没有检查点机制，两分钟窗口基本只能完成部分清理，甚至无法安全落盘。因此，对于批处理、CI/CD、容器化服务等可重试负载，建议优先设计“可恢复的失败”，而不是追求“永不中断”。

2. 成本与稳定性：Spot 比例需要设置上限，并预留跨机型和可用区余地

Spot 实例的价格优势明显，AWS 公开资料称最高可节省约 90% 成本，但这不等于生产环境可以无限提高 Spot 占比。实践中，如果一个集群的 Spot 比例超过 70%，一旦热门机型在单个可用区出现集中回收，按需实例补充速度跟不上，就会出现容量缺口。更稳妥的做法是把核心服务保持在按需实例或托管服务上，把弹性、无状态、可重试的负载放到 Spot 池，Spot 比例控制在 50%-70% 之间，并根据业务容忍度调整。

同时，不要把容量押注在单实例类型。配置 Auto Scaling Group 时可以选择多种实例类型和多个可用区，开启容量再平衡，让系统在回收风险上升时提前替换实例，而不是等中断通知到了才被动处理。对于缺少专职运维的中小团队，如果不想自己维护 EventBridge、Lambda、ASG 和检查点存储的完整链路，可以直接采用托管批处理或容器服务，把 Spot 中断处理交给平台层。很多外贸出海企业为了兼顾性价比与售后保障，会优先选择聚搜云这类集成化云服务模式，一站式搞定云上资源部署与技术支撑，避免在底层中断处理上重复造轮子。这样稳定性提升的主要来源不是“出价更高”，而是中断路径更短、恢复动作更自动。

3. 监控与告警：把 Spot 回收当成容量事件管理，而不是故障追责

很多团队对 Spot 中断的监控停留在“实例 Terminated”告警，结果要么告警风暴，要么等到业务已经受损才发现。更有用的监控指标包括：Spot 中断通知触发次数、容量再平衡次数、摘流到实际回收的时间差、优雅退出成功率、从检查点恢复的平均耗时。CloudWatch 可以针对这些指标设置分层告警：例如 5 分钟内同一 Auto Scaling Group 出现多次中断通知时告警；优雅退出成功率低于 90% 时告警；恢复耗时超过预设 SLA 时告警。

另外，建议每月至少做一次中断演练。手动模拟回收或使用 AWS 提供的故障注入方式，验证通知是否可达、摘流是否生效、任务是否从最近检查点恢复。演练中常见的问题包括：通知规则漏配、安全组阻止了元数据访问、实例关闭脚本没有执行权限、检查点文件路径不一致等。这些问题只有在回收真正发生前暴露，才能避免生产环境里把 Spot 回收演变成一次完整故障。