寻求AWS Lambda调用失败后支持约1天延迟的指数重试方案

针对你遇到的Lambda失败重试需求，推荐两个基于AWS托管服务的方案，均无需自行维护Cron，且支持百万级事件规模：

方案一：SQS标准队列 + Step Functions 工作流协调 #

利用Step Functions的等待状态实现自定义指数退避，配合SQS标准队列的高吞吐量特性：

• 首次处理失败后，将消息送入SQS标准队列（无需FIFO，标准队列支持百万级并发）
• 创建Step Functions状态机，逻辑如下：
  1. 从SQS获取消息
  2. 调用Lambda处理消息
  3. 处理成功：结束流程
  4. 处理失败：根据当前重试次数计算延迟时间（例如：第1次失败延迟10s，第2次1min，第3次10min，第4次1h，第5次6h，第6次24h）
  5. 进入等待状态，等待对应时长后回到步骤2
  6. 达到最大重试次数仍失败：将消息送入死信队列（DLQ）
• 优势：状态机可视化，可追踪每个消息的重试流程，AWS托管无需维护基础设施，标准队列支持百万级事件

方案二：SQS标准队列 + EventBridge Scheduler 一次性任务 #

通过为每个失败消息创建独立的一次性调度任务，实现精准延迟重试：

• 首次处理失败后，Lambda根据当前重试次数计算下一次延迟时间（按指数退避规则）
• 调用EventBridge Scheduler的CreateSchedule API，创建一次性任务，设置对应延迟时长，任务触发时再次调用Lambda处理该消息
• 可以将消息内容直接存入Scheduler任务的Payload中，或通过SQS暂存（任务触发时从SQS取消息）
• 限制重试次数：每次重试时记录当前次数，达到最大次数后不再创建调度任务，直接送入DLQ
• 优势：轻量灵活，每个消息的重试策略独立，Scheduler支持最长1年延迟，完全满足1天需求，标准队列和Scheduler均支持百万级规模

通用注意事项 #

• 消息去重：给每个事件生成唯一ID，Lambda处理前可通过DynamoDB记录已处理的ID，避免重复执行（SQS标准队列的内置去重仅5分钟窗口，无法覆盖长延迟场景）
• 死信队列配置：无论哪种方案，都要配置DLQ接收最终处理失败的消息，方便后续排查

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