AWS S3 推出账户级区域命名空间，结束存在长达 18 年之久的全局存储桶名称冲突

近日，亚马逊云科技宣布为 S3 通用存储桶推出账户级区域命名空间，解决了困扰开发者 18 年之久的一个限制性问题——全局存储桶名称冲突。团队现在可以创建名称可预测的存储桶，有效范围限定在其亚马逊云科技账户和区域之内，从而简化了基础设施即代码模板。

自 2006 年以来，S3 全局命名空间一直是一个令人头疼的问题。当"mybucket"在全球任何地方被占用后，你就只能被迫使用"mybucket-prod-v2-final"或更糟糕的名称。基础设施团队只能采用一些变通方法：确定性哈希、加密项目名称及解密脚本、在 Terraform 中添加随机后缀、 CloudFormation 伪随机 ID。所有这些都只是为了保证在生产环境中创建存储桶时不会因 "BucketAlreadyExists" 而失败。

账户级区域命名空间改变了规则。现在，存储桶命名遵循 {前缀}-{账户 ID}-{区域}-an 的格式，其中 -an 表示账户级区域后缀。亚马逊云科技账户 123456789012 可以创建"mybucket-123456789012-us-east-1-an"，而无需检查是否已被其他人占用。12 位账户 ID 充当了天然的分隔符，其他账户尝试使用完全相同的后缀时会被自动拒绝。

图片来源：亚马逊云科技新闻博客

这对基础设施即代码尤为重要。CloudFormation 模板现在可以使用 BucketNamePrefix 属性，而无需拼接伪参数并祈祷它是唯一的：

yamlBucketNamePrefix: 'amzn-s3-demo-bucket'BucketNamespace: 'account-regional'

CloudFormation 会自动处理账户 ID 和区域。Terraform 和 Pulumi 模板也能得到类似的简化。多账户组织可以在数百个亚马逊云科技账户中强制执行一致的命名规范，而无需担心冲突。

安全团队通过新增的 IAM 条件键 s3:x-amz-bucket-namespace 获得了强制执行能力。组织可以通过服务控制策略要求所有新建的存储桶使用账户级区域命名，从而防止团队退回到使用容易冲突的全局命名空间，这简化了合规审计。只要筛选出不带 -an 后缀的存储桶，你就可以知道哪些是旧存储桶了。

除命名冲突之外，全局命名空间还带来了其他的安全风险。 Reddit 上有一位评论者指出：

全局命名空间构成了一种安全风险，可能导致混淆代理攻击。虽然这项新增的强制措施目前在大多数区域都已经可以使用，但在中东区域尚未开启。此更改有助于自动化许多团队已经在其基础设施即代码中使用的命名约定，从而确保唯一性。

亚马逊云科技正在追赶 Azure 和 Google Cloud 从一开始就实现了的模式。Azure Blob Storage 始终将存储账户名称限定在订阅级，而Google Cloud Storage 始终将存储桶限定在项目级。亚马逊云科技坚持使用全局命名空间近二十年，现在才提供账户级替代方案（作为可选功能，而非破坏性变更）。

有证据表明，开发者一直在主动绕过这些限制。一个 2024 年的 Hacker News 讨论帖显示，各团队使用确定性哈希和加密项目名称来避免全局命名空间问题。有一条评论总结了这种模式：

现在，每次我做 AWS 项目时，所有存储桶名称通常都命名为 <项目>-<从自种子值生成的确定性哈希>。

CLI 和 SDK 支持非常简单。AWS CLI 采用 --bucket-namespace account-regional 标志，而 Python Boto3 SDK 在 create_bucket() 调用中添加了 BucketNamespace 参数。账户 ID 可通过 STS GetCallerIdentity 获取。

文档强调，这不会破坏现有部署。全局命名空间存储桶将继续像以前一样工作。此功能适用于希望在 CI/CD 管道中实现可预测的存储桶创建、在多账户组织中实现命名一致性或厌倦处理 BucketAlreadyExists 异常的团队。

最后，此功能目前在 35 个亚马逊云科技区域内可用，不收取额外费用，但在中东（巴林）和中东（阿联酋）尚不可用。现有存储桶无法重命名；此功能仅适用于新存储桶。它仅限于通用存储桶；S3 表存储桶、目录存储桶和向量存储桶已经是在账户级或区域级命名空间中。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：https://www.infoq.com/news/2026/03/s3-account-regional-namespaces/