Lambda失败时：用SQS作为目标还是直接调用另一个函数？

核心结论 #

如果你的错误处理逻辑极简单、对可靠性要求不高（比如只是打个测试日志），直接用Lambda失败目标调用另一个Lambda完全可行；但生产环境下更推荐用SQS作为中间层——看起来多了一步，但能解决直接调用的不少硬伤。

直接调用第二个Lambda的劣势 #

• 丢事件风险高：如果错误处理Lambda本身挂了、或者因为并发超限被拒，直接调用的请求会直接丢失，连补录错误记录的机会都没有，而且你可能还不知道这事。
• 容易打满并发配额：要是S3一次性触发大量失败事件（比如批量上传的文件全处理失败），直接调用会瞬间把错误处理Lambda的并发配额耗尽，导致后续的错误处理请求被AWS拒绝，部分错误记录直接没了。
• 没缓冲，扛不住突发流量：错误处理Lambda必须实时接所有请求，一旦它性能跟不上（比如数据库写入慢），整个错误处理流程会直接阻塞，甚至连累原Lambda的重试逻辑（如果有的话）。
• 没法事后复盘：事件处理完就没了，要是事后发现错误处理逻辑有问题，想重新处理这批失败事件都找不到源数据。

SQS中间层的核心优势 #

• 自带重试+死信兜底：SQS可以配置重试次数和重试间隔，就算错误处理Lambda暂时挂了，队列会自动重试；超过重试次数的事件会进死信队列，不会彻底丢失，你可以事后手动处理。
• 削峰填谷稳得住：批量失败事件先存在SQS里，错误处理Lambda可以按照自己的能力慢慢消费，不用担心突然被海量请求打垮，并发完全可控。
• 事件持久化留底：队列里的事件最多能存14天，要是后续发现错误记录漏了、或者想优化错误处理逻辑，随时可以把队列里的事件重新拿出来处理。
• 解耦原逻辑和错误处理：原Lambda只需要把失败事件丢去队列，不用关心错误处理的细节；以后要改错误处理逻辑（比如换成写另一个数据库、或者通知运维），直接改消费Lambda就行，原代码和配置完全不用动。

场景选择建议 #

• 测试环境、个人项目、错误处理逻辑只是打个日志：直接用Lambda目标，快速省事。
• 生产环境、需要确保错误记录不丢、可能出现批量失败：必须上SQS中间层，稳比快重要。

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