AWS EC2 Spot实例多中断通知异常：如何确保完整2分钟优雅停机窗口？

这是已知问题吗？ #

这不是AWS EC2 Spot实例的已知行为——每个Spot中断通知的2分钟停机窗口是针对单个实例独立计算的，不会因其他实例的中断通知被覆盖或缩短。问题出在你的中断处理逻辑中，存在共享状态或实例事件混淆的情况。

可能的原因 #

• Lambda函数全局状态污染：如果Lambda使用全局变量存储终止时间、实例ID等信息，短时间内触发两次执行时（Lambda容器复用机制），第二次执行可能读取到第一次留下的全局变量值，导致时序计算错误。
• 事件处理逻辑混淆：处理中断通知时，未严格根据事件中的detail.instance-id区分不同实例，错误地将第一个实例的终止时间应用到第二个实例的处理流程中。
• 共享存储竞争问题：若使用共享存储（如DynamoDB、SSM参数存储）记录实例终止时间，读写操作未基于实例ID做隔离，导致第二个实例的记录被第一个实例覆盖。

确保每个实例获得完整2分钟窗口的解决方案 #

1. 完全隔离实例的中断处理逻辑 #

• Lambda处理EventBridge中断事件时，必须以detail.instance-id作为唯一标识，所有与该实例相关的操作（触发优雅停机、记录状态等）都绑定这个ID，避免跨实例的状态干扰。
• 不在Lambda中使用全局变量存储任何实例相关状态，所有状态要么通过实例ID关联到独立存储条目（如DynamoDB用实例ID做主键），要么直接传递给目标实例的本地处理脚本。

2. 让实例自身主导优雅停机流程 #

Lambda仅作为通知转发器，收到中断通知后，通过以下方式触发目标实例的本地优雅停机脚本：

• 使用SSM Run Command：向目标实例发送预定义的停机脚本命令，脚本在实例本地执行，基于实例自身从EC2元数据服务http://169.254.169.254/latest/meta-data/spot/instance-action获取的中断时间控制停机时序。
• 部署实例本地监听服务：在每个Spot实例上部署轻量服务（如systemd服务或cron任务），定期轮询EC2元数据的中断通知，一旦检测到通知立即启动本地优雅停机流程。这种方式不依赖Lambda，能避免Lambda层面的逻辑错误。

3. 验证事件时序的正确性 #

在Lambda日志中检查每个中断事件的detail.notification-time和detail.instance-action-time字段，确认这些值是对应实例的正确时间。处理逻辑必须基于这些字段的时间，而非自行计算（比如不要简单在当前时间加2分钟）。

4. 测试多中断场景 #

通过EventBridge手动触发两个不同实例的中断通知事件（模拟短时间内的连续通知），检查Lambda执行日志和实例处理流程，确认：

• 两个实例的处理流程完全独立，无共享状态干扰。
• 每个实例的优雅停机流程都基于自身的中断通知时间启动。

内容的提问来源于stack exchange，提问作者Alexandre_Bon