Amazon S3 路径弃用计划

上周，我们相当低调地（事实上是过于低调地）宣布了我们的计划，准备缓慢而谨慎地弃用用于指定 S3 存储桶中对象地址的基于路径的访问模型。为了撰写此博文，我花了一些时间与 S3 团队交谈，以便更好地了解情况。我了解到的情况如下…

我们在 2006 年初推出了 S3。Jeff Bezos 最初提出的 S3 规范非常简洁 – 他想在 Internet 中使用 malloc（C 程序的关键内存分配功能）。以此为起点，S3 已经发展到现在可以存储数万亿个对象，并且每秒可处理针对这些对象的数百万个请求。在过去的 13 年中，我们为 S3 增添了许多新的存储选项、功能和安全控制措施。

旧与新的比较

S3 目前支持两种不同的寻址模型：路径式和虚拟托管式。让我们快速了解一下这两种模型。路径式模型看起来是这样的（全局 S3 终端节点）：

https://s3.amazonaws.com/jbarr-public/images/ritchie_and_thompson_pdp11.jpeg

https://s3.amazonaws.com/jeffbarr-public/classic_amazon_door_desk.png

或这样的（区域 S3 终端节点之一）：

https://s3-us-east-2.amazonaws.com/jbarr-public/images/ritchie_and_thompson_pdp11.jpeg

https://s3-us-east-2.amazonaws.com/jeffbarr-public/classic_amazon_door_desk.png

在此示例中，jbarr-public 和 jeffbarr-public 是存储桶名称；/images/ritchie_and_thompson_pdp11.jpeg 和 /jeffbarr-public/classic_amazon_door_desk.png 是对象键。

即使这些对象由不同的 AWS 账户拥有并位于不同的 S3 存储桶中（还可能位于不同的 AWS 区域中），但它们都位于 DNS 子域 s3.amazonaws.com 中。在我们查看等效的虚拟托管式引用时，请记住这一点（尽管您可能认为它们是“新的”，但它们至少从 2010 年就开始存在了）：

https://jbarr-public.s3.amazonaws.com/images/ritchie_and_thompson_pdp11.jpeg

https://jeffbarr-public.s3.amazonaws.com/classic_amazon_door_desk.png

这些 URL 引用相同的对象，但这些对象现在位于不同的 DNS 子域中（分别在 jbarr-public.s3.amazonaws.com 和jeffbarr-public.s3.amazonaws.com 中）。虽然差别很小，但非常重要。在使用 URL 引用对象时，DNS 解析用于将子域名映射到 IP 地址。在路径式模型中，子域始终是 s3.amazonaws.com 或其中一个区域终端节点；在虚拟托管式模型中，子域特定于存储桶。这种额外等级的终端节点特异性是打开 S3 许多重要改进之门的关键。

除旧

针对我们上周宣布的原始弃用计划的反馈，我们将做出重大更改。下面是执行摘要：

原始计划 – 对路径式模型的支持将于 2020 年 9 月 30 日终止。

修订后的计划 – 2020 年 9 月 30 日或之前创建的存储桶将继续支持路径式模型。在该日期之后创建的存储桶必须使用虚拟托管模型引用。

我们迁移到虚拟托管引用的原因有二：

首先，我们预计会在数十个区域拥有数十亿个存储桶，因此随着时间推移，将所有传入请求直接路由到一小组终端节点会越来越没有意义。在这个集中式模型中，DNS 解析、扩展、安全性和流量管理（包括 DDoS 防护）更具挑战性。在出现问题时，虚拟托管模型能够缩小影响区域（我们在内部称之为“爆炸半径”）；这有助于我们提高可用性和性能。

其次，团队还在开发大量强大功能，其中许多功能需要使用独特的虚拟托管式子域。迁移到此模型将使您在发布这些新功能后立即从中受益。例如，我们计划弃用某些最陈旧的安全密码和版本（稍后将详细介绍）。如果您使用的是虚拟托管引用，则弃用过程会更简单、更顺畅（无论是对您还是对我们都是如此）。

布新

举例来说，使用虚拟托管引用时可能实现的一项功能是，我们正在考虑为您提供对每个存储桶的安全配置（包括密码和密码版本）的更多控制。如果您有自己的想法，请随时与我们联系。

向前迈进

以下是关于我们的计划的一些信息：

识别路径式引用 – 您可以使用 S3 访问日志（查找 Host Header 字段）和 AWS CloudTrail 数据事件（查找 requestParameters 条目的 host 元素）识别正在进行路径式请求的应用程序。

编程性访问 – 如果您的应用程序使用某个 AWS 开发工具包 访问 S3，则除了确保您的开发工具包是最新版本之外，您无需执行任何操作。SDK 已经对 S3 使用虚拟托管引用，除非存储桶名称包含一个或多个“.”字符。

包含点的存储桶名称 – 请务必注意，包含“.”字符的存储桶名称对于网站托管和其他使用案例完全有效。但是，TLS 和 SSL 证书存在一些已知问题。我们正在努力制定计划来支持虚拟托管对这些存储桶的请求，并将在 2020 年 9 月 30 日之前分享详细信息。

不可路由的名称 – 某些在 URL 的路径组件中有效的字符不适合作为域名的一部分。此外，路径区分大小写，但域名和子域名不区分大小写。自去年以来，我们一直在对新的存储桶名称实施更严格的规定。如果您的数据位于具有不可路由名称的存储桶中，并且您想要切换到虚拟托管请求，则可以使用新的 S3 批处理操作功能来移动数据。但是，如果这个选项不可行，请联系 AWS 开发人员支持。

文档 – 我们计划更新 S3 文档，以鼓励所有开发人员构建使用虚拟托管请求的应用程序。虚拟托管文档是一个很好的起点。

我们可随时为您提供帮助

S3 团队一直与我们的一些客户合作来帮助他们迁移，他们已准备好与更多客户合作。

我们的目标是使本次弃用顺利平稳，我们希望尽可能帮助减少您可能产生的任何成本！ 如果您有任何问题、疑问或疑虑，请随时与我们联系。

作者介绍：

Jeff Barr

AWS 首席布道师； 2004 年开始发布博客，此后便笔耕不辍。

本文转载自 AWS 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/amazon-s3-path-deprecation-plan-the-rest-of-the-story/