CloudFront 快取設定詳解:Cache Key、TTL、Path Pattern 是什麼?

CloudFront 快取設定詳解:Cache Key、TTL、Path Pattern 是什麼?
圖文不符之 - 薄荷島海很藍。CloudFront 設定知識跟海一樣深

當你打開 CloudFront 的「行為」頁面時,常常會看到一些看不懂的預設值,像是:( 行為 Behaviors 頁面可以看到以下內容 )

  • 只有一個預設值,但完全不曉得要填什麼…
  • 點選 建立行為 之後,又有一堆選項,也是看不懂:
    (行為 Behaviors 頁面點選 建立行為 ,下拉選單到快取政策後可以看到)
    • 如果路徑模式選填 /*.js,則會出現推薦的快取政策 CachingOptimized,說適合 path pattern

到底這些是什麼意思?為什麼要選 AWS 推薦的設定?此文會一步步慢慢介紹 CloudFront 常見的快取概念,包括:

  • Cache Key 是什麼?
  • 為什麼 CloudFront 預設 Cache Key 是兩個?
  • TTL 是什麼?
  • Path Pattern 的作用是什麼?
  • 為什麼 AWS 會在 Path Pattern 推薦 CachingOptimized?
  • 常見問題

先來看看其中一個快取政策: CachingOptimized

裡面有很多設定啊...我們先來看 Cache Key

Cache Key 是什麼?—— 像是圖書館的「索書號」

Cache Key 像圖書館的索書號系統:

  • 圖書館找書:
    • 讀者說:「我要《網頁設計入門》這本書」
    • 圖書館員查系統:找到索書號 312.9 4567
    • 用索書號找書:拿著索書號去書架找,312.9 區域的 4567 號位置
  • CloudFront 找檔案:
    • Client 端 (瀏覽器、curl 等) 說:「我要 logo.png 這個檔案」
    • CloudFront 查看 cache key:mywebsite.com/images/logo.png
    • 用 cache key 找檔案:拿著這個 key 去快取裡找對應的檔案

👉 所以 Cache Key 就是「找檔案的依據」,若是 key 不同就會被視為不同的檔案。

預設情況下,Cache Key 包含:

  • 請求的主機名稱 (Host header)(例如:d111111abcdef8.cloudfront.net
  • 請求的 URI 路徑 (不包含 query string)

這代表什麼?

  • CloudFront 是依賴這兩個最基本的資訊來判斷「這是同一個檔案嗎?」「這個檔案有在快取裡嗎?」這樣可以簡單高效就能拿到檔案。
    這就像圖書館的「書名」和「作者」是預設的找書資訊,但如果你想找「某某出版社出版的精裝版」,你就需要更多的資訊了。

為什麼 CloudFront 預設 Cache Key 是兩個?

因為只用 Host + Path 能讓靜態檔案達到最高快取命中率。

設計邏輯:針對靜態檔案優化

  • 最早前 CDN 設計就主要是為了快取靜態檔案(圖片 .jpg, .png、CSS 檔案 .css、JavaScript 檔案 .js),同樣的靜態檔案,對所有使用者來說內容都是一樣的,所以不需要因應 query、header、cookie 去快取多份版本。
    • 例子: yourdomain.com/images/logo.png 不管誰來拿,它永遠是那個 logo.png

為什麼不包含 Query、Header、Cookie?

  • 考量快取「命中率」CloudFront 的目標是盡可能地快取檔案,讓使用者能從最近的節點取得內容,減少延遲。
    • 如果 Cache Key 太複雜: 如果預設把所有的「查詢參數 Query Parameters」、「HTTP 標頭 Headers」都納入 Cache Key,那麼即使是同一個檔案,只要網址上多一個 ?id=1 或是加個 header,CloudFront 就會把它視為完全不同的檔案,並單獨快取一份。
    • 導致的結果:
      • 快取命中率下降: 許多 cache Key 不同的檔案,每次請求可能都得回 Origin 拿一次,因為 CloudFront 覺得它是「新檔案」。

結果: 簡化的 Cache Key(只有 Host + Path)讓靜態檔案快取效率最大化。

💡
關於 CDN 原生用途,可以參考這裡說明 Akamai 研究論文(2010)- Originally, CDNs improved website performance by caching static site content at the edge of the Internet, close to end users, in order to avoid middle mile bottlenecks as much as possible.

Path Pattern 是什麼?——幫不同路徑分類設定規則

Path Pattern 可以針對不同類型的 URL 設定不同的快取策略。

💡
區別:
Path Pattern 決定 哪些 路徑用哪一組快取設定;
Cache Key 決定 同一路徑 有沒有命中快取
Path Pattern 代表意義
/images/*.jpg 對所有圖片設定,可以決定其為同樣的快取政策
*.html 對所有 HTML 設定,可以決定其為同樣的快取政策

這也是為什麼當我們進到行為頁面的時候,是可以用「建立行為」去做更細緻設定的。這樣就能控制不同類型內容的快取行為。
🔗 參考 AWS 文件 Path pattern 說明

TTL 是什麼?——像罐頭的保存期限

TTL(Time-To-Live)決定 CDN 多久向 Origin 確認檔案是否有更新。 在 TTL 時間內直接回傳快取,不向 Origin 確認。

TTL 就像保存期限的概念

CloudFront 會把檔案存放在最近的「超商」(Edge Location)。TTL(Time-To-Live)就是這份檔案的保存期限:期限內客人(Client 端:瀏覽器、curl 等)來買,店員(Edge Location)直接從貨架拿;期限一到,快取項目會被標記為過期,店員才回總倉(Origin)補貨。

什麼檔案適合設長 TTL?

  • 靜態檔就像罐頭:圖檔、CSS、JavaScript 通常不會變
  • 寫好沒錯就不變動:既然不常變質,適合設很長的保存期限
  • 減少重複請求:長 TTL 讓使用者載入更快、原伺服器更省力

CloudFront 的 CachingOptimized 政策

提供了最適合靜態檔案的 TTL 策略:

  • 長保存期限:TTL 預設 24 小時,最多可到 1 年
  • 只保留單一快取檔案:不將 Query、Cookie、Header 列入 Cache Key
  • 最高命中率:確保同一個 URL 只有一個版本

要更新快取可以怎麼辦?

  • 改檔名(加 fingerprint / hash):例如把 app.js 換成 app-a1b2c3.js。URL 變了,Edge 快取與所有 Client 端(瀏覽器、curl、App)都會把它當成全新檔案。

實際效果 TTL 搭配 CachingOptimized 政策,讓靜態檔案就像放在各地超商的罐頭一樣,客人隨時都能就近快速取得,總倉庫也不用一直出貨。
簡單來說,先理解 TTL 保存期限的概念,再用 CloudFront 的 CachingOptimized 政策來實現快取最佳化!

為什麼 AWS 會在 Path Pattern 推薦 CachingOptimized?

因為大部分網站的靜態資源(圖檔、CSS、JS)都放在特定路徑下(如 /static/*/assets/*),而 CachingOptimized 正是為這類檔案設計的最佳策略。

什麼時候不該用 CachingOptimized?

  • API 回應、動態內容、需要即時更新的檔案
  • 這些會在下個章節詳細說

常見問題

設錯快取政策怎麼驗證?

  • 我們可以實際去網站上看,看有沒有 hit cloudfront。驗證是為了確保快取如預期工作,避免因為設定錯誤而導致的「快取失效」之類的問題
  • 舉例:
# 第一次通常 MISS
curl -I <https://blog.majid.info/js/photoswipe-lightbox.esm.min.js>

# 再跑一次就會 HIT
curl -I <https://blog.majid.info/js/photoswipe-lightbox.esm.min.js>
# 重點關注這些 header:
# - x-cache: Hit from cloudfront / Miss from cloudfront
# - age: 顯示快取了多久
# - cache-control: 顯示快取策略

改了 CSS 檔案,使用者會看到舊版本嗎?

這是使用長 TTL 時最常遇到的問題!解決方案是讓每次更新都產生「新的檔名」:優先使用框架內建的 fingerprint 功能是最好的,以 Rails 來說,Rails 好棒棒已經自動處理了這個問題,其他框架必須確認各自的 fingerprint 處理方式
🔗 參考 Rails 官方網站文章

# 部署前:app.css  
# 部署後:app-a1b2c3d4e5f6.css ← 自動加上 fingerprint
  • 在 cloudfront 頁面也可以手動建立無效判定,讓特定路徑的快取無效(invalidation)

動態內容(如 API)該怎麼設定快取?

  • 下一個章節介紹,但先記住動態內容不要設定 CachingOptimized 當作快取政策,會出事啊啊啊啊啊啊啊啊

結論:回到最初的問題

還記得開頭看到 CloudFront 設定頁面的困惑嗎?現在你應該能理解以下:

💡
重點提醒:
Cache Key:像圖書館索書號,CloudFront 用 Host + Path 找檔案TTL:像罐頭保存期限,決定快取檔案多久重新驗證或獲取新版本Path Pattern:幫不同路徑分類,設定專屬的快取策略

為什麼 AWS 推薦 CachingOptimized?
因為它符合靜態檔案的特性:簡化的 Cache Key + 長 TTL = 最高快取命中率。
💡
實務建議:
靜態檔案(圖片、CSS、JS)→ 用 CachingOptimized
動態內容(API、個人化內容)→ 用其他政策(下篇詳解)
更新靜態檔案時記得加 fingerprint,讓新版本立即生效避免使用舊檔案