我正在使用从SNS事件触发器触发的AWS Lambda函数来从SQS队列中使用。当Lambda函数执行时，它从队列中提取10条消息，处理它们，再拉出10条消息，依此类推 - 直到达到一定时间限制，这些时间限制被编码到Lambda函数中（小于最大值）显然是5分钟。
我的理解是，由SNS事件触发的Lambda函数是一对一的，这是正确的吗？换句话说，一个SNS事件不会触发多个Lambda函数（达到最大并发执行限制）。根据负载没有扩展。
还有其他潜在的解决方案，利用Lambda，让我尽可能频繁/快速地从SQS消费吗？我曾考虑过根据SQS队列大小利用CloudWatch警报（以及SNS事件触发器）来尝试自动扩展我的Lambda函数，但似乎这些警报最多每隔5分钟触发一次。我还考虑开发一个主Lambda函数，它可以根据查询队列大小自动执行（很多）从属Lambdas。
据我所知，更优化的设计可能是利用Kinesis而不是SNS。我可能会考虑将Kinesis融入未来，但现在让我们假装Kinesis不是一个选择。
答案 0 :(得分：0)
没有最佳方法可以做到这一点。一种方法（您已经提到过）是使用CloudWatch并安排Lambda函数每分钟运行一次（这是Lambda的最小调度时间）。然后，此Lambda函数将查找新的SQS消息并调用其他Lambda函数来处理新消息。这是一篇关于该用例的非常好的文章：https://cloudonaut.io/integrate-sqs-and-lambda-serverless-architecture-for-asynchronous-workloads/
就我个人而言，我不建议SNS为此用例触发您的Lambda，因为SNS不能完全保证交付，并建议将SNS通知发送到SQS - 这不能解决您的问题。来自常见问题解答：
[...]如果成功处理所有已发布的消息至关重要，开发人员应将通知发送到SQS队列（除了通过其他传输的通知）。
答案 1 :(得分：0)
对于这种处理，如果您将消息推送到Kinesis Stream，而不是SQS，您应该能够灵活地处理（以所需大小的批量）消息。
注意：如果您使用SQS，在通过SNS（或使用Scheduled Lambda）触发Lambda函数后，它可以调用内部Lambda函数来检查生成多个并发内部Lambda的队列。但问题是批量处理SQS项目不切实际。