可变端点第三方REST API响应下载到S3的Lambda方案及架构咨询

Lambda完全适配该场景，只需将单Lambda全流程执行的逻辑拆分为多步无服务任务编排即可，以下是可直接落地的标准架构：

架构核心流程 #

1. 触发层 #

• 配置两个Amazon EventBridge定时规则：
  • 每月触发一次批次同步任务，匹配新批次更新频率
  • 每周触发一次ID增量同步任务，匹配新ID更新频率
  • 历史全量批次下载需求可手动触发一次流程即可

2. 元数据同步层（单Lambda执行，无超时风险） #

该Lambda仅负责元数据拉取和待下载任务生成，不处理实际数据下载：

• 调用myapi.com/data/batches拉取全量可用批次号
• 遍历每个批次号，调用myapi.com/data/{batch}/ids拉取对应批次下的全量ID
• 识别待下载ID（对应第一个问题的解决方案），两种可选方案适配不同规模场景：
  • 低成本方案：调用S3 ListObjectsV2接口拉取对应批次存储路径下已存在的.json文件，取文件名（即数据ID）和拉取到的全量ID做差集，得到未下载的新增ID列表
  • 高性能方案：用DynamoDB存储(batch_id, data_id)联合主键的下载状态记录，拉取到ID后先查DynamoDB，无记录/状态为未下载的记录进入待下载列表，适合单批次ID量级超过10万的场景
• 将每个待下载的(batch, id)组合作为单独任务消息，发送到SQS标准队列

3. 下载执行层（多Lambda并行执行，解决超时问题） #

该层解决第二个提到的批量下载超时问题，通过任务拆分+异步并行规避15分钟时长限制：

• 配置SQS队列事件触发Lambda，设置合理的批量处理条数（比如一次处理10条，单条响应1MB的话单批次总数据量仅10MB，Lambda处理无压力）
• 每个Lambda实例仅负责处理分到的少量ID任务：
  1. 调用myapi.com/data/{batch}/{id}拉取单条数据
  2. 写入S3对应路径s3://<你的存储桶名>/data/{batch}/{id}.json
  3. 若使用DynamoDB做元数据管理，同步更新对应记录的状态为已完成
• 配置SQS死信队列，处理下载失败的任务：第三方接口限流、超时等异常情况自动重试3次后进入死信队列，后续手动兜底处理即可

额外优化点 #

• 若第三方接口有请求频率限制，可给SQS设置发送延迟，或调整Lambda并发数阈值，避免触发限流规则
• 历史全量批次下载时可临时调高Lambda并发上限，跑完后再调回常规值，不会额外增加成本
• 单条数据1MB的大小对于S3存储、Lambda处理都没有性能瓶颈，整体按需付费的成本远低于常驻服务器方案

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