S3 事件 -> Lambda 与 S3->SNS->Lambda答案

【问题标题】：S3 Event -> Lambda vs S3->SNS->LambdaS3 事件 -> Lambda 与 S3->SNS->Lambda
【发布时间】：2019-01-30 17:34:36
【问题描述】：

我正在尝试了解 S3 事件通知触发器的行为。我有 s3 事件来触发 lambda。 Lambda 将事件和文件元数据捕获到 dynamodb。一天内会有大约 50k 的事件触发。如果我必须在工作流中添加 SNS 并让 SNS 触发 lambda，那么 sns 与 s3 直接调用 lambda 有什么优势？

【问题讨论】：

标签： amazon-web-services amazon-s3 aws-lambda amazon-sns

【解决方案1】：

没有获得优势。 S3 和 SNS 事件都是异步事件源并且行为方式相同。请参阅：Lambda supported event sources 和：Lambda Retry on Errors (Asynchronous invocation part)，它很好地突出了具有特定类型事件源的 lambda 行为。

只需做 S3 -> Lambda 就足够了。

【讨论】：

【解决方案2】：

优势在于未来的灵活性。如果您在中间使用 SNS，您可以轻松地将通知发送（扇出）到具有更多 SNS 主题订阅的多个目的地——另一个 Lambda 函数、一个 SQS 队列、一个 HTTPS 端点，甚至是电子邮件，可以是非常对于非侵入式观察、测试、故障排除和开发需要相同通知的新功能非常有用。

【讨论】：

虽然如果特定用例需要扇出可能是一个优势，但在需要之前实施它并不是一个优势。在 S3 和 Lambda 之间添加 SNS 非常简单，应该只在您需要时才进行，否则您会从 SNS 主题中产生不必要的成本，而不会给您带来任何好处。
@Deiv，我不同意。一旦你需要它，就不可能不中断地添加它，因为在添加新的之前必须删除旧的事件通知——不可能添加重叠的事件通知配置。当您进行更改时，您将丢失事件。问题是“优势是什么？”，我已经正确回答了——这种稳定性和灵活性可能是一个非常引人注目的优势。无一例外，即使现在不需要，我也会以这种方式配置我的通知。
您现在可以为 S3 添加多个事件通知，因此如果您将来需要引入 SNS/SQS 目的地，则无需停机。