通过单个 CloudFront 分配支持 HTTPS URL 重定向

Posted 2023-03-06

【中文标题】通过单个 CloudFront 分配支持 HTTPS URL 重定向

【英文标题】：Supporting HTTPS URL redirection with a single CloudFront distribution

【发布时间】：2016-06-07 11:39:11

【问题描述】：

我有一个域名formulagrid.com。

我正在使用 AWS S3 将其托管为静态网站。我的问题是我想将 www 子域重定向到裸域，如下所示：

https://www.formulagrid.com -> https://formulagrid.com http://www.formulagrid.com -> https://formulagrid.com

如果两者都设置为静态网站托管，亚马逊会提供从 S3 存储桶到 S3 存储桶的 URL 重定向。

所以我要做的就是设置两个桶：

formulagrid.com - 实际网站 www.formulagrid.com - 仅用于重定向到实际网站

如果您仅通过 HTTP 进行操作，这非常有效，但 S3 绝对不支持 HTTPS。

使用 HTTPS 连接到 S3 静态网站的方法是在 S3 存储桶前设置 CloudFront 分配。然而，CloudFront 虽然提供 HTTPS，但主要是作为 CDN 存在的。

最初，我在包含实际站点的 S3 存储桶前面设置了一个 CloudFront 分配设置。一切似乎都可以运行：该站点通过 CDN 分发，它具有 HTTPS，并且 HTTP 重定向到 HTTPS。

有一个例外。

https://www.formulagrid.com 是一个完全损坏的页面

找了一阵子错误的源头，才发现是因为没有经过CDN，尝试通过HTTPS访问S3不起作用。

最后，我最终不得不做的是在www S3 存储桶前面配置另一个发行版，以便可以通过 HTTPS 访问它。这就是我担心的地方，因为正如我之前提到的，CloudFront 的主要目的是成为 CDN。

将 CDN 放在只是重定向到另一个 URL 的 URL 前面对我来说没有任何意义。它还提出了一个问题，即我是否会为每个到达 www 子域的请求支付双倍费用，因为它会在重定向后到达其他 CloudFront 分配。

这令人沮丧，因为我正在尝试使用 Lambda 构建“无服务器”架构，并且必须配置 EC2 实例来进行 url 重写不是我想做的事情，除非这是我最后的手段。

如果 Amazon 提供任何形式的 URL 重写或 CloudFront 本身进行重定向，那么解决方案将是微不足道的，但据我所知，这些都不存在（如果有，请告诉我）。

我是 AWS 新手，所以我希望有更多经验的人可以为我指明正确的方向。

【参考方案1】：

你的想法太狭隘了——这个设置没有错。

如果亚马逊提供任何形式的 URL 重写，解决方案将是微不足道的

他们确实——空桶。

S3 完全不支持 HTTPS。

不适用于网站托管的存储桶，不...但 CloudFront 可以。

CloudFront 不仅仅是一个 CDN。它也是一个 SSL 卸载程序、Host: 标头重写器、路径前置器、地理定位器、地理限制器、安全内容网关、http 到 https 重定向器、错误页面定制器、根页面替代器、Web 应用程序防火墙、原始标头注入器、动态内容 gzipper、路径-基于多源 http 请求路由器、查看器平台标识符、DDoS 缓解器、区域顶点别名目标......所以不要太沉迷于“CDN”或您将一项服务堆叠在另一个服务前面的事实 - - CloudFront 的设计在很大程度上是为了补充 S3。他们每个人都专注于存储和交付的某些方面。

所以，你做对了......无论如何，大部分......创建一个存储桶，将其配置为网站托管，将其设置为将所有请求重定向到另一个站点（非 www）并放置一个 CloudFront在它前面分发——使用 CloudFront 中的存储桶的网站端点 URL，而不是下拉列表中的那个——配置高 TTL，以便 CloudFront 向 S3 发送最少数量的请求，然后将您的 (免费！）来自 Amazon Certificate Manager 的 SSL 证书。 HTTPS 备用域路由：已解决。没有服务器，没有故障排除，而且便宜。 仅 费用是使用费——没有像服务器那样的后台经常性费用。

额外积分：为最便宜的费率层配置重定向 CloudFront 分配。来自更昂贵位置的重定向将被路由到更便宜的边缘位置，或者——根据 CloudFront 的选择——可以从成本更高的位置提供服务，但以较低的费率计费。

请注意，大多数情况下，CloudFront 应该从其缓存中提供来自 S3 的重定向...当您配置存储桶以将所有请求重定向到另一个主机名时，重定向是 301永久 em> 重定向 -- 哪些浏览器应该自己缓存。

【讨论】：

感谢您的回答！你说的我基本上都做了。我有一个问题。对于被重定向的请求，它不会转到CDN -> empty S3 -> CDN -> S3 吗？这是我的主要问题。

CloudFront 缓存来自空存储桶的重定向后，它将是 CF > CF > S3，如果缓存了 S3 站点内容，则只是 CF > CF。在初始登陆后，它们被重定向到裸域，随后的链接会将它们保留在那里......这与 CF 具有重定向到不同域的本机能力的表现应该没有什么不同——那些初始请求仍然会命中 CF 两次，因为重定向会将浏览器带到浏览器将始终假定为不同位置的位置，因为主机名会发生变化......无论它实际上是否是同一台机器。

是的，每个 HTTPS 请求额外支付 0.000001 美元。 （每百万美元）。

哈哈，所以不是一个真正的问题。即使它更昂贵，它仍然可能比 EC2 服务器更便宜来进行重定向。谢谢。

...但是您必须支付 somebody 费用才能进行重定向。如果同一个发行版处理它，它仍然需要第二个请求。