AWS Lambda上传文件至同区域S3速度慢于EC2的原因咨询

已明确的前置场景 #

• 业务存在向S3批量上传大量文件的需求，当前请求量未达到S3配置的最大请求上限
• c5.large规格EC2实例上传单文件平均耗时约200ms
• 对比环境为10GB内存、与S3同区域的Lambda函数，相同大小文件部分上传耗时达3-4s，明显高于EC2表现
• 耗时统计口径为上传操作启动到上传完成的时间差，待上传文件为应用调用数据库拉取数据处理后生成

高概率根因（按出现概率排序） #

1. S3 SDK未复用HTTP长连接，重复产生连接握手开销 #

这是Lambda场景下S3上传延迟波动最常见的原因：

• 如果S3客户端的初始化代码写在请求处理函数（如Python的lambda_handler、Node.js的handler）内部，每次Lambda调用都会生成全新的SDK实例，无法复用上一次调用留存的TCP长连接。同区域S3走HTTPS协议时，全新建连接的TLS握手+TCP慢启动开销就有1-2s，叠加轻微网络抖动总耗时很容易冲到3-4s。
• 常驻运行的EC2服务通常会全局初始化S3客户端，进程生命周期内一直保活TCP长连接，上传时直接复用连接传输数据，没有额外握手开销，因此耗时稳定在200ms区间。
• 验证方式：开启SDK的详细请求日志，查看慢请求日志中是否存在新建连接的标记，是否有TLS握手相关的耗时记录。
• 修复方式：将S3客户端初始化逻辑移到处理函数外部，利用Lambda执行环境复用特性全局保留客户端实例，实现HTTP长连接复用；Java/.NET等运行时可手动开启SDK的TCP keepalive配置，进一步降低连接断连概率。

2. SDK默认重试机制触发，叠加指数退避等待 #

该场景完全匹配“仅部分文件耗时异常、同大小文件耗时差异大”的特征：

• 官方S3 SDK默认开启自动重试逻辑，针对S3端瞬时5xx错误、网络瞬断、单分区瞬时流控（整体账户配额未达上限也可能出现），会自动做最多3-5次重试，每次重试之间带指数退避等待。如果某次请求刚好触发1-2次重试，总耗时会比正常请求高1-3s。
• EC2环境到S3的网络路径更稳定、长连接保活状态好，触发重试的概率极低，因此平均耗时波动很小。
• 验证方式：开启SDK的重试日志，查看慢请求是否存在重试记录，对应请求的S3返回码是否出现过503、500、429等瞬时错误码。
• 修复方式：小文件上传场景可适当调小重试的退避基准时间，将最大重试次数从默认的3次调整为2次；给上传请求设置合理的单次超时阈值，避免无意义等待。

3. VPC路由配置导致S3流量绕转 #

如果Lambda配置了VPC访问（比如需要连接VPC内的数据库），很容易出现这类问题：

• 若VPC路由表没有配置S3网关端点，Lambda访问同区域S3的流量会经过NAT网关或公网网关绕转，无法走AWS内网直连。NAT网关本身存在带宽争抢、连接数限制，部分请求刚好碰到NAT节点负载高时，延迟会陡增。如果EC2部署时已经配置了S3网关端点或者在公网子网直连S3，就会出现明显的耗时差。
• 验证方式：在Lambda执行环境中运行traceroute s3.<你的区域代码>.amazonaws.com做路由追踪，查看访问S3的流量是否经过公网IP跳点，是否命中S3内网地址段。
• 修复方式：在Lambda所在VPC的路由表中添加S3网关端点，配置路由策略让S3流量走网关端点直连，避免公网绕转。

4. Lambda多租户环境的资源争抢与运行时开销 #

• Lambda是多租户共享底层宿主机的服务，哪怕配置了10GB内存对应的满额CPU配额，也可能出现底层资源调度带来的偶发延迟；如果运行时带自动垃圾回收机制（Java、Python、Node.js等），刚好在上传过程中触发GC停顿，也会拉长单次请求的耗时。这类波动属于偶发，通常只会出现在少部分请求上。而EC2是独享资源的实例，不存在多租户争抢，运行时GC行为也更可控，因此耗时更稳定。
• 验证方式：在日志中埋点记录Lambda初始化耗时、GC停顿时间，查看慢请求对应时间段是否存在GC停顿、执行环境冻结/解冻的记录。
• 优化方式：如果对延迟稳定性要求极高，可以为Lambda配置预配置并发，消除冷启动和环境调度带来的开销；针对运行时做GC参数调优，减少长GC停顿的概率。

快速验证方法 #

可以先做最小化测试：将S3客户端移到全局初始化后，连续发起100次同大小文件上传，统计耗时分布。如果99分位耗时降到200-300ms区间，基本可以确认是长连接复用或重试配置导致的问题。

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