AWS Cloudfront 作为具有自定义域的 Heroku 站点的 CDN

Question

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

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

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

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

没有太多与这三种技术（Heroku、Cloudfront、Route 53）相关的在线文档，我花了很多时间在这三篇文章之间跳来跳去，但无济于事：

Heroku - 使用 Amazon CloudFront CDN

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

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

---更新---

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

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

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

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

与成功发送请求相比，处理来自 Heroku 应用程序服务器的响应是否更像是一个问题？

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

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

Heroku 指出：

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

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

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

Cloudfront 文档继续指出：

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

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

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

真悲哀，我不知道托管个人网站会有多复杂！

Answer 1

域名：burger.brianpatrickhummel.com

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

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

创建分配 CloudFront 时，将此配置为源域名。

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

Answer 2

这是我会做的步骤，

由于您已经在 53 号公路上，

从 ACM 获取免费 SSL

确认您对域电子邮件地址的 SSL 验证。 确保它看起来像下面的绿色，

也使用 SSL 和 CNAME 将其分配给 CloudFront Endpoint

您还将看到将在 Route53 中为此 SSL 端点自动创建一个 cname。

如果您 p​​ing burger.brianpatrickhummel.com，它应该从云前端响应。

现在在 Cloudfront 中设置 Origins 以将其指向具有所需的所有缓存设置的端点。 如果不需要缓存设置，可以全部设置为0，这样cloudfront就不会缓存任何数据。

在您的 Cloudront 模式中，确保末尾有 *，以便它匹配所有 url 模式以将其转发到您的端点。

如果您的端点需要保护，您可以从 Cloudfront 传入额外的标头，并确保请求来自 Cloudfront，而不是任何公共端点。

Answer 3

我不确定在 Cloudfront、Route 53 或两者中进行某些 DNS/CNAME 更改的位置

既然 Route53 是 DNS 服务（不是 CloudFront），那么您将在 Route53 中创建 CNAME 记录。 您想在 Route53 中创建一个 CNAME 记录，将您的子域指向 CloudFront。 然后，您需要将 CloudFront 配置为通过配置备用域名字段来了解它需要为该域提供服务。

Answer 4

似乎Host 不再被 heroku 信任和接受。 它将不再正确链接到该站点

请改用Origin Custom Header 。

自定义头的名称会经过一些解析和大小写更改，因此要对其进行调试，请添加此命令以打印请求中提供的相关头。

puts request.headers.env.reject { |key| key.to_s.include?('.') }

你应该在那里看到你的标题，但可能是不同的格式。

作为参考，我的标头是X-Request-ID （这是Heroku 推荐用于额外用途的），并将其转换为HTTP_X_REQUEST_ID 。