如何通过AWS API Gateway传输超大型JSON payload，突破与Lambda的大小限制？

方案1：API Gateway 直接代理S3集成 + 异步校验回调（满足单请求要求） #

这个方案完全不需要第三方调用方修改请求逻辑，仍然是向原有同一个POST端点发JSON请求，调整步骤如下：

• 首先修改API Gateway的集成类型为AWS服务集成，指向你的S3存储桶，配置APIGW自动把整个POST请求体写入S3对象，对象名可以用请求ID+时间戳自动生成，避免重复
• 配置S3的对象创建事件，触发你的.Net Core Lambda函数执行后续处理
• 校验逻辑的实现：你可以把原有400校验逻辑拆成两部分：
  • 基础字段校验通过APIGW的请求验证器实现：配置JSON Schema校验顶层的Code、Name字段是否存在、格式是否符合要求，不符合的话APIGW直接返回400 BadRequest，完全和原有逻辑一致
  • 深层字段/Items集合的校验放在Lambda中执行，如果校验失败，你可以通过你原有和第三方约定的回调通知方式（比如你方预先给第三方提供的回调接口、消息推送等）告知错误；如果你的场景允许同步返回的话，可以配置APIGW在写入S3成功后，先调用一个极轻量的校验Lambda拉取S3对象的前N个字节做快速校验，校验通过再返回202 Accepted，校验失败直接返回400
• Lambda处理大文件的注意点：把Lambda的内存配置到至少1GB（越高CPU和网络带宽越高，S3读取速度越快），用S3的流式读取API处理JSON，不要把整个文件加载到内存中避免OOM，.Net Core可以用Amazon.S3.Transfer.TransferUtility的OpenStream方法结合System.Text.Json的Utf8JsonReader做流式解析，完全可以处理GB级别的Items集合

方案2：Payload拆分压缩方案（无需改动现有架构主体） #

如果你的大Payload是可压缩的，这个方案改造成本最低：

• 要求调用方发送请求时开启gzip/deflate压缩，JSON的压缩比通常可以达到10:1以上，100MB的原始JSON压缩后往往不到10MB，刚好可以落在APIGW的10MB限制内
• 在APIGW中启用内容编码支持，自动解压请求体后再传递给Lambda，或者直接把压缩后的请求体传给Lambda，在Lambda代码中自行解压处理，只要解压后的内存占用不超过Lambda的内存限制即可
• 原有校验逻辑完全不用修改，直接复用现有代码即可，调用方也只需要加一个请求压缩头，不需要修改请求地址或者调用逻辑

方案3：Lambda函数URL替代API Gateway #

如果你的API不需要APIGW的WAF、限流、认证等高级能力，可以直接使用Lambda函数URL作为对外端点，Lambda函数URL的请求Payload上限为20MB，比APIGW更高，如果你的Payload大小不超过20MB，这个方案改造成本几乎为0，只需要给Lambda开函数URL，把原有域名指向函数URL即可，所有现有逻辑完全不用修改。

• 如果你的Payload大小超过20MB，优先选方案1，完全没有大小上限，S3可以存储TB级别的对象
• 如果采用方案1，建议给S3存储桶配置生命周期规则，处理完的Payload对象自动过期删除，避免不必要的存储成本

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