S3多用户文件上传下载：桶规划与权限配置技术问询

1. 单Bucket vs 多Bucket选择 #

绝对不要为每位用户单独创建Bucket，理由如下：

• S3 Bucket名称是全局唯一的，1000个用户要生成1000个不重复的Bucket名难度极高，且容易出现命名冲突
• AWS默认每个区域的Bucket配额为100个，虽然可以申请提升配额，但会大幅增加权限管理、监控和成本核算的复杂度
• 多Bucket架构会让后续的批量操作（比如生命周期规则、加密配置）变得繁琐

最优方案：使用单个Bucket + 用户专属对象前缀实现隔离。比如为每个用户分配{userId}:{email}/作为前缀，S3会通过对象键的前缀实现逻辑上的"文件夹"隔离，配合权限控制即可确保用户只能访问自己前缀下的文件。

2. 无需创建AWS账号的权限配置方案 #

你的场景是已有Web API做身份验证，不需要给每个终端用户创建IAM账号（AWS账号），推荐以下两种实用方案：

方案一：S3预签名URL（最适合Web应用上传/下载） #

这是Web应用对接S3的主流方案，流程如下：

• 用户通过你的Web API完成身份验证后，后端记录用户的userId:email标识
• 用户发起上传/下载请求时，先向你的Web API申请对应的预签名URL
• 后端使用自身的IAM角色（需拥有S3对应Bucket的读写权限），生成仅针对该用户专属前缀下特定对象的预签名URL，并设置合理的过期时间（比如15分钟）
• 用户拿到预签名URL后，直接与S3交互完成文件操作，无需任何AWS账号

权限保障：

• S3 Bucket默认设置为私有，仅后端IAM角色拥有访问权限
• 预签名URL仅对指定前缀下的对象有效，且有过期时间，避免权限泄露

方案二：STS临时IAM凭证（适合复杂S3操作场景） #

如果需要用户直接调用S3 SDK进行复杂操作（比如批量上传、文件夹遍历），可以使用AWS STS生成临时凭证：

• 用户通过Web API验证身份后，后端调用AWS STS的AssumeRole或GetFederationToken接口，生成临时Access Key、Secret Key和Session Token
• 生成凭证时，绑定自定义权限策略，限制该凭证仅能访问your-bucket/{userId}:{email}/*路径下的对象，示例策略如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::your-bucket/{userId}:{email}/*"
    }
  ]
}

• 用户拿到临时凭证后，即可用它调用S3 API，且只能操作自己前缀下的文件

关于你之前的尝试 #

用IAM用户+数据库管理文件夹的方案，仅适合少量用户（比如你测试的3个用户），对于1000用户的规模化场景，会带来巨大的管理负担：需要维护1000个IAM用户的凭证、权限、轮换策略，审计和排查问题也会变得异常繁琐，完全不推荐。

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