今天我們來聊聊如何設定 CloudFront 的 Origin，以及相關需要注意的情況。

設定 Origin 有幾個最基本的條件:

• 1. 必須是 HTTP Server，因為 CloudFront 目前只支援 HTTP Server 作為 Origin[1]
• 2. 必須要使用 DNS(FQDN[2]，可以由 DNS 域名查詢到即可，不要求一定要可以反查) 名稱，不能只是使用 IP。無論是IPv4 or IPv6 都不能直接作為 Origin.

所以，當使用 CloudFront 時，就可以拿以下當成 Origin:

- S3 bucket，S3 的 Static Website
- AWS ELB (Elastic Load Balancer)
- AWS MediaPackage/MediaTailor 的 Endpoint
- AWS API G/W 
- 其它各式各樣的 HTTP Server

那麼，知道基本要求後，我們來進一步看看 CloudFront 對 Origin 還有哪些設定。

支持的 HTTP & TLS Protocol 版本

• CloudFront 回 Origin 時，可以選擇 HTTP or HTTPS。HTTP 版本目前僅支援 HTTP/1.1。
• 如果是 TLS 版本，可以支持 SSLv3, TLSv1.0, TLSv1.1, TLSv1.2。但如果您的源站是 S3 Bucket，那麼限定會使用 TLSv1.2(也沒選項可以調整就是了)

Origin Shield

簡單版本: 如果不是極度追求 CacheHitRate(緩存命中率)，其實可以不用開。

複雜版本:

• 1. CloudFront 全球目前(2023.09)已有 400+ 個以上的 PoP。資料來源 - 2022.06
• 2. 為了提高緩存命中率，CloudFront 有個 REC (Regional Edge Cache) 的設計，同屬同一個 REC 範圍(地理距離較近)的 PoP，可以在這邊共享資料。如下圖:
     
• 3. 但 REC 彼此之間不會交換資料，所以 CloudFront 在 2020 年推出 Origin Shield，由客戶自行指定，把特定的 REC 「提升」(Promote)成一個特殊的節點，讓其它 REC 可以先來這邊拿資料。這樣只要這個 Origin Shield 有資料，其它 REC 就可以先來找他要，而減少將請求送往 Origin Server 的次數。
     **這是因為 Origin Server 可能很忙反應慢，比起回 Origin 再要一次資料，可以直接從 Origin Shield 拿資料的效率，綜合看來會比較好。除了可以讓不同 REC 之間共享緩存物件，也降低了 Origin 收到的請求數量，緩解 Origin 的壓力。
     

註: 如果請求不能緩存，又極度在乎 Latency，那麼不建議開啟使用 Origin Sheild.

Additional Settings

接下來我們來看 Additional Settings 裡面有哪些選項。

• Connection attempts: TCP 連線的參數，當 CloudFront 暫時無法連上 Origin 時，最多可以嘗試幾次，預設是 3 秒。
• Connection timeout: TCP 連線的參數，每次連線時，CloudFront 會等多久。預設數值為 10 秒。
  
• Response timeout: HTTP 請求的參數，當 CloudFront 將 HTTP 請求發給 Origin 時，可以等待多久，超過時間只能放棄。預設為 30 秒。
• Keep-alive timeout: TCP 連線的參數，當 CloudFront 收到 HTTP 回覆後，多久可以中斷跟 Origin 的 TCP 連線。預設為 5秒。

Origin Groups

這是一個很精巧且厲害的設計。CloudFront 可以設定多個 Origin，然後將多個 Origin 歸成一組，讓 CloudFront 在優先順序較高的 Origin 的回應特定錯誤代碼(Ex: HTTP 404)時，多一個再試一次的機會。

Origin 的問答集

• Q1. 請問上面的參數我需要調整嗎?
  Ans: 一般來說，維持預設就可以滿足大多數時候的需求。
• Q2. 我的 Origin 反應很慢，我想要讓加大 Response timeout，讓 CloudFront 多等久一點的時間可以嗎?
  Ans: 當然可以，但除非網站反應速度無法改進，不然更長的等待時間非常影響使用網站的體驗。根據我個人的經驗，如果你的 Origin 回應一個請求超過 10秒，那麼他很可能也會超過 30秒，甚至更久。拉長時間只是讓彼此傷害的時間更久。
• Q3. Keep-Alive 可以加大嗎? 加大有什麼好處，可以加到多大?
  Ans: 當然可以加大。Keep-Alive 加大的最大好處，就是減少重建 TCP 連線的耗時。但這個數值建議 Origin 本身的 TCP Timeout 來得大。比方說您的 Origin 是 AWS 的 ALB(Application Load Balancer) 時，ALB 預設的 Timeout 為 60秒，此時 CloudFront 的 KeepAlive Timeout 建議最大就 59 秒，甚至 55 秒。這樣可以避免一些預料之外的 502問題。

關於 502 排查，我們以後另開一篇文章來討論。

• Q4. Origin Shield 的區域要怎麼選啊?
  Ans: 選跟 Origin 網路距離較近的，因為距離越長，代表 Origin Shield 就得花越多的時間跟 Origin 建立連線 + 拿資料。(畢竟沒有人能超越光速)
• Q5. 回 Origin 時，選 HTTP 還是 HTTPS 比較好呢?
  Ans: 如果極端在乎 Latency，那麼 HTTP 會比較好。但如果 CloudFront 大都可以跟 Origin 維持在連線存在的狀態(KeepAlive 還沒過期)，那麼影響不大。
• Q6. 如果送進來的請求，要 31秒才能處理完畢，這時是不是應該把 Response timeout 加大?
  Ans: 如果是這麼極端的情況，在沒有加大 Response timeout 時，客戶可能會等上 90秒，最終拿到一個 504 錯誤。(30*3= 90，CloudFront 每次等 30 秒後放棄，連等 3 次)。但通常改善效能時(ex: 調整程式寫法、函式、或調整 DB 查詢語法)，可以改善的比例非常高，比方說我有遇過超過30 秒才能回應的請求，在改善之後不到 2秒就能回應。所以仍建議以改善效能為主。

關於 504 排查，我們以後在前面提到的另一篇文章中討論。

• Q7. Origin 可以設定為其它 CloudFront Distribution 嗎?
  Ans: 可以的，這叫做菊花鍊(daisy chain)，從網路上可以找到的討論，「最大」僅能 2 層 Distribution 串接，也就是你的 Distribution A 可以將另一個 Distribution B 設定為 Origin，但 Distribution B 不可以採類似設定，將 Distribution C 設定為 Origin 。超過的話，會噴錯。討論 link
• Q7. Origin 的 DNS 可以是指到一組依照 Geo Location有不同回應的目標嗎?
  Ans: 可以的，但當有使用 Origin Sheild 時，都會解析到同一組值，因為 CloudFront都會從被設定為 Origin Shield 的 REC 發出相關請求。
• Q8. Origin 可以是非 80 or 443 Port嗎?
  Ans: 可以的，比方說 Tomcat 的 8080 Port 就是個常見例子。Client 端也會受益於 CloudFront 的存在，可以改存取 80/443 Port 來拉取資料。
• Q9. 我可以設定 VPC 的 Private 網段主機(NAT 之後)來當 Origin 嗎?
  Ans: 除非您知道如何設置 TCP Tunnel(ex: SSH Port Forwarding)，讓外部可以存取道這主機的 HTTP Port，不然您即便設定上去也， CloudFront 也無法抓取到 HTTP Server 回應的資料。
• Q10. HTTP POST 的請求，也會在 Response timeout 後重試嗎?
  Ans: 不會的，依照文件說明，僅有 GET & HEAD 這兩類請求在Response timeout 後會重試。

[1] 很多年前 CloudFront 曾經支持 RTMP Server 作為 Origin，但已經在 2020 年底停止相關支持。https://repost.aws/questions/QUoUZgHZh7SEWlnQUPlBmVNQ?annID=7356
[2] FQDN - https://en.wikipedia.org/wiki/Fully_qualified_domain_name

今天的文章到這邊為止，有任何問題 & 建議，都歡迎在留言區留言給我喔!