AWS帳號充值優惠 AWS CloudFront CDN加速靜態資源的配置教學

第一章：為什麼靜態資源特別需要 CDN

很多網站的「慢」，其實不是程式邏輯慢，而是靜態資源慢：圖片、CSS、JavaScript、字型、甚至是下載檔。當使用者每一次點進頁面都要從同一地點取回這些檔案，延遲就會累積。對全球使用者來說，問題更明顯：資料距離越遠，等待時間越長。

CDN（Content Delivery Network）的核心概念很簡單：把你常用的靜態檔，緩存在靠近使用者的邊緣節點（edge locations）。使用者請求時，優先由邊緣節點回應，而不是每次都跨洋回源。這會帶來三個直接收益：降低延遲、減少源站壓力、提升使用者體驗（也常間接改善 SEO 與轉換）。

在 AWS 生態中，CloudFront 是最常見的 CDN 選項。它的強項在於：與 S3、ALB、EC2 等源站整合順暢；提供可配置的快取行為、壓縮、HTTPS、安全策略；而且有統一的管理入口與監控指標。

第二章：在動手配置前先理解幾個關鍵名詞

你做 CloudFront 時，最容易卡住的不是按鈕，而是概念。先抓住以下幾個詞，後面操作就會順很多。

源站（Origin）

CloudFront 會向哪裡「回源」取得你沒有緩存的內容。常見源站包括：S3 bucket、HTTP 端點（例如 ALB/EC2/自建服務）。靜態資源加速最常見就是 S3。

分配（Distribution）

CloudFront 的頂層配置。一次 distribution 可以包含至少一個「行為」（Behaviors），用不同規則處理不同路徑。

行為（Behavior）與路徑模式

