通过单个 CloudFront 分配支持 HTTPS URL 重定向
Supporting HTTPS URL redirection with a single CloudFront distribution
我有一个域 formulagrid.com。
我正在使用 AWS S3 将其托管为静态网站。我的问题是我想像这样将 www 子域重定向到裸域：
https://www.formulagrid.com -> https://formulagrid.comhttp://www.formulagrid.com -> https://formulagrid.com
Amazon 提供 URL 从 S3 存储桶到 S3 存储桶的重定向（如果两者都设置为静态网站托管）。
所以我要做的是设置两个存储桶：
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 前面对我来说没有任何意义。此外，它还提出了一个问题，即我是否会对每个命中 www 子域的请求收取双倍费用，因为它在重定向后会命中其他 CloudFront 分配。
这令人沮丧，因为我正在尝试使用 Lambda 构建 "serverless" 架构，并且必须提供一个 EC2 实例来进行 url 重写不是我想做的事情，除非这是我最后的选择。
如果 Amazon 提供任何形式的 URL 重写，或者如果 CloudFront 本身进行了重定向，那么解决方案将是微不足道的，但据我所知，这些都不存在（如果有，请告诉我）。
我是 AWS 的新手，所以我希望有更多经验的人能为我指明正确的方向。
你想得太狭隘了——这个设置没有错。
The solution would be trivial if Amazon offered any form of URL rewriting
他们有 -- 空桶。
S3 has absolutely no support for HTTPS.
不适用于网站托管的存储桶，不……但 CloudFront 可以。
CloudFront 不仅仅是一个 CDN。它也是一个 SSL 卸载器、Host: header 重写器、路径前置器、地理定位器、地理限制器、安全内容网关、http 到 https 重定向器、错误页面定制器、根页面替换器、Web 应用程序防火墙、origin header 注入器、动态内容 gzipper、path-based multi-origin http 请求路由器、查看器平台标识符、DDoS 缓解器、zone apex 别名目标...所以不要太在意 "CDN"或者您将一项服务堆叠在另一项服务之前这一事实——CloudFront 的设计在很大程度上是为了补充 S3。他们各自专注于存储和交付的某些方面。
所以，你做对了......大部分，无论如何......创建一个存储桶，将其配置为网站托管，将其设置为将所有请求重定向到另一个站点（non-www）并在其前面放置一个 CloudFront 分配——使用网站端点 URL 用于 CloudFront 中的存储桶，而不是 drop-down 列表中的那个——配置高 TTL，以便 CloudFront 将发送一个向 S3 发出最少数量的请求，然后从 Amazon Certificate Manager 中放置您的（免费！）SSL 证书。 HTTPS 备用域路由：已解决。没有服务器，没有故障排除，而且便宜。 仅 费用是使用费——没有像服务器那样的后台经常性费用。
额外功劳：为最便宜的费率层配置重定向 CloudFront 分配。来自更昂贵位置的重定向将被路由到更便宜的边缘位置，或者——根据 CloudFront 的选择——可能在成本更高的位置提供服务，但以更低的费率计费。
请注意，大多数时候，CloudFront 应该从它的缓存中提供来自 S3 的重定向...并且当您配置存储桶以将所有请求重定向到另一个主机名时，重定向是 301 永久 重定向——哪些浏览器应该自己缓存。
我有一个域 formulagrid.com。
我正在使用 AWS S3 将其托管为静态网站。我的问题是我想像这样将 www 子域重定向到裸域：
https://www.formulagrid.com -> https://formulagrid.comhttp://www.formulagrid.com -> https://formulagrid.com
Amazon 提供 URL 从 S3 存储桶到 S3 存储桶的重定向（如果两者都设置为静态网站托管）。
所以我要做的是设置两个存储桶：
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 前面对我来说没有任何意义。此外，它还提出了一个问题，即我是否会对每个命中 www 子域的请求收取双倍费用，因为它在重定向后会命中其他 CloudFront 分配。
这令人沮丧，因为我正在尝试使用 Lambda 构建 "serverless" 架构，并且必须提供一个 EC2 实例来进行 url 重写不是我想做的事情，除非这是我最后的选择。
如果 Amazon 提供任何形式的 URL 重写，或者如果 CloudFront 本身进行了重定向，那么解决方案将是微不足道的，但据我所知，这些都不存在（如果有，请告诉我）。
我是 AWS 的新手，所以我希望有更多经验的人能为我指明正确的方向。
你想得太狭隘了——这个设置没有错。
The solution would be trivial if Amazon offered any form of URL rewriting
他们有 -- 空桶。
S3 has absolutely no support for HTTPS.
不适用于网站托管的存储桶，不……但 CloudFront 可以。
CloudFront 不仅仅是一个 CDN。它也是一个 SSL 卸载器、Host: header 重写器、路径前置器、地理定位器、地理限制器、安全内容网关、http 到 https 重定向器、错误页面定制器、根页面替换器、Web 应用程序防火墙、origin header 注入器、动态内容 gzipper、path-based multi-origin http 请求路由器、查看器平台标识符、DDoS 缓解器、zone apex 别名目标...所以不要太在意 "CDN"或者您将一项服务堆叠在另一项服务之前这一事实——CloudFront 的设计在很大程度上是为了补充 S3。他们各自专注于存储和交付的某些方面。
所以，你做对了......大部分，无论如何......创建一个存储桶，将其配置为网站托管，将其设置为将所有请求重定向到另一个站点（non-www）并在其前面放置一个 CloudFront 分配——使用网站端点 URL 用于 CloudFront 中的存储桶，而不是 drop-down 列表中的那个——配置高 TTL，以便 CloudFront 将发送一个向 S3 发出最少数量的请求，然后从 Amazon Certificate Manager 中放置您的（免费！）SSL 证书。 HTTPS 备用域路由：已解决。没有服务器，没有故障排除，而且便宜。 仅 费用是使用费——没有像服务器那样的后台经常性费用。
额外功劳：为最便宜的费率层配置重定向 CloudFront 分配。来自更昂贵位置的重定向将被路由到更便宜的边缘位置，或者——根据 CloudFront 的选择——可能在成本更高的位置提供服务，但以更低的费率计费。
请注意，大多数时候，CloudFront 应该从它的缓存中提供来自 S3 的重定向...并且当您配置存储桶以将所有请求重定向到另一个主机名时，重定向是 301 永久 重定向——哪些浏览器应该自己缓存。