通过单个 CloudFront 分配支持 HTTPS URL 重定向 [英] Supporting HTTPS URL redirection with a single CloudFront distribution

问题描述

我有一个域 formulagrid.com.

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

I am using AWS S3 to host it as a static website. My problem was that I wanted to redirect the www subdomain to the bare domain like so:

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

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

Amazon provides URL redirecting from S3 bucket to S3 bucket if both are setup for static website hosting.

所以我必须做的是设置两个存储桶:

So what I had to do was set up two buckets:

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

• formulagrid.com - actual website
• www.formulagrid.com - exists solely to redirect to the actual website

如果您仅通过 HTTP 进行操作，这完全没问题，但 S3 绝对不支持 HTTPS.

This works perfectly fine if you're operating only over HTTP, but S3 has absolutely no support for HTTPS.

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

The way that one can use HTTPS to connect to an S3 static website is by setting up a CloudFront distribution in front of an S3 bucket. CloudFront, however, while it does provide HTTPS, mainly exists to function as a CDN.

最初，我在保存实际站点的 S3 存储桶前面设置了一个 CloudFront 分配.一切似乎都可以正常运行:该站点分布在 CDN 上，具有 HTTPS，并且 HTTP 重定向到 HTTPS.

Initially, I had a single CloudFront distribution setup in front of the S3 bucket holding the actual site. Everything seemed operational: the site was distributed over the CDN, it had HTTPS, and HTTP redirected to HTTPS.

有一个例外.

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

• https://www.formulagrid.com was a completely broken page

在尝试查找错误源头一段时间后，我意识到这是因为它没有通过 CDN，并且尝试通过 HTTPS 访问 S3 不起作用.

After trying to find the source of the error for a while, I realized it's because it wasn't going through the CDN, and trying to access S3 over HTTPS doesn't work.

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

Finally, what I ended up having to do was provision another distribution to sit in front of the www S3 bucket so it was accessible over HTTPS. This is where my concerns come in because, like I mentioned earlier, CloudFront's main purpose is to be a CDN.

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

It doesn't make any sense to me to have a CDN sit in front of a url that just redirects to another. Also it brings up the question of whether I would be double charged for every request that hits the www subdomain because it'd hit the other CloudFront distribution after being redirected.

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

This is frustrating because I'm trying to do a "serverless" architecture using Lambda, and having to provision an EC2 instance just to do url rewriting isn't something I want to do unless it's my last resort.

如果 Amazon 提供任何形式的 URL 重写或者如果 CloudFront 本身进行重定向，解决方案将是微不足道的，但据我所知，这两种都不存在(如果有，请告诉我).

The solution would be trivial if Amazon offered any form of URL rewriting or if CloudFront itself did redirecting, but neither of these exist as far as I know (let me know if they do).

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

I'm new to AWS so I'm hoping someone with more experience can point me in the right direction.

推荐答案

你的想法太狭隘了——这个设置没有任何问题.

You're thinking too narrowly -- there's nothing wrong with this setup.

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

The solution would be trivial if Amazon offered any form of URL rewriting

他们做了——空桶.

S3 完全不支持 HTTPS.

S3 has absolutely no support for HTTPS.

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

Not for web site hosted buckets, no... but CloudFront does.

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

CloudFront is not just a CDN. It's also an SSL offloader, Host: header rewriter, path prepender, geolocator, georestrictor, secure content gateway, http to https redirector, error page customizer, root page substituter, web application firewall, origin header injector, dynamic content gzipper, path-based multi-origin http request router, viewer platform identifier, DDoS mitigator, zone apex alias target... so don't get too hung up on "CDN" or on the fact that you're stacking one service in front of another -- CloudFront was designed, in large part, to complement S3. They each specialize in certain facets of storage and delivery.

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

So, you did it right... most of it, anyway... Create a bucket, configure it for web site hosting, set it to redirect all requests to another site (the non-www) and put a CloudFront distribution in front of it -- using the web site endpoint URL for with bucket in CloudFront, not the one from the drop-down list -- configured with high TTLs so that CloudFront will send a minimal number of requests to S3 then put your (free!) SSL certificate from Amazon Certificate Manager. HTTPS alternate domain routing: solved. No servers, no troubleshooting, and cheap. The only charges are the usage -- there is no background recurring charge as there would be with servers.

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

Extra credit: configure the redirecting CloudFront distribution for the cheapest rate tier. Redirects from more expensive locations will either be routed to a cheaper edge location or -- at CloudFront's option -- may be served out of a higher cost location but billed at the lower rate.

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

Note that most of the time, CloudFront should serve the redirects from S3 from it's cache... and when you configure a bucket to redirect all requests to another hostname, the redirect is a 301 permanent redirect -- which browsers are supposed to cache, themselves.

这篇关于通过单个 CloudFront 分配支持 HTTPS URL 重定向的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！