AWS Step Functions Express工作流迭代数次后意外退出问题咨询

你遇到的所有异常均由AWS Step Functions的Express类型工作流服务配额限制导致，属于平台预设硬限制，和你的流程配置无关：

• Express类型工作流的最大允许执行时长固定为5分钟（300秒），超出时长会被AWS服务端直接强制终止，不会在流程日志中生成额外错误记录。
• 手动触发使用的StartSyncExecution同步调用接口，本身最大等待返回时长仅为2分钟（120秒），接口等待超时就会返回你看到的调用失败提示，但此时后台状态机仍会继续运行直到5分钟上限。

对应你的现象完全匹配：

• 等待时长设为60秒时，单次迭代（Lambda运行+等待）时长约60秒左右，5次迭代总时长接近300秒上限，因此刚好迭代5次就被强制终止。
• 等待时长设为3600秒时，单次等待就远超5分钟上限，因此无法完成1次迭代就被终止。
• CloudWatch仅记录到WaitStateEntered是因为流程还没走到后续步骤就被强制终止，没有内部错误产生，因此不会有异常日志。

打开Step Functions控制台，找到对应异常退出的执行记录，查看执行状态应为「Timed Out（超时）」，即可确认是执行时长超限导致的问题。

有三种可选方案，根据你的业务场景选择即可：

• 方案1（最适配当前场景）：将工作流类型从Express切换为Standard类型
  Standard类型工作流最大执行时长可达1年，完全支持你这种需要长时间循环等待、反复触发Lambda的巡检类场景，修改后不需要调整现有状态机定义逻辑，即可正常运行。
• 方案2（保留Express类型）：把等待逻辑移出状态机
  取消状态机内部的Wait步骤和循环逻辑，每次状态机执行仅做一次重复账号检测：如果检测到重复，就创建一条EventBridge定时规则，1小时后重新触发状态机执行；如果没有重复就直接结束。单次Express工作流执行时长控制在秒级，不会触碰时长上限。
• 方案3（修复手动触发报错）：改用异步触发接口
  如果不需要同步拿到执行结果，手动触发或API Gateway触发时改用StartExecution异步接口，不会有2分钟的调用超时限制，可避免触发阶段的报错。

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