例如你可以把 /assets/* 指向特別的快取策略；而 /api/*（若有）則改成不快取或短快取。路徑模式的匹配順序與你期望的一致，能避免「快取錯人」或「API 被不該快取」的問題。

快取策略（Cache Policy）與快取期間（TTL）

快取策略決定 CloudFront 如何依據請求（headers、query strings、cookies 等）形成快取鍵，以及快取多久。TTL 通常會被你設成一組：最小值（min）、預設值（default）、最大值（max）。靜態檔案一般會讓它更久。

Invalidation（無效化）

當你更新了源站檔案，CloudFront 可能仍在用舊的緩存。無效化可以讓 CloudFront 立刻把指定路徑的快取清掉，重新回源取新內容。這不是免費的捷徑：大量路徑頻繁無效化會增加成本，所以建議搭配「檔名帶版本」的釋出方式。

第三章：準備工作：確保你的靜態資源可被 CloudFront 取得

以 S3 為例，你要先把靜態資源上傳到一個 bucket，並確認它的權限與 CloudFront 的回源權限。

建議的檔案命名方式：帶 Hash 的版本檔名

例如把 app.js 變成 app.9f3c2a1.js。當內容變動時，hash 會變，路徑不同，CloudFront 就會自然取得新檔案。這能大幅降低你對 Invalidations 的依賴。

設定 S3 的靜態網站或一般 Bucket 網站

CloudFront 通常不需要你開啟 S3 的「靜態網站託管」，你可以把源站指向 S3 的 REST endpoint（S3 origin）。這樣行為更一致，也比較好控權限。

讓 CloudFront 存取 S3：使用 Origin Access Control（OAC）

AWS帳號充值優惠 如果你要安全地讓 CloudFront 讀取私有 S3，建議使用 OAC（或也可使用較早的 OAI，但 OAC 逐步成為常見作法）。其目的就是：你不要把 bucket 公開給全世界，而是讓 CloudFront 以受控方式取得檔案。

實作上你需要做幾件事：建立 OAC，將其綁定到 CloudFront distribution 的 origin；同時調整 S3 bucket policy，允許特定 CloudFront 分配的存取。只要這一步沒做好，你就會看到 403 或 404，且除非你看錯誤頁內容，通常不會一眼看出原因。

AWS帳號充值優惠 第四章：建立 CloudFront 分配（Distribution）

下面用較貼近實務的流程描述。你在 AWS 主控台操作時，名稱可能因為版本略有不同，但邏輯是一樣的。

步驟 1：選擇 Web 或 RTMP

靜態資源加速通常選「Web」。

步驟 2：設定 Origin

1) 選擇「Origin domain」：通常選你的 S3 bucket 的 domain。

2) Origin access：若你使用 OAC，選擇相應的 OAC。

3) Origin protocol policy：針對 S3 這通常沒太多選擇空間，但要確保 CloudFront 能用正確協定回源。

如果你不是 S3，而是有 HTTP 端點作為源站，這裡就會涉及 HTTP/HTTPS 與回源安全性設定。

步驟 3：設定 Default Cache Behavior

這裡是決定成敗的地方之一。你需要設定：

1) Viewer protocol policy：建議設為「Redirect HTTP to HTTPS」或「HTTPS only」。你的目標是讓使用者端永遠走 HTTPS，避免混合內容與安全警告。

2) Allowed HTTP methods：靜態資源通常只需要 GET、HEAD。

3) Cache policy：可先選「CachingOptimized」等預設，但你後面最好自己調整，尤其要處理 query string 的情況。

4) Compress：建議打開。CloudFront 可在傳輸時啟用 gzip/brotli 壓縮（依資源類型與瀏覽器支援）。靜態資源通常能明顯受益。

第五章：快取規則怎麼設才合理（Cache Policy + TTL）

很多人把快取 TTL 設很短，擔心更新內容不會生效；也有人把 TTL 設到極限，最後發現更新要等半天甚至更久。

更好的思路是：你要把內容更新策略納入快取設計。最常見的解法就是「檔名帶版本」與「正確的 Cache-Control」。

靜態資源（CSS/JS/圖片/字型）的建議策略

如果你的資源檔名包含 hash（版本），你可以給很長 TTL，甚至接近一天到一年等級都合理。你要做的不是把 TTL 設成越長越好，而是「確定你不需要用時間來讓客戶拿到更新」。因為檔名一變，URL 就變，CDN 就會以新鍵獲取新檔。

一個常見做法是：default TTL 設高、max TTL 設高，min TTL 設小或設為 0（避免邊緣節點在某些情況下過度長時間）。實際數值依團隊風格與部署節奏調整即可。

Query String 與快取鍵：避免快取爆炸

若你的靜態資源 URL 帶 query string，例如 ?v=1 或 ?timestamp=...，你就要小心快取鍵組合。你選擇是否把 query string 納入快取鍵；若納入且值每次都變，快取命中率會大幅下降。

建議做法通常是：對靜態資源盡量避免在 URL 上使用會頻繁變動的 query parameter；用檔名 hash 取代它。如果真的不可避免，至少要明確定義「哪些 query 參數要被納入」而不是全部都進快取鍵。

Headers、cookies：能不加就不要加

快取鍵加入越多維度，命中率越難維持。對靜態資源而言，通常不需要 cookies，也不需要特定 headers。你只要確保內容的行為一致即可。

第六章：壓縮、HTTPS 與自訂網域（可選但很常用）

CloudFront 的價值不只是快取。你還可以把傳輸層優化做得更完整。

啟用壓縮（Compress）

如果你已經讓 CloudFront 提供壓縮，且瀏覽器支援（例如現代瀏覽器幾乎都支援），資源大小會下降，延遲與吞吐都會更好。

注意：壓縮對圖片（PNG/JPG）通常效果有限，但對 JS/CSS 以及某些字型資源通常很有感。

Viewer protocol policy 與憑證

如果你用自訂網域（例如 cdn.example.com），你需要在 CloudFront 申請/綁定憑證。建議使用 AWS Certificate Manager（ACM），確保更新和部署流程順。

同時設定 Viewer protocol policy，讓所有請求導向 HTTPS，能降低安全風險與排錯成本。

第七章：建立針對不同路徑的行為（Behaviors）

只用 Default behavior 也能跑，但當你的網站包含多種資源類型，行為分配會讓整體更精準。

示例：/assets/* 走長快取

把你的靜態打包產物放在固定路徑，例如 /assets/*。對這個路徑：

1) 只允許 GET/HEAD。

2) Cache policy 使用長 TTL。

3) 啟用壓縮。

4) 通常不快取 query（或限制只快取你需要的）。

示例：/index.html 或 /$ 特殊處理

有些網站會把 /index.html 視為「入口文件」。它可能包含對資源檔名的引用，而你的 JS/CSS 會帶 hash。這種情況下，入口文件需要更快更新。

AWS帳號充值優惠 因此你可以讓 /index.html 或 /*（若你確定只用在前端）採用較短 TTL，確保每次發版後更快生效。

更細的做法是：用 Cache-Control: no-cache 或 max-age 很小，搭配無效化或輪詢策略。但如果你入口文件也用 hash，那又是另一套策略。

第八章：部署更新與無效化策略（Invalidation）怎麼用才不燒錢

當你上傳新檔到 S3，CloudFront 不一定立刻更新邊緣節點。這不是失誤，是快取機制的設計。

你可以用兩條路線：

• 路線 A：採用檔名 hash，更新後 URL 改變，就不需要 Invalidations（通常這是最佳方案）。
• 路線 B：若你必須更新固定路徑檔案（例如 /robots.txt、/favicon.ico、/index.html），就用 Invalidation 讓特定路徑立即刷新。

通常我會建議：把 Invalidations 用在少量、固定路徑的更新上；大量、頻繁的資源用 hash 檔名。這樣你既能確保更新速度，又能避免無效化成本與風險。

第九章：常見錯誤與排查方式（讓你少走彎路）

AWS帳號充值優惠 你配置 CloudFront 時，最常見的問題不是概念，而是細節。這裡列一些高頻原因與排查方法，能讓你更快找到根因。

403：回源權限不足

最常見就是 S3 bucket policy 或 OAC 沒配置好。你可能看到 CloudFront 返回 403，源站端可能也有拒絕記錄。解法通常是：

• 確認 OAC 已綁定到 distribution 的 origin。
• 確認 bucket policy 允許對應的 CloudFront 分配/身份。
• 檢查資源物件是否真的存在，避免把 404/403 混在一起看。

404：物件不存在或路徑不一致

CloudFront 返回 404 的情況也常見於路徑拼接錯誤。例如你在網頁引用 /assets/app.js，但 S3 實際上是上傳到 /asset/app.js 或大小寫不同（S3 對 key 是區分大小寫的）。

建議你在部署後立即用同一套 URL（CloudFront URL）測試，並對照 S3 key。

快取命中率很低

如果你發現快取命中率不理想，通常原因是：

• Query string 每次都變（例如 timestamp）。
• 快取鍵包含過多 headers 或 cookies。
• TTL 設得太短。

你可以從 CloudFront 監控指標觀察 CacheHitRate，並檢查你的 Cache policy 設定。

更新後仍顯示舊內容

這通常是 TTL 或 Cache-Control 設定造成。若你依賴快取刷新，你就要確認：

• 靜態資源 URL 是否已使用 hash 變更。
• 你更新的是否是快取鍵對應的路徑。
• AWS帳號充值優惠 是否需要 Invalidation，以及是否已對正確的路徑做無效化。

記住：只更新 S3 物件內容，但 URL 沒變，CDN 很可能仍沿用舊緩存。

第十章：如何驗證成效（不是只看頁面快了）

配置完成後，你要做兩件事：確認內容正確、確認效能提升且風險可控。

測試內容一致性

用幾個典型資源測試：首頁 HTML、JS/CSS、圖片、字型、以及你特別處理的路徑。確保 CloudFront URL 回傳的狀態碼正確，且內容與預期版本一致。

觀察快取命中率與回源比例

CloudFront 的監控指標可以看到 CacheHitRate 與 origin fetch rate。命中率偏低時，表示你的快取策略與 URL 行為尚未匹配。

同時也要看回源錯誤（例如 4xx/5xx）。如果回源在錯誤狀態下被重複觸發，你可能會遇到使用者端大量失敗，卻不會立即注意到。

用瀏覽器開發者工具確認 Cache-Control

在前端頁面打開開發者工具，查看 Network 面板的 Response Headers。你可以確認：

• 是否有 Cache-Control / ETag（視你的配置）。
• 瀏覽器是否顯示從 cache 讀取，或標示由 CDN 提供。

AWS帳號充值優惠 如果你希望瀏覽器也快，你可能還要調整源站或 CloudFront 對應的 header 行為。

AWS帳號充值優惠 第十一章：一套可直接套用的配置建議（以靜態資源為前提）

如果你只是希望「快、穩、可更新」，這裡給你一套常見且實務友善的組合。你可以把它當作起點，再依需求微調。

Origin

S3 bucket（私有），搭配 OAC；確保 bucket policy 只允許 CloudFront 讀取。

AWS帳號充值優惠 Default behavior

Viewer protocol policy：Redirect HTTP to HTTPS 或 HTTPS only。

Allowed methods：GET, HEAD。

Cache policy：以你專案的更新頻率調整，靜態資源預設偏長。

Compress：Enable。

Behaviors 分路徑

• /assets/*：長快取（搭配 hash 檔名）。
• /index.html（或 /* 入口）：短快取或 no-cache 機制（視你的部署策略）。

更新策略

資源檔名 hash 化：盡量不用 Invalidation。

僅對少量固定檔（入口文件、robots、manifest 等）做 Invalidation。

第十二章：把 CloudFront 當成系統的一部分，而不是一次性設定

真正穩定的 CDN，不是把按鈕點完就結束，而是把它納入部署與監控。你可以用以下習慣讓後續維運更輕鬆：

• 部署流水線要能清楚描述：哪些檔名會變、哪些需要無效化、何時更新入口文件。
• 監控快取命中率、回源錯誤與延遲。不要只看「今天快不快」，要看趨勢。
• 為容易錯的地方建立檢查：OAC 權限、路徑大小寫、query string 使用規則。
• 每次調整 Cache policy 前，先在測試環境確認行為，避免把快取鍵設太複雜導致命中率下降。

結語：你已經有一張能落地的配置路線圖

CloudFront 的設定看起來選項多，但邏輯其實是圍繞「回源安全、快取策略、更新方式、驗證監控」。只要你先把靜態資源的 URL 策略（尤其是 hash 檔名）想清楚，後續的 TTL、是否需要無效化、以及如何避免命中率下降就會變得很容易。

把你的目標講白：讓使用者拿到最新且更快的靜態內容，同時不要把源站與運維成本壓垮。用這套方法，你就能真正做到 CloudFront CDN 加速，而不是只完成一次設定。