如何在AWS上实现多租户场景下数千个定时调度任务的稳定运行

多规则独立触发方案（1万条EventBridge规则） #

• 完全不推荐，首先是配额限制：EventBridge默认事件总线单账户单区域配额为2000条规则，自定义事件总线仅为300条，即便提交工单提升配额最高也仅能到数万量级，后续租户、任务规模再涨依然会碰到天花板
• 管理成本极高：租户新增/注销、任务调度规则调整都需要批量增删改规则，故障排查时无法快速定位单租户的任务触发异常，运维成本随规模线性上涨

单规则触发+父任务派生子任务方案 #

• 是当前场景下的最优选型方向，规则数量仅和任务类型数量挂钩，几十条规则远低于配额上限，租户维度的调整仅需要修改父任务读取的租户列表，无需改动调度层配置，扩展性极强

子任务载体选择 #

你提到担心Lambda并发配额不足，这里补充两个关键点：

• Lambda的1000并发是区域级软配额，可以通过工单轻松提升至数万甚至更高，完全可以支撑上万级的并发任务需求
• 你的单任务执行时长仅30秒，无长时运行需求，Lambda的冷启动影响极小，且不需要维护ECS集群、镜像版本、任务定义等组件，运维成本和运行成本都比Fargate更低，除非你的任务有大于10GB的打包依赖、需要特殊 runtime 这类Lambda不支持的场景，否则优先选Lambda作为子任务载体

调度链路优化 #

不要让父任务直接调用子任务执行，建议调整为以下链路：

EventBridge定时触发父任务 -> 父任务拉取对应任务的租户列表 -> 为每个租户生成独立任务消息写入SQS标准队列 -> SQS触发子任务执行/ECS集群根据队列深度自动扩缩容消费任务

• 自带削峰能力，避免瞬间上万并发触发下游外部API、数据库的限流
• 原生支持失败重试、死信队列存储执行失败的任务，不需要自己开发重试、异常兜底逻辑
• 并发可控，可通过Lambda预留并发、ECS最大任务数设置消费速度，避免打垮下游依赖

• Step Functions 状态机方案：每种任务类型创建一个定时触发的状态机，通过Map状态并行执行所有租户的子任务，单Map状态最高支持1万次并行执行，自带重试、异常捕获、全链路执行日志，不需要自己开发父任务的调度逻辑，适合不想自己维护调度代码的场景
• AWS Batch方案：如果后续任务规模继续上涨到十万级，或者有大量重资源消耗的任务，可以选择AWS Batch，原生支持定时调度、任务队列管理、并发控制，是专门面向大规模批量作业的托管服务

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