AWS Lambda中调用S3 create_multipart_upload超时问题：generate_presigned_post正常、移除Endpoint后恢复正常的原因排查

云原生阿岚

2026-4-30

排查AWS Lambda调用自定义S3端点create_multipart_upload超时问题

从你遇到的情况来看，问题的核心大概率出在自定义S3兼容端点对分片上传接口的支持逻辑，或者Lambda与该端点的网络连通性上——毕竟去掉endpoint_url后接口能正常工作，而且generate_presigned_post也没问题，说明你的基础S3客户端配置和权限都是ok的。

下面我梳理几个可能的原因和对应的排查、解决方向：

一、自定义S3兼容服务的API支持差异

很多第三方S3兼容存储（比如MinIO、Ceph这类）虽然实现了大部分标准S3 API，但分片上传相关的接口（比如create_multipart_upload）可能存在细节差异：

create_multipart_upload是Lambda主动向存储服务发起的服务端直调接口，而generate_presigned_post只是生成一个签名URL，实际请求是由外部客户端发起的。如果你的自定义存储服务对服务端直调的分片接口有特殊要求（比如需要额外的认证头、或者接口路径和标准S3不一致），就会导致超时。
建议先去查一下你用的存储服务的官方文档，确认它是否完全支持标准的create_multipart_upload API，有没有特殊的配置要求。

如果你的Lambda函数配置了VPC，那它的网络访问会受VPC的安全组、子网、NAT网关等配置限制：

先确认自定义S3端点是否在Lambda的可访问范围内：如果是内网端点，要确保Lambda所在的安全组允许出站访问该端点的443端口；如果是公网端点，要检查NAT网关是否配置正确，Lambda能不能正常访问公网。
这里要注意和generate_presigned_post的区别：这个接口不需要Lambda直接访问存储服务，只是生成签名返回，所以哪怕Lambda网络受限，只要能生成签名就会成功；但create_multipart_upload是Lambda主动发请求到端点，网络不通就会直接超时。

你的endpoint_url格式可能不符合自定义存储服务的要求：

有些S3兼容服务要求endpoint不能带bucket前缀，比如应该用https://your-endpoint.com，而不是https://bucket.your-endpoint.com，bucket通过请求的Bucket参数指定。你可以试试去掉endpoint里的bucket部分，再测试调用。
另外，有些服务要求endpoint包含区域信息（比如https://s3.us-east-1.your-endpoint.com），如果你的URL里没加，也可能导致服务无法正确路由请求。

虽然你指定了s3v4签名，但有些自定义存储服务对S3v4签名的处理可能有特殊逻辑：

你可以按以下顺序尝试，快速定位问题：

本地验证端点可用性：在能访问该自定义端点的本地机器上，用和Lambda完全一样的代码调用create_multipart_upload，如果本地也失败，那就是存储服务本身的问题，联系服务商或者检查服务配置。
排除VPC网络问题：临时把Lambda切换到“不配置VPC”（用AWS的公网环境），测试是否能调用成功。如果成功了，就说明之前的VPC配置有问题，需要调整安全组或NAT网关。
调整endpoint格式：按照存储服务文档的要求修正endpoint_url的格式，比如去掉bucket前缀、添加区域信息等。
开启调试日志：在Lambda代码里添加boto3的DEBUG日志，查看具体的请求细节：
```
import logging
import boto3
boto3.set_stream_logger('', logging.DEBUG)
```
这样能看到请求的URL、头部、响应状态等信息，帮你定位是请求发不出去，还是服务端没响应。

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