上一篇比較了 ALB 與 NLB，處理的是流量進入 AWS 後，要怎麼分配到後端服務。
但如果使用者分散在台灣、日本、美國等不同地區，即使後端服務本身沒有問題，還是可能遇到：
這時常會看到三個 AWS 服務：
它們看起來都和「使用者如何抵達服務」有關，但處理的是不同問題。
這篇會比較 Amazon CloudFront、AWS Global Accelerator 與 Amazon Route 53，看看內容傳遞、網路路徑與 DNS 導向，分別如何影響使用者的存取體驗。
先從一條完整的存取路徑來看：
使用者
│
│ DNS 查詢
▼
Route 53
│
│ 找到服務入口
▼
CloudFront / Global Accelerator
│
▼
ALB / NLB
│
▼
應用程式
其中 CloudFront 與 Global Accelerator 會實際承接應用程式流量，可以先簡單理解成：
Route 53
→ DNS 要把使用者導向哪裡？
Route 53 是在 DNS 階段回答「這個網域應該連到哪裡」，後續的 HTTP、TCP 等應用程式流量並不會經過 Route 53。
CloudFront
→ 內容能不能從離使用者較近的地方提供？
Global Accelerator
→ 使用者連到 AWS 的網路路徑能不能更穩定？
所以這三個服務不是單純三選一，實際架構中也可能同時出現。
假設網站部署在東京：
使用者
│
│ Internet
▼
Tokyo ALB
│
▼
應用程式
日本使用者連到東京的延遲通常較低，但美國使用者如果需要向來源站重新取得圖片、JavaScript 或 CSS，就必須跨越較長的網路距離，增加等待時間。
這時可以在前面加入 Amazon CloudFront：
使用者
│
▼
CloudFront Edge Location
（邊緣節點）
│
▼
Origin
（來源站）
│
├── S3
└── ALB
CloudFront 是內容傳遞網路（CDN），會將請求導向適合服務該使用者的 Edge Location（邊緣節點）。
如果節點已有符合請求且仍有效的快取，就能直接回傳，減少回到 Origin（來源站） 取得內容的次數，來源站可以是 S3 Bucket，也可以是 ALB 後方的應用程式。
CloudFront 也可以依照 Path Pattern（路徑模式） 設定不同的 Cache Behavior（快取行為），讓不同路徑使用不同的來源站、快取方式與轉送規則。
例如一個購物網站可以分成：
| 路徑 | 內容 | 做法 |
|---|---|---|
/assets/* |
JavaScript、CSS | 快取 |
/images/* |
商品圖片 | 快取 |
/api/orders/* |
登入者的訂單資料 | 不快取，轉送到來源站 |
也就是說，使用 CloudFront 不代表「整個網站全部快取」。
以上面的訂單 API 為例，請求仍然經過 CloudFront，但每次都轉送到來源站，由後端驗證身分並產生回應，因此網站可以同時透過 CloudFront 傳送公開檔案與個人化資料，再依內容設定不同的處理方式。
對需要快取的內容，Cache Policy（快取政策） 會設定快取有效時間，以及哪些 Header（標頭）、Cookie 或 Query String（查詢參數）要納入 Cache Key（快取鍵），快取鍵是用來區分哪些請求可以共用同一份回應，例如同一個網址會依語言標頭回傳中文或英文內容，就需要將這項差異納入快取設定。
這篇先不深入快取鍵的設定，只要先知道：不是所有內容都應該使用相同的快取方式。
如果服務使用 TCP、UDP，例如自訂通訊協定或遊戲連線，或需要固定 IP 作為跨 Region 的入口，就可以進一步評估 AWS Global Accelerator（GA）。
HTTP／HTTPS API 也能使用 GA，但單純「每次請求都必須回到後端」，還不足以決定要導入，選擇時仍要確認是否有改善網路路徑、固定入口 IP，或跨 Region 流量分配的需求。
Global Accelerator 會提供固定的 Anycast IP（由多個網路節點宣告的同一組 IP 位址） 作為入口，讓不同地區的使用者就近進入 AWS 網路，再透過 AWS 全球網路前往適合的 Regional Endpoint（區域端點）。
以 Standard Accelerator（標準加速器） 來說，端點可以是 ALB、NLB、EC2 執行個體或 Elastic IP，並可分布在一個或多個 Region，GA 會依端點健康狀態、使用者位置與路由設定選擇目的地。
舉例來說：
┌── Tokyo ALB
│
User ── GA 固定 IP ──────┤
│
└── Singapore ALB
東京與新加坡各有一個 ALB，就可以將兩者設為 GA 的端點，使用者透過同一組固定 IP 連線，再由 GA 選擇目的地；各 Region 內的 ALB 則繼續負責將請求分配給後端應用程式。
固定入口 IP 也適合需要設定 IP Allow List（IP 白名單） 的合作廠商，後端端點調整時，只要保留同一個加速器，對外入口 IP 就能維持不變，減少重新申請白名單的工作。
但要注意：使用 GA 能改善多少，取決於網路延遲占整體回應時間的比例。
假設 API 很慢的原因是：
網路延遲
→ 50 ms
資料庫查詢
→ 2 秒
真正的瓶頸在資料庫，那麼就算改善前面的網路路徑，整體回應時間也不會因此從 2 秒變成瞬間完成。
另外，Global Accelerator 不會幫另一個 Region 準備應用程式或複製資料。
它可以把新的連線導向健康的區域端點，但另一個 Region 本身還是要先有可以正常接手的應用程式、資料庫與相關資源。
這個問題就會接到下一篇要談的 Multi-AZ 與 Disaster Recovery（災難復原）。
前面的 CloudFront 與 Global Accelerator 都會實際處理使用者流量，Amazon Route 53 則透過 DNS 解析，告訴用戶端這個網域對應哪個目的地，取得解析結果後，用戶端才會連線到 CloudFront、ALB 或 Global Accelerator，後續的應用程式流量不會經過 Route 53。
例如：
www.example.com
│
▼
Route 53
│
▼
CloudFront / ALB / Global Accelerator
如果系統只有一個入口，Route 53 可以單純把網域指向該資源；但如果系統部署在多個 Region，就可以透過不同的 Routing Policy（路由政策） 決定 DNS 回應。
| 路由政策 | 如何選擇目的地 | 舉例使用情境 |
|---|---|---|
| Latency-based Routing（延遲路由） | 根據 AWS 的延遲量測資訊，選擇預期延遲較低的 Region | 東京與新加坡都有服務，希望使用者連到延遲較低的一側 |
| Weighted Routing（加權路由） | 依設定的相對權重分配 DNS 回應 | 舊環境權重設為 90、新環境設為 10，逐步導入新環境 |
| Failover Routing（容錯移轉路由） | 配合健康檢查，在主要資源不健康、備援資源健康時回覆備援目的地 | 東京為主要環境，新加坡為備援環境 |
不過這裡有一個很重要的限制：Route 53 做的是 DNS 導向，不是每一次 HTTP Request 都重新選一次目的地。
因此加權設為 90：10，不保證每十次 HTTP 請求就有九次進入舊環境、一次進入新環境，同一份 DNS 解析結果可能被重複使用，後續請求也可能沿用既有連線。
DNS Resolver（DNS 解析器）會依照 TTL（Time to Live，存活時間） 快取 DNS 回應，例如 TTL 還沒到期，即使 Route 53 的 DNS Record（DNS 紀錄）已經修改，解析器還是可能暫時使用舊的結果。
簡單示意流程如下：
Primary 發生問題
↓
Route 53 更新 DNS 回應
↓
不代表所有 Client 立刻切換
Route 53 判定主要資源故障後，不會讓所有用戶端立刻切換，既有連線也不會因 DNS 回應改變而自動轉移。
縮短 TTL 可以減少快取造成的等待，但整體切換時間仍受健康檢查、DNS 快取與用戶端重連行為影響。
這也是 Route 53 的容錯移轉，和 Global Accelerator 依端點健康狀態導流之間很重要的差異。
看完各自的能力與限制，可以整理成以下比較：
| 服務 | 主要處理的問題 | 適合的需求 | 需要管理的設定與限制 |
|---|---|---|---|
| CloudFront | HTTP／HTTPS 內容如何傳遞 | 共用內容快取、網站與 API 傳送 | 快取有效時間、快取鍵與來源請求轉送 |
| Global Accelerator | 使用者如何透過 AWS 全球網路連到端點 | 固定入口 IP、TCP／UDP 連線、跨 Region 導流 | 端點健康檢查與路由設定；後端應用程式與資料需自行準備 |
| Route 53 | DNS 查詢應回覆哪個目的地 | 網域解析、加權分流、延遲路由與主備切換 | DNS 快取會影響切換時間，無法控制每次應用程式請求 |
舉一個簡單的情境，假設現在有一個購物網站：
這個情境下，可以設計成：
Route 53
│
▼
CloudFront
│
▼
ALB
│
┌──────┴──────┐
▼ ▼
Web Service API Service
Route 53 負責：
www.example.com
→ CloudFront
CloudFront 則可以：
/assets/*
→ 快取
/images/*
→ 快取
/api/orders/*
→ 不快取
→ 轉送到 ALB
這個案例不需要只因為「使用者分散在不同國家」，就再加一層 Global Accelerator。
因為目前真正需要解決的是網站內容傳遞，而不是固定全球 IP、TCP / UDP 加速，或多 Region 端點導流。
如果需求換成全球使用者都要連到一個 UDP Service：
User
│
▼
Global Accelerator
│
├── Tokyo NLB
└── Singapore NLB
那 Global Accelerator 就會更符合需求。
如果只是系統已經部署兩個 Region，希望透過 DNS 做 Primary / Secondary，則可以先評估 Route 53 的 Failover Routing（容錯移轉路由）。
到這裡，已經從 VPC 內部網路、跨 VPC、公司網路，一路看到 Load Balancer 與全球使用者入口。
但即使入口可以把流量導向另一個 Region，也不代表那個 Region 已經能接手服務。
接下來會進入 Availability（可用性）與 Disaster Recovery（災難復原），下一篇會從 RTO、RPO 開始，看看 Multi-AZ、跨 Region 與災難復原分別在解決什麼問題。
iThome鐵人賽
看影片追技術