支持断点补跑的AWS Lambda任务调度软件/托管服务咨询

以下方案均不需要承担Airflow级别的运维复杂度，适配你提到的ETL补跑场景：

AWS原生零运维方案 #

优先选同栈托管服务，完全不需要自己维护服务节点：

• AWS Step Functions 标准工作流：原生支持Lambda作为任务节点，自带持久化状态存储，不需要额外开发状态追踪逻辑。你可以在工作流中定义时间分片的遍历规则，任务执行失败时会自动暂停在对应失败节点，等依赖服务恢复、Lambda代码修复完成后，直接触发重跑就会从断点开始按顺序补跑所有漏处理的时间分片，不会重复跑已经成功的任务。整套配置在控制台可视化操作即可完成，按状态转换次数计费，小规模ETL场景月成本通常在几美元以内。
• EventBridge Scheduler + DynamoDB 极简组合：如果不想引入Step Functions，只需要在现有Lambda逻辑里加十几行代码：每次被EventBridge触发时，先查询DynamoDB中存储的「最后一个成功处理的时间分片」标记，从该断点之后的第一个未处理分片开始顺序执行，每处理完一个分片就更新标记值。故障恢复后第一次触发就会自动拉取所有积压的分片顺序补跑，DynamoDB按请求量计费，低负载场景基本属于免费额度覆盖范围。

低运维开源自托管方案 #

如果需要跨云或者更灵活的自定义能力，可以选以下轻量工具，运维成本不到Airflow的1/10：

• Dagster 轻量模式：不需要部署整套分布式集群，单进程即可启动服务，原生支持Lambda任务触发，自带任务状态追踪、失败断点续跑、历史补数能力，配置逻辑比Airflow简单很多，最小规格可以跑在1核2G的低配服务器上。
• BullMQ：如果团队熟悉Node/TS技术栈，只需要一个Redis实例就能搭起整套调度+队列服务，自带任务状态持久化、失败重试、顺序消费能力。你只需要写简单的周期规则生成对应时间分片的任务入队，故障恢复后会自动从失败的任务开始往后消费，整套部署加配置耗时不超过1小时。

落地时记得把Lambda的分片处理逻辑做幂等设计，保证同一个时间分片重复执行不会产生重复写入、数据统计错误等问题，避免补跑时引入脏数据。

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