本文為 CloudFront 系列第三篇，建議先閱讀以下文章了解基礎架構後再繼續。 CloudFront cache 錯頁面 Debug 流程（Rails 篇）這篇文章從真實案例出發，帶你逐步排查 CloudFront 快取錯頁面的問題。解析 Rails 的預設 Header、CDN 設定與 DNS 模式，避免使用者畫面被快取錯誤、看到別人的資料。假裝喝酒的軟體工程師YinCloudFront 快取設定詳解：Cache Key、TTL、Path Pattern 是什麼？（上）CloudFront 的快取設定讓你一頭霧水？這篇用白話文解釋 Cache Key、TTL 和 Path Pattern，讓你一次掌握 CDN 的快取核心概念！假裝喝酒的軟體工程師Yin 以下內容會幫助你理解 CloudFront 的快取策略與行為設定，

第一次打開 CloudFront 的設定頁時，我其實有點混亂。 畫面上會看到 Cache Key、TTL、Path Pattern 這些名詞，但如果你還沒實際踩過 CDN 快取的坑，很難立刻知道它們各自在管什麼。 後來我爬了很多文跟資料才理解，這三個設定其實分別在回答三件事： * 這份快取可以保留多久？ * 哪些請求可以共用同一份快取？ * 這個請求要套用哪一套規則？ 換句話說，CloudFront 的快取行為，很多時候就是由 Path Pattern、Cache Key、TTL 一起決定的。 這篇文章我會用比較直白的方式，整理這三個概念各自的角色，以及它們實際上怎麼影響 CDN 的快取判斷。 實際進到 CloudFront 的 Behaviors 頁面時，會看到一組預設行為，以及對應的快取相關設定。 一開始如果不熟這些欄位，很容易只看到一堆名詞，卻不知道它們分別會影響什麼。也因為這樣，我後來是反過來先搞懂每個設定在決定什麼，再回頭看介面，才比較看得懂。 當我從

以前在 bootcamp 學習套用 CDN 的時候，因為懂的少也不懂得懷疑，覺得反正部署之後，圖片有經過 CDN 、顯示得出來就好，其他不管。 但現在有了經驗、也踩了各種雷坑之後，疑心病加重！每個設定都覺得疑點重重，在想幹嘛要有這個，設定這是想做什麼！每個都覺得這一定有問題！！決定用這篇紀錄我的實作心得。 事件緣起：Reddit 真實案例 在 Reddit 上看到這篇討論，作者遇到了一個恐怖的狀況：CloudFront 把 A 使用者的頁面快取起來，卻回傳給 B 使用者看！ 想像一下這個場景： * 付費用戶登入後看到的專屬內容，竟然被免費用戶看到了 * 或者相反，免費用戶看到了付費才能看的頁面 * 更糟的是，用戶 A 的個人資訊被用戶 B 看到了 Production 環境要是真的發生這種事情還得了啊！天啊！！！！緊張如我開始有了一連串的質疑！ 問題：我的

什麼是 CDN ? 全名是 Content Delivery Network（內容傳遞網路），是一種透過分佈式的伺服器網路來加速網站和應用程式內容傳遞的技術。這些伺服器分佈在世界各地，目的是將內容更靠近用戶，從而提高訪問速度和效能。CDN 的伺服器稱為節點，當用戶請求網站內容時，CDN 會將請求路由到距離用戶最近的節點，提供最快的回應時間。 如果要我比喻 CDN 的話，他很像物流業者的倉庫。 舉例來說：物流業者有總倉庫和各個地點的小倉庫，當小倉庫設在離你家很近的地方，而且物流業者定期都會從總倉庫拉貨到你家旁邊的小倉庫的時候，當你訂貨購買，貨物只要從你家小倉庫送到你家就好，相當快速。 → 所以，以台灣用戶來說，如果有節點在台灣，回應速度是最快的。 可以想像成：貨物從日本倉庫送來 vs 貨物從台灣倉庫直送的時間差 什麼是 Push 型 CDN ? * 主動上傳內容： 在 push 型 CDN 中，需要「主動」將資源上傳到你指定的 storage，