如何实现S3上传触发Lambda仅在指定UTC时间范围内执行

直接用SQS做事件缓冲+Lambda触发器时间窗控制+定时唤醒兜底，全原生Serverless组件，零额外运维成本，可靠性最高，具体落地步骤：

• 先改原有事件链路：去掉S3到业务Lambda的直接触发配置，所有S3上传事件统一投递到SQS标准队列，队列开长轮询减少空转成本，没有严格顺序要求就别用FIFO队列，贵且吞吐上限低。
• 给业务Lambda配两个触发源：
  • 第一个触发源绑定刚才的SQS队列，给这个触发器配置启用时间窗，仅在UTC 13:00-20:00时段激活，非允许时段自动停止拉取队列消息，这个是Lambda触发器原生支持的能力，不用自己写代码判断时间。
  • 第二个触发源绑定EventBridge定时规则，固定在每天UTC 13:00整触发一次，作用是唤醒Lambda拉取队列里攒了整个非允许时段的S3事件，避免触发器刚激活时的冷启动导致第一批消息延迟处理。
• 最后给SQS队列配基础可靠性规则：可见性超时设置为业务Lambda最长运行时长的6倍，重试超过3次的消息自动投递到死信队列，避免坏消息阻塞队列，也不会丢事件。

避坑提醒：别选两个常见的不可行方案

1. 前置Lambda判断时间+发延迟消息：SQS延迟消息最长只支持15分钟，要是上传发生在UTC 5:00，距离允许窗口有8小时，根本发不了这么久的延迟消息，完全走不通。
2. 非时段事件写DynamoDB+定时扫表触发：平白多了DynamoDB读写成本，还要自己写扫表、去重、异常处理的逻辑，排查问题链路长，完全没必要。

两个落地优化点：

• 对时间精度要求高的话，把EventBridge定时触发的时间往前调10秒，Lambda启动后先等10秒再开始处理消息，避免时钟偏差导致提前执行。
• Lambda处理SQS批量消息时，记得配置部分失败响应，只返回处理失败的消息ID做重试，不要重复处理成功事件，省成本也避免重复执行业务逻辑。

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