SST 部署过程中 S3 PutObject 权限问题分析与解决

问题背景

在使用 SST (Serverless Stack Toolkit) 部署 Next.js 应用时，开发者遇到了一个常见的 AWS S3 权限问题。具体表现为部署过程中出现 operation error S3: PutObject, api error AccessDenied: Access Denied 错误，导致部署失败。

错误现象

部署过程中，系统尝试将构建产物上传到 S3 时遭遇权限拒绝。尽管开发者使用的是具有管理员权限的 IAM 身份中心(Identity Center)账户，配置了正确的 AWS 区域和 SSO 会话，但仍然无法完成 S3 对象的写入操作。

根本原因分析

经过深入排查，发现问题的根源在于：

1. 资源命名冲突：之前部署时使用了不同的应用名称，导致 SST 创建的 S3 资产桶和状态桶中存在残留资源
2. 参数存储残留：AWS Systems Manager Parameter Store 中保留了旧的 /sst/bootstrap 参数
3. 部署状态不一致：新旧部署状态混合导致权限系统出现混乱

解决方案

针对这一问题，可以采取以下解决步骤：

1. 清理旧资源：

   • 手动删除 AWS 控制台中的 asset 和 state S3 存储桶
   • 清除 Parameter Store 中的 /sst/bootstrap 参数

2. 修改项目标识：

   • 更改 sst.config.ts 中的应用名称，确保使用全新的唯一标识

3. 完整重新部署：

   • 执行 sst deploy 命令，让系统从头开始创建所有必要资源

最佳实践建议

为避免类似问题，建议开发者：

1. 命名规范：为 SST 项目使用明确且唯一的名称，避免使用通用名称
2. 环境隔离：为不同环境(开发、测试、生产)使用不同的 AWS 账户或区域
3. 清理机制：在更改重要配置前，先使用 sst remove 命令清理旧部署
4. 权限验证：部署前使用 AWS CLI 验证当前凭证的 S3 写入权限

技术细节

SST 在部署过程中会创建多个 S3 存储桶用于不同用途：

1. 资产存储桶：存放构建后的静态资源
2. 状态存储桶：存储部署状态信息
3. 函数代码存储桶：存放 Lambda 函数代码包

当这些资源之间存在命名冲突或权限不一致时，就容易出现 AccessDenied 错误。通过完全清理旧资源并重新部署，可以确保权限系统的一致性。

总结

AWS 权限问题往往看似复杂，但通过系统性的资源清理和重新部署通常可以解决。理解 SST 的资源管理机制有助于快速定位和解决部署问题。对于生产环境，建议建立完善的部署前检查清单，包括资源清理、权限验证等步骤，以确保部署过程的顺利进行。