如何突破AWS Lambda容量限制将S3大文件POST至REST API

方案1：S3范围读取+流式分块传输（成本最低，优先选） #

• 思路完全绕开“加载全量文件到内存”的死胡同：S3原生支持带Range头的范围请求，你不用把3.5G文件全拖进Lambda内存，只要按固定大小切块（比如单块128MB，给512M内存的Lambda留足运行时、HTTP客户端的冗余空间），逐块从S3读取，读一块就往POST请求的连接里写一块，全程内存里只留当前处理的单块数据，内存占用永远不会超过150M，完全碰不到500M的上限。
• 落地注意事项：
  • 先跟目标API确认是否支持Transfer-Encoding: chunked分块传输，支持的话直接开长连接逐块推就行，不用在本地拼完整请求体
  • 如果API不支持chunked、要求走分片上传流程（大部分文件上传类API都支持：初始化分片任务→逐片上传→最终合并），就每读一个S3块对应传一个分片，所有分片传完发个合并请求就完事，全程内存还是只占单块大小
  • 用AWS SDK读S3的时候别手滑调用无参数的.read()直接拉全量，要用带范围参数的读取方法，比如Python boto3里调用get_object(Range='bytes={start}-{end}')，返回的Body本身是可迭代的流，迭代读就行
  • 记得把Lambda超时时间调够：3.5G文件走AWS内网传输大概30多秒，走公网的话留2-5分钟冗余，Lambda最长支持15分钟超时，完全够
  • 每发完一块就立刻释放这块的内存引用，别攒着块数据，避免内存慢慢涨满。

方案2：用Lambda临时存储缓存文件（适配必须单次POST传完整文件的API） #

• 要是碰到API完全不支持分块、必须单次请求传完整个文件的情况，也不用硬扛内存：现在Lambda的/tmp临时目录最高可以配置10GB存储空间，远大于你的3.5G文件，全程还是不用把文件加载到运行内存：
  1. 给Lambda配置至少4GB的/tmp存储，内存还是配512M就行
  2. 还是按块从S3读文件，逐块写到/tmp目录下的本地文件里，写的时候内存只存当前块
  3. 发POST请求的时候，直接把本地存的文件作为文件流传给HTTP客户端，客户端会从磁盘逐块读内容发请求，不会把全量文件加载进内存
• 注意每次请求处理完删掉/tmp里的旧文件，避免同一个Lambda实例复用时临时目录被占满报错。/tmp的存储成本很低，比你把Lambda内存升到4G以上划算太多。

方案3：更大文件的扩展方案（可选） #

如果后续要处理的文件大小超过10GB，超过了/tmp的配置上限，也不用搭EC2这类常驻服务：给Lambda挂个EFS弹性文件系统就行，EFS容量无上限，还是按块从S3下载到EFS，再逐块读了发POST就行。如果传输容易断，就把已传的分片位置存在DynamoDB里，下次触发直接从断点续传，不用从头读文件。

别踩坑：别想着给Lambda配几个G的大内存硬加载全量文件，一来10G内存档的Lambda成本是512M档的20倍，二来全量加载后只要网络波动触发请求重试，又要重新占内存读一遍全量，稳定性极差，完全没必要。

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