异步Invoke Lambda vs SQS/SNS：无需CloudFormation/CDK时后者的优势何在？

先看你当前的Lambda异步调用实现，确实简洁高效：

let aws = require('aws-sdk');
let lambda = new aws.Lambda();

lambda.invoke({
    FunctionName: 'testLambda',
    InvocationType: "Event",
    Payload: JSON.stringify(""),
}).promise();

下面针对你的两个疑问逐一解答：

一、无需基础设施即代码的情况下，用SNS/SQS替代Lambda异步调用的优势 #

哪怕手动创建SNS/SQS资源，也能带来这些实用价值：

• 更精细的重试与错误处理：Lambda异步调用的重试规则是固定配置（默认2次，最多10次），重试间隔由AWS控制；而SQS可以自定义可见性超时（比如失败后隔5分钟再重试），还能配置死信队列隔离多次失败的消息，方便后续排查，比Lambda原生机制灵活得多。
• 更强的消息持久化与可追溯性：SQS消息默认保留4天（最长14天），如果目标Lambda故障，消息会一直存在队列里，你可以直接查看消息内容；Lambda异步调用的事件失败后默认仅保留7天，且需要通过CloudWatch或配置的死信队列才能查看，不如SQS直观。
• 批量处理降本提效：SQS触发Lambda时支持批量消费（最多10条消息），面对大量请求时，能减少Lambda执行次数，降低运行成本；而Lambda异步调用是单事件触发，每个请求对应一次函数执行。
• 多目标分发（SNS专属）：如果需要把同一个事件同步发送给多个服务（比如同时触发Lambda、推送到另一个SQS、通知邮件服务），SNS通过订阅机制就能一键实现，不用在代码里写多次lambda.invoke调用。
• 更可控的流量削峰：突发流量来袭时，SQS可以先缓存所有请求，让目标Lambda按自身并发能力逐步消费，避免被突增请求压垮；Lambda异步调用的内部队列用户无法直接干预，只能通过调整Lambda并发数控制，灵活性远不如SQS。

二、解释“Lambda会先将事件加入队列再发送至函数” #

当你使用InvocationType: "Event"发起Lambda异步调用时，底层流程是这样的：

1. 你的调用请求不会直接送达目标函数，而是先被发送到AWS Lambda管理的内部专属队列（这个队列对用户不可见，也无法直接操作）。
2. Lambda服务会持续从这个内部队列中取出事件，再分发给目标函数执行。

AWS设计这个机制的核心目的：

• 解耦调用方与执行方：调用方只需成功发送请求即可返回，不用等待函数执行完成，大幅提升调用侧的响应速度。
• 容错保障：如果目标函数此时不可用、并发资源耗尽，事件会暂存在内部队列中，等函数恢复或有空闲并发时再执行，避免请求直接丢失（Lambda的重试机制就是基于这个队列实现的）。
• 流量缓冲：面对突发的高并发请求，内部队列可以起到缓冲作用，避免瞬间打满Lambda的并发上限，导致新请求被拒绝。

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