AWS Cloudfront 作为具有自定义域的 Heroku 站点的 CDN [英] AWS Cloudfront as CDN for Heroku Site with Custom Domain

问题描述

最近，我从 AWS Route 53 (brianpatrickhummel.com) 购买了一个域来托管个人投资组合.投资组合站点已启动并运行，使用 S3 存储桶和 Cloudfront 作为 CDN.在投资组合网站上，访问者可以预览我构建的一些应用程序，这些应用程序使用 iframe 元素在现场启动，我注意到我的 Heroku 部署的应用程序需要 10-20 秒才能加载，因为这些网站上的访问者很少平均，没有 CDN 服务.

Recently, I bought a domain from AWS Route 53 (brianpatrickhummel.com) to host a personal portfolio. The portfolio site is up and running, using an S3 bucket and Cloudfront as a CDN. On the portfolio site, visitors are able to preview some apps that I built, which launch in-site using iframe elements, and I noticed that my Heroku-deployed apps take 10-20 seconds to load, since those sites have very few visitors on average and have no CDN service.

因此，我开始研究使用 AWS Cloudfront 作为 CDN.我从一个 Heroku 应用程序开始，添加了一个自定义域，现在配置如下:

Therefore, I began researching using AWS Cloudfront as a CDN. I began with one Heroku app, adding a custom domain which is now configured as such:

Domain Name: burger.brianpatrickhummel.com
DNS Target: burger.brianpatrickhummel.com.herokudns.com

最后一步是将您的应用的 DNS 提供商配置为指向 Heroku 提供的 DNS 目标."在这一步和正确配置 Cloudfront 发行版之间，我陷入了混乱的漩涡.我不确定在 Cloudfront、Route 53 或两者中进行某些 DNS/CNAME 更改的位置.

The last step is to "configure your app’s DNS provider to point to the Heroku-supplied DNS Target." Between this step and properly configuring a Cloudfront distribution, I have run myself into a spiral of confusion. I'm uncertain as to of where I make certain DNS/CNAME changes, in Cloudfront, Route 53 or both.

没有太多专门与这三种技术(Heroku、Cloudfront、Route 53)相关的在线文档，我在这三篇文章之间花了很多时间，但无济于事:

There isn't much online documention specifically related to these three technologies (Heroku, Cloudfront, Route 53) and I've spent much time bouncing between these three articles, to no avail:

Heroku - 使用 Amazon CloudFront CDN

为您的 Heroku 应用配置 Amazon Route 53 DNS

我相信必要的更改本质上很简单，并且非常感谢那些可能对这种特定配置有经验的人的任何见解.

I'm confident that the necessary changes are simple in nature and would greatly appreciate any insight from those who might have experience with this particular configuration.

---更新---

我还有最后一个问题，现在我的所有 Heroku 应用程序都通过 Cloudfront 成功路由，我意识到所有具有生成 POST HTTP 请求的组件的应用程序都会收到 403 - 禁止错误.这与相应 AJAX 调用中的相对 URL 有什么关系:

---UPDATE---

I have one last question, now that I have all of my Heroku apps successfully routing through Cloudfront, I have realized that all of the apps which have components that generate POST HTTP requests receive 403 - forbidden errors. Does this have anything to do with the relative URL in the respective AJAX calls:

$(document).on("click", ".saveButton", function () {
  var thisId = $(this).attr("id");
  $.ajax({
    method: "POST",
    url: "/save/" + thisId
  }).done(function () {} 

我在 Cloudfront 文档中看到以下内容:

I see the following in the Cloudfront documentation:

CloudFront 始终缓存对 GET 和 HEAD 请求的响应.您还可以将 CloudFront 配置为缓存对 OPTIONS 请求的响应.CloudFront 不会缓存对使用其他方法的请求的响应.

CloudFront always caches responses to GET and HEAD requests. You can also configure CloudFront to cache responses to OPTIONS requests. CloudFront does not cache responses to requests that use the other methods.

与成功发送请求相比，处理来自 Heroku 应用程序服务器的响应的问题更多吗?

Is this more of a problem with handling the responses from the server of the Heroku app than it is an issue with successfully sending the request?

-- 更新 2 --
我认为这与基于 Cloudfront 文档中的此声明的 HTTP/HTTPS 有关:

-- UPDATE 2 --
I'm thinking that this has to do with HTTP/HTTPS based on this statement in the Cloudfront Documentation:

CloudFront 不会将 DELETE、OPTIONS、PATCH、POST 或 PUT 请求从 HTTP 重定向到 HTTPS.如果您将缓存行为配置为重定向到 HTTPS，CloudFront 会使用 HTTP 状态代码 403(禁止)响应该缓存行为的 HTTP DELETE、OPTIONS、PATCH、POST 或 PUT 请求.

CloudFront doesn't redirect DELETE, OPTIONS, PATCH, POST, or PUT requests from HTTP to HTTPS. If you configure a cache behavior to redirect to HTTPS, CloudFront responds to HTTP DELETE, OPTIONS, PATCH, POST, or PUT requests for that cache behavior with HTTP status code 403 (Forbidden).

Heroku 声明:

如果您想使用 SSL 为 Cloudfront 资产提供服务，您只需在 Amazon 提供给您的分发域上使用 HTTPS.请注意，虽然您可以为此目的创建 CNAME，但通过 CNAME 和 SSL 提供 Cloudfront 资产会产生附加成本.

If you are wanting to serve Cloudfront assets using SSL you can simply use HTTPS on the distribution domain given to you by Amazon. Note, whilst you can create CNAME’s for this purpose, serving Cloudfront assets over your CNAME and SSL has an attached cost.

在 AWS Cloudfront Distribution Cache Behavior 设置中，您可以选择从三个选项中选择查看者协议政策:

In AWS Cloudfront Distribution Cache Behaviour settings, you can choose for the Viewer Protocol Policy from three options:

如果您希望 CloudFront 允许查看者使用 HTTP 或 HTTPS 访问您的 Web 内容，请指定 HTTP 和 HTTPS.如果您希望 CloudFront 将所有 HTTP 请求重定向到 HTTPS，请指定将 HTTP 重定向到 HTTPS.如果您希望 CloudFront 需要 HTTPS，请指定仅 HTTPS.

If you want CloudFront to allow viewers to access your web content using either HTTP or HTTPS, specify HTTP and HTTPS. If you want CloudFront to redirect all HTTP requests to HTTPS, specify Redirect HTTP to HTTPS. If you want CloudFront to require HTTPS, specify HTTPS Only.

Cloudfront 文档继续指出:

The Cloudfront doc goes on to note:

将 HTTP 重定向到 HTTPS查看器可以使用这两种协议，但 HTTP 请求会自动重定向到 HTTPS 请求.CloudFront 返回 HTTP 状态代码 301(永久移动)以及新的 HTTPS URL.然后，查看器使用 HTTPS URL 将请求重新提交给 CloudFront.

Redirect HTTP to HTTPS Viewers can use both protocols, but HTTP requests are automatically redirected to HTTPS requests. CloudFront returns HTTP status code 301 (Moved Permanently) along with the new HTTPS URL. The viewer then resubmits the request to CloudFront using the HTTPS URL.

当查看者发出重定向到 HTTPS 请求的 HTTP 请求时，CloudFront 会为这两个请求收费.对于 HTTP 请求，费用仅针对请求和 CloudFront 返回给查看器的标头.对于 HTTPS 请求，费用是针对请求以及源头返回的标头和对象.

When a viewer makes an HTTP request that is redirected to an HTTPS request, CloudFront charges for both requests. For the HTTP request, the charge is only for the request and for the headers that CloudFront returns to the viewer. For the HTTPS request, the charge is for the request, and for the headers and the object returned by your origin.

仅限 HTTPS观看者只有在使用 HTTPS 时才能访问您的内容.如果查看器发送 HTTP 请求而不是 HTTPS 请求，CloudFront 将返回 HTTP 状态代码 403(禁止)并且不返回对象.

HTTPS Only Viewers can access your content only if they're using HTTPS. If a viewer sends an HTTP request instead of an HTTPS request, CloudFront returns HTTP status code 403 (Forbidden) and does not return the object.

很遗憾，我不知道托管个人网站会有多复杂！

Good grief, I had no idea how complicated it would be to host a personal website!

推荐答案

域名:burger.brianpatrickhummel.com

Domain Name: burger.brianpatrickhummel.com

您将在 Route 53 中将此指向 CloudFront...但在此之前，您需要创建一个新的 CloudFront 分配并将该主机名配置为分配的备用域名.

You will point this to CloudFront, in Route 53... but before you can do that, you need to create a new CloudFront distribution and configure that hostname as an Alternate Domain Name for the distribution.

DNS 目标:burger.brianpatrickhummel.com.herokudns.com

DNS Target: burger.brianpatrickhummel.com.herokudns.com

在创建分配 CloudFront 时将此配置为源域名.

Configure this as the Origin Domain Name when creating the distribution CloudFront.

在缓存行为设置中，将 Host 标头列入白名单，以便 Heroku 了解请求是针对哪个站点的.

In the Cache Behavior settings, whitelist the Host header so that Heroku will understand which site the request is for.

这篇关于AWS Cloudfront 作为具有自定义域的 Heroku 站点的 CDN的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！