我想知道 getbucketlocation 是如何工作的。是否有一个集中存储来保存所有存储桶位置映射？在 2019 年 3 月 20 日之前启动的区域中创建的存储桶可通过https://bucket.s3.amazonaws.com 访问因此，如果我有一个存储桶，那么我使用https://bucket.s3.amazonaws.com/xxxxx 访问该存储桶，然后它将查询该区域的集中映射存储，然后将我的请求路由到正确的地区？
【问题讨论】：
标签： amazon-web-services amazon-s3
us-east-1 中有一个集中式数据库，所有其他区域都有它的副本。这用于GET bucket location API 调用以及列表存储桶。
但这不用于请求路由。
请求路由是一个简单的系统——数据库是 DNS。为每个存储桶自动创建了一条 DNS 记录 - 一个指向存储桶区域中 S3 终端节点的 CNAME。
还有一个指向 us-east-1 的 *.s3.amazonaws.com DNS 通配符...因此，当新存储桶位于 us-east-1 中时，这些主机名会立即起作用。否则，在创建特定存储桶记录（覆盖通配符）之前会有延迟，并且发送到该端点的请求将到达 us-east-1，后者将以 HTTP 重定向响应该存储桶的适当区域端点。
他们可能会停止为新区域执行此操作的原因可能与扩展考虑有关，并且它不再像以前那样有用。当强制签名版本 4 身份验证成为 2014 年及以后推出的区域规则时，${bucket}.s3.amazonaws.com URL 样式在很大程度上变得无关紧要，因为您无法在不知道请求的目标区域的情况下生成有效的 Sig V4 URL。 Signature V2 签名不要求生成签名的代码知道该区域。
S3 在历史上也没有区域端点的一致主机名。例如，在 us-west-2 中，区域端点曾经是 ${bucket}.s3-us-west-2.amazonaws.com，但在 us-east-2 中，区域端点一直是 ${bucket}.s3.us-east-2.amazonaws.com...您发现区别了吗？在s3 之后是- 而不是.，因此构建区域 URL 还需要了解不同区域的随机规则。更随机的是，us-east-1 的特定于区域的端点实际上是 ${bucket}.s3-external-1.amazonaws.com，当然，除非您有理由使用 ${bucket}.s3-external-2.amazonaws.com（这有一个遗留原因——当时这是有道理的，但那是很久以前的事了。）
值得称赞的是，他们修复了这个问题，现在所有区域都支持${bucket}.s3.${region}.amazonaws.com，但（也值得称赞的是）旧的 URL 在旧的区域仍然可以使用，即使现在已经标准化。
【讨论】：