基于Lambda的S3对象批量处理方案及技术疑问

场景背景 #

我们有一个批量作业需求：需要处理S3存储桶中的4000+文件，这些文件分散在36个根前缀下，每个根前缀包含4个子前缀；文件路径存储在RDS中，可由Lambda读取。当前计划采用Initializer Lambda从RDS读取配置，向SQS发送6条消息（每条包含6个根前缀），再由Processing Lambda读取消息并顺序处理消息内的6个文件夹，期望6个Processing Lambda并发执行。针对该方案，以下是三个技术问题的解答：

问题1：发送6条SQS消息后，Processing Lambda是否会以并发模式执行？ #

• 会的。SQS作为Lambda事件源时，默认会根据队列中的消息数量自动扩展并发执行环境。当队列中有6条消息时，Lambda服务会启动6个独立的执行实例分别处理每条消息，刚好符合你期望的6个Processing Lambda并发执行的需求。
• 注意：如果你的Lambda配置了预留并发或账户级并发限制，只要限制值不小于6，就不会影响并发效果；若限制低于6，并发数会被限制在设定值内。

问题2：若单文件平均大小约50KB，Lambda将文件读取至内存处理是否会存在问题？ #

• 完全没问题。Lambda最低内存配置为128MB，50KB的文件占比极小，远低于内存上限。
• 即便单条消息处理6个根前缀（每个含4个子前缀），就算每个子前缀下有数十个文件，总内存占用也不会触及Lambda的资源限制。如果后续有更大的处理需求，Lambda内存最高可配置到10GB，弹性足够。

问题3：作业SLA约10分钟，每日8:00-20:00每20分钟触发一次，Lambda是否为合适选择，还是应采用ECS？ #

• Lambda是更合适的选择，理由如下：
  • 成本更低：Lambda按执行时长和资源用量计费，作业仅在触发时段运行，空闲时无资源占用成本，比ECS需要维护集群或频繁启停实例的成本低很多。
  • 运维更轻量：Lambda由AWS全托管，无需管理ECS集群、容器实例的部署和扩容，只需专注于业务逻辑开发。
  • 弹性匹配需求：Lambda能自动根据SQS消息数调整并发数，刚好适配每次触发的6个并发需求，无需手动配置ECS的扩容策略。
• 除非你的处理逻辑有特殊依赖（比如长期保持外部连接、需要复杂本地环境或超大资源占用），否则Lambda完全能满足该场景的SLA和触发频率要求。

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