AWS S3 virtual-hosted-style 与 path-style 的区别

本文简单的记录下 s3 virtual-hosted-style 和 path-style 的区别。

一开始 s3 的路径只有 path-style ：

https://s3.region-code.amazonaws.com/bucket-name/key-name

即 endpoint 后面 https://s3.region-code.amazonaws.com 第一个斜线紧跟的就是 bucket 名称。

之后 virtual-hosted-style 变成了：

https://bucket-name.s3.region-code.amazonaws.com/key-name

即 bucket 名称挪到到了前面。

Path-style 存在的问题

• 不 scale，一个 region 内的所有 bucket 流量都会先打到 https://s3.region-code.amazonaws.com 这个域名上。你能做的也只是对这个域名进行负载均衡。
• 用户没法通过 cname 绑定自定义域名。
• favicon.ico ，robots.txt 这种本该在 root 路径下的文件，都无法被正确识别。因为你 root 路径下第一级目录永远都是 bucket 名称。

Path-style 的问题没那么绝对，不是说无论如何都解决不了，只是相对不好解决。

Virtual-hosted-style 的优点

• scale，我通过 dns 可以给每个 bucket 的流量分摊到不同 IP 的机器上面，即不同 bucket 绑定不同的 A 记录就可以了。
• 用户可以绑定自己的域名。比如我通过 cname 绑定了 cdn.xxxx.org 到 https://bucket-name.s3.region-code.amazonaws.com 上面。这样后续我直接通过 cdn.xxxx.org 就能访问我的 bucket。
• favicon.ico ，robots.txt 这种文件也能被正确识别了，因为它就是在 root 路径下。利好静态博客党。

受制于 SSL 的问题，如果你用了 virtual-hosted-style，你的 bucket 名称不能带点。

比如你的 bucket 名称是 dot.dot，那么你整个 bucket 路径就是 https://dot.dot.s3.region-code.amazonaws.com。但是 SSL 的泛域名解析只能到二级域名，更深层级到不了。

When you’re using virtual-hosted–style buckets with SSL, the SSL wildcard certificate matches only buckets that do not contain dots (.). To work around this limitation, use HTTP or write your own certificate-verification logic. For more information, see Amazon S3 Path Deprecation Plan on the AWS News Blog.

不过其实现在貌似是支持 bucket 带点了，我用 AWS-JAVA-SDK-v2 测试是支持的，AWS-JAVA-SDK-v1 仍然不支持。

小结

这也是为什么在 minio 这一类自建 s3 服务中，用户都需要显式的设置使用 path-style 模式访问。因为 minio 中用的都还是 http://127.0.0.1:9000/bucket-name/key-name 这种路径。毕竟私有化部署的时候，virtual-hosted-style 没有太大优势，而且如果用了 virtual-hosted-style，你还需要额外配置 DNS 服务，属于吃力不讨好，没多大收益。

参考文献

https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html

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