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 。