Route 53 DNS、路由策略與 CloudFront CDN

Amazon Route 53 與 Amazon CloudFront 共同構成每個 AWS 工作負載的對外邊緣，在 SOA-C02 中，它們是 Task Statement 5.2「設定網域、DNS 服務與內容交付」的全部考試主軸。SAA-C03 要求你在設計階段選擇一種 routing policy，SOA-C02 則測試你能否在生產環境中實際維運 Route 53 zone：一筆失效卻沒有切換的 failover record、有人試圖在 zone apex 建立的 CNAME、指向錯誤 CloudFront distribution 的 example.com Alias、S3 bucket 更新後卻還持續提供舊資產的 CloudFront distribution，以及在 bucket policy 重寫後忘記加回 OAC principal 導致 S3 靜態網站突然回應 AccessDenied。Route 53 DNS、CloudFront 與內容交付是 Domain 5 所有關於流量、延遲或 DNS 解析場景題的匯聚點。

本指南從 SysOps 角度完整走過 Route 53：hosted zone 類型、Alias vs CNAME 的抉擇（以及為何 zone apex record 讓答案別無選擇）、七種 routing policy 與各自的運維識別線索、health checks（endpoint、calculated、CloudWatch alarm），以及 Route 53 Resolver 的 inbound 和 outbound endpoints 如何應對混合 DNS；接著進入 CloudFront：distributions 與 origins、OAC vs 已棄用的 OAI、cache behaviors 與 TTL、CloudFront Functions vs Lambda@Edge、price classes、cache invalidation，以及接上 Route 53 Alias 的 S3 靜態網站代管。你也會看到反覆出現的 SOA-C02 場景類型：failover 後流量卻跑錯 region（TTL 陷阱）、S3 更新後 CloudFront 仍提供舊內容（cache invalidation）、example.com apex 指向 CloudFront（Alias 是唯一選項），以及 OAI 遷移至 OAC。

為什麼 Route 53 與 CloudFront 是 SOA-C02 的邊緣核心

官方 SOA-C02 Exam Guide v2.3 在 Task Statement 5.2 下列出五項技能：設定 Route 53 hosted zones 與 records、實作包含 geolocation 和 geoproximity 的 Route 53 routing policies、透過 Route 53 Resolver 設定 DNS、設定 CloudFront 與 S3 origin access control（OAC），以及設定 S3 靜態網站代管。本指南覆蓋了以上每一項技能對應的服務或功能。Domain 5 佔 SOA-C02 分數的 18%，而 TS 5.2 大約佔該 domain 三分之一的分量，換算下來 Route 53 與 CloudFront 在典型 65 題的考試中佔 8 至 10 題。

在 SysOps 層級，考試的切入點是實作與疑難排解，而非架構選型。SAA-C03 問「哪種 Route 53 routing policy 能讓歐洲使用者從 Frankfurt region 取得服務？」；SOA-C02 問「latency-based routing record 指向 Frankfurt 的 ALB，但歐洲使用者仍然打到 us-east-1 的 origin——發生了什麼事？」答案很少是 routing policy 本身出問題，而是 recursive resolver 上的過期 TTL、缺少 health check、record set ID 不符、Alias 指向錯誤的目標，或 CloudFront distribution 快取了舊的 endpoint。Route 53 與 CloudFront 主題與 SOA-C02 後續所有對話都息息相關：ELB health checks 與 Multi-AZ failover（Domain 2）、跨 region backup 與災難復原 failover（Domain 2.3）、掛載到 CloudFront 的 WAF 與 Shield（Domain 5.1）、用於疑難排解的 VPC Flow Logs 與 CloudFront access logs（Domain 5.3），以及串接 Route 53 health checks 做複合訊號的 CloudWatch alarms（Domain 1）。

白話文解釋 Route 53 DNS, CloudFront, and Content Delivery

DNS 與 CDN 的概念很容易讓人覺得抽象，用幾個日常情境來固定這些概念就清晰多了。以下三個類比涵蓋 SOA-C02 的主要考點。

類比一：DNS 是夜市攤位的公告欄

Route 53 是夜市裡的公告欄。Hosted zone 是某家攤商（example.com）在公告欄上佔的那個專屬版面——版面裡的每筆 record 都是這攤的聯絡資訊。A record 是實際攤位號碼（IPv4 位址）。CNAME 是一張指引條，寫著「想找阿義的魯肉飯，先去查阿嬌的豬腳飯在哪裡」——很方便，但你不能把「指引條」貼在攤商的主版面欄位，因為主版面只能貼實際資訊，不能貼跳轉說明。Alias record 是 Route 53 的特殊**「請見另版」快捷指標**，直接讀取其他 AWS 資源的當下資訊，不受 apex-CNAME 限制——它占的位置和普通 A record 一樣，但會動態解析到目標資源當下的 IP。Routing policies 是攤主設定的派單規則：Simple（永遠給第一筆）、Weighted（按比例輪流）、Latency（給最近的）、Failover（主攤忙不過來才給備攤）、Geolocation（按客人來的縣市給）、Geoproximity（按距離加權）、Multivalue（最多給八筆讓客人自選）。Health checks 是市場管理員定期巡攤——打電話確認攤子還開著；接連三次沒人接，就把這攤從派單名單移除。

類比二：CloudFront 是連鎖便當的衛星門市網路

CloudFront 是連鎖便當店的衛星門市網路。Origin 是中央廚房，負責準備所有菜色（你的 S3 bucket 或 ALB）。Edge locations（全球 600 個以上）是各地衛星門市——客人走進門市點便當，門市先看自己的保溫箱（快取）有沒有；有的話（cache hit）立刻出餐；沒有的話（cache miss）打電話給中央廚房，拿到食譜現做，留一份在保溫箱，再出給客人。TTL 是保溫箱上的保鮮標籤——24 小時後（預設）這份便當就不新鮮了，下一位客人點餐時要重新向中央廚房叫貨。Cache invalidation 是總部發出的緊急下架通知——「各門市立刻清掉便當，食材有問題」——代價很高，因為所有門市下一次點單都得向中央廚房重拿。OAC 是門市識別證——中央廚房只接受持有官方識別證的門市來電，拒絕任何陌生電話（防止直接訪問 S3 bucket）。Cache behaviors 是各品項的保存規則——「便當可以放 24 小時，但果汁每次現打」，對應到路徑規則如 /static/*（長 TTL）與 /api/*（零 TTL）。

類比三：Health Checks 是每日健康回報系統

Route 53 health check 像是對每台伺服器建立的每日健康回報制度。預設情況下，護理站（Route 53）每 30 秒呼叫一次受測人員（你的 endpoint）確認狀況。連續三次沒有回應，這位人員就被標記為失聯，從緊急聯絡名單（DNS 輪流清單）中移除。Fast health check 每 10 秒一次，加收費用——適合需要更快偵測的關鍵服務。Calculated health check 是由多達 256 份個別回報綜合判斷的整體評估，使用布林表達式——「若兩個核心系統都異常，則整體視為異常」。CloudWatch alarm health check 是透過儀表板讀取結果的間接判斷——Route 53 不直接打電話給 endpoint，而是讀取 CloudWatch alarm 狀態，alarm 進入 ALARM 時就標記為 Unhealthy。Failover routing policy 依賴這些評估結果：永遠優先回傳 Primary；只有 Primary 被標記為 Unhealthy 時，才切換到 Secondary。

Route 53 Hosted Zones：Public vs Private

Hosted zone 是 Route 53 中某個網域 DNS records 的頂層容器。每次 Route 53 部署，都從決定 zone 類型開始：public、private，或兩者並存。

Public hosted zones

Public hosted zone 回應來自公共網際網路的 DNS 查詢。當你透過 Route 53（或其他 registrar，並將 NS records 委派給 Route 53）登記 example.com 時，Route 53 會建立一個 public hosted zone，並分配四個分散在不同頂層網域的權威名稱伺服器。你在其中新增的每筆 record——A、AAAA、CNAME、MX、TXT、SRV、NS、SOA、Alias——都可在全球解析。

Public hosted zones 的計費方式是前 25 個 zone 每月每個 $0.50，加上查詢費用（Alias 指向 AWS 資源免費；標準 records 按每百萬次查詢計費）。在維運上，SysOps 工程師負責設定 records、掛上 health checks，以及輪換 DNSSEC 金鑰（Route 53 支援 public zones 的 DNSSEC 簽名）。

Private hosted zones

Private hosted zone 只在你明確關聯的 VPC 內部回應 DNS 查詢。同一個網域名稱 example.com 可以同時擁有 public hosted zone（對網際網路可見）與 private hosted zone（只對指定 VPC 可見）——Route 53 稱此為 split-view DNS。Private zone 查詢從每個 VPC 內的 Route 53 Resolver 發起，不會離開 AWS。

Private hosted zones 需要每個關聯 VPC 啟用兩個設定：enableDnsSupport 與 enableDnsHostnames。這兩個設定在預設 VPC 上都預設啟用；新建的自訂 VPC 可能需要明確開啟 enableDnsHostnames。Private zones 不支援 DNSSEC 簽名（這是公共網際網路的功能）。

跨帳號 VPC 關聯

帳號 A 中的 private hosted zone 可以與帳號 B 中的 VPC 建立關聯。兩個帳號透過 route53:CreateVPCAssociationAuthorization（帳號 A）再接 route53:AssociateVPCWithHostedZone（帳號 B）來授權關聯。這個模式常見於多帳號組織架構中，由一個網路帳號擁有 private DNS namespace 並分享給各工作負載帳號。

Record Types：A、AAAA、CNAME 與 Alias

Route 53 支援標準 DNS record types，加上自有的 Alias record。SOA-C02 最常考以下四種。

A 與 AAAA records

A record 將名稱對應到單一 IPv4 位址。AAAA record 將名稱對應到單一 IPv6 位址。兩者都是標準 DNS records——客戶端透過任何 recursive resolver 取得後，依設定的 TTL 快取。適用於目標有固定 IP 位址的情況（客戶自有的 NLB Elastic IP、內部部署伺服器、已知 EIP 後的靜態 EC2 instance）。

CNAME records

CNAME（Canonical Name） record 將一個 DNS 名稱對應到另一個 DNS 名稱。典型用途是 www.example.com → cdn.cloudfront.net。有兩條維運規則在每次 SOA-C02 考試都至關重要：

1. CNAME 不能與相同名稱的任何其他 record 共存。 若 www.example.com 有 CNAME，就不能同時有 A record 或 MX record。
2. CNAME 不能存在於 zone apex（裸網域，例如 example.com）。 這是 DNS 標準的硬性規定，不是 AWS 的限制。Apex 必須存放 SOA 與 NS record，CNAME 在 apex 會與它們衝突。

第二條規則正是 Alias record 存在的原因。

Alias records

Alias record 是 Route 53 的專屬擴充。對客戶端而言它看起來像 A 或 AAAA record（回應是實際 IP 位址，不是跳轉），但 Route 53 在查詢時會動態向目標 AWS 資源查詢 IP。Alias records 有三個特性，使其成為 SOA-C02 面對 AWS 資源目標時的預設答案：

1. Alias 可用於 zone apex。 因為回應是 A record（或 AAAA），不違反 no-CNAME-at-apex 規則。這是將 example.com（裸網域）指向 CloudFront distribution、ALB、S3 website endpoint 或另一筆 Route 53 record 的唯一合法方式。
2. Alias 查詢 AWS 資源免費。 標準 CNAME 查詢按每百萬次計費；Alias 查詢到受支援的 AWS 目標則免費。
3. Alias 自動追蹤資源的 IP。 當 ALB 或 CloudFront 更換 IP 時，Route 53 透明地更新 Alias 解析，無需編輯 zone。

Alias 支援的目標

Alias records 可以指向：

• CloudFront distributions
• Application Load Balancers、Network Load Balancers、Gateway Load Balancers
• API Gateway 自訂網域名稱
• Elastic Beanstalk 環境
• 設定為靜態網站代管的 S3 buckets
• VPC interface endpoints
• Global Accelerator
• 同一 hosted zone 內的另一筆 record set

Alias records 無法指向任意 IP 位址、內部部署系統或第三方 SaaS endpoints——這些情況請使用 A/AAAA 或 CNAME。

Alias vs CNAME 決策矩陣

Routing Policies：Simple、Weighted、Latency、Failover、Geolocation、Geoproximity、Multivalue

Route 53 提供七種 routing policies。SOA-C02 全數考及，但每種的維運觸發線索都足夠獨特，讓你能快速選出正確答案。

Simple routing

預設選項。一筆 record、一組值、不附 health checks。若在單一 Simple record 中列出多個值（一筆 A record 含多個 IP），Route 53 全數回傳，由 resolver 自選——AWS 這端沒有任何決策邏輯。適用於不需要智慧判斷的基本 DNS。

Weighted routing

相同 name 與 type 的多筆 records，各自附上權重（0 到 255）。Route 53 按比例回傳各 record——權重 80 與 20 大約以 80/20 分配。將權重設為 0 可停止回傳該 record，而不必刪除它。

維運用途：藍/綠部署（從 99/1 開始，漸進到 50/50，再到 0/100）、漸進式 region 遷移、A/B 測試。

Latency-based routing

相同 name 與 type 的多筆 records，各自標記 AWS region。Route 53 回傳從 resolver 位置量測延遲最低的那個 region 的 record。延遲資料來自 Amazon 持續量測的網路遙測，而非每次查詢時即時探測。

維運用途：每個 region 都有完整健康服務棧的多 region active-active 部署，目標是最小化使用者感知延遲。搭配 health checks 使失效的 region 自動退出輪流清單。

Failover routing

兩筆 records——一筆標記 Primary，一筆標記 Secondary——相同 name 與 type。Route 53 永遠回傳 Primary，除非其關聯的 health check 失效，才回傳 Secondary。Primary 上的 health check 是必填項（沒有它，policy 就沒有觸發 failover 的依據）。

維運用途：secondary 在另一個 region 或 AZ 的 warm-standby active-passive 災難復原。SOA-C02 的經典場景是「主要應用程式在 us-east-1；若失效，自動路由到 us-west-2 的災難復原服務棧。」

Geolocation routing

多筆 records，各自標記大洲、國家或美國州別（另加一筆特殊的 Default record）。Route 53 回傳與 resolver 地理位置相符的 record，若無符合項則回傳 Default。Geolocation 使用 resolver 的 IP，而非終端使用者的 IP，因此精準度取決於 resolver 位置（ISP resolver 效果好；VPN 使用者精準度較差）。

維運用途：法規遵循（EU 使用者必須打到 EU 服務棧）、授權管理（僅特定國家可串流某影音目錄）、語言本地化（西班牙使用者導向西班牙文內容 origin）。

Geoproximity routing

多筆 records，各自標記 AWS region 或任意經緯度座標，加上 -99 到 +99 之間的可選 bias。Route 53 回傳地理上最靠近 resolver 的 record，但 bias 可以擴大或縮小該 record 涵蓋的地理範圍。正向 bias 讓該 region「變大」（吸引更多使用者）；負向 bias 則縮小覆蓋範圍。Geoproximity 需要 Route 53 traffic flow policy（比基本路由更進階的 UI）。

維運用途：多 region active-active 配合手動流量調整（透過調整 bias，將 10% 的美東使用者移向美西以因應容量需求）。

Multivalue answer routing

相同 name 與 type 最多八筆 records，各自可選附 health check。Route 53 每次查詢隨機順序回傳健康的 records。Multivalue 不是 load balancer（沒有 SLA，沒有 session affinity），但對於需要 health check 的簡單 round-robin DNS 而言，成本遠低於 ELB。

維運用途：公開 IP 後端的小型服務群、private hosted zones 內的內部服務、沙盒環境。

Route 53 Health Checks：Endpoint、Calculated 與 CloudWatch Alarm

Health check 是 Route 53 管理的探針，回傳 Healthy 或 Unhealthy 的判斷結果。會參考 health checks 的 routing policies（Failover、Weighted、Latency、Multivalue、Geolocation、Geoproximity）會將 Unhealthy 的 records 從輪流清單中移除。

三種 health check 類型

1. Endpoint health check — Route 53 本身從全球 15 個以上的 checker 位置，向目標 IP 或 hostname 發送 HTTP、HTTPS 或 TCP 探針。預設間隔為 30 秒（standard）；fast 為 10 秒，需額外付費。預設失敗門檻是連續 3 次探針失敗才切換為 Unhealthy。

2. Calculated health check — 將最多 256 個子 health checks 的結果以門檻規則（N 個中需有 X 個 Healthy）組合。用於複合 DR 訊號（只有 web tier 與 DB tier 都健康時，整體才算健康）。

3. CloudWatch alarm health check — 結果從同帳號的 CloudWatch alarm 讀取。Alarm 為 OK 或 INSUFFICIENT_DATA 時視為 Healthy，進入 ALARM 時視為 Unhealthy。這是連接自訂應用程式遙測（任何 CloudWatch metric）與 Route 53 路由決策的橋梁。

Endpoint health check 設定項目

• Protocol：HTTP、HTTPS、TCP。HTTPS 會驗證 TLS 握手；HTTP/HTTPS 可比對回應 body 中的字串。
• Port 與 path（HTTP/HTTPS）：通常是 /health 或 /ping。
• Interval：30 秒（standard，免費方案適用）或 10 秒（fast，付費）。
• Failure threshold：1–10 次連續失敗才標記為 Unhealthy，預設 3。
• String matching：可選；回應 body 必須包含設定的字串。
• Latency graphs：可在 console 查看；適合在失效發生前偵測效能下降。
• SNI for HTTPS：virtual hosting 或 CloudFront 後方的 endpoint 必須啟用。
• Invert health check status：適用於「預期此 URL 應該是 down 的」情境。
• Disable health check：明確標記為 Unhealthy（強制 failover，用於測試）。

Health check 間隔——必背數字

Health check 最佳實務

• 探測正確的事物。 只打 /index.html 的 health check 測不到後端資料庫；請建立 /health endpoint，只有當應用程式的所有關鍵依賴都回應時才回傳 200。
• TLS endpoint 請用 HTTPS health check，而非 HTTP，因為憑證到期是真實的失效情況，HTTP 探針無法偵測。
• String matching 讓你要求 body 中包含特定健康標記字串（例如 JSON 回應含 "status":"OK"）。
• CloudWatch alarm health checks 讓你能基於無法直接探測的 metrics 觸發 failover——RDS replica lag、SQS oldest message age、Lambda error rate。
• Calculated checks 防止單一元件抖動；要求 3 個子 check 中有 2 個通過，才宣告整體健康。

Route 53 Resolver：混合 DNS 的 Inbound 與 Outbound Endpoints

Route 53 Resolver 是已在每個 VPC 內建的遞迴 DNS resolver，位於 VPC_CIDR_base + 2 位址（AWS 保留的 +2 IP）。它回應所有源自 VPC 的 DNS 查詢，包括關聯到該 VPC 的 private hosted zones 的查詢。純 AWS 工作負載不需要額外設定。

有趣的情境——也是 SOA-C02 的考點——是混合 DNS，即內部部署系統與 AWS 系統需要互相解析對方 namespace 的名稱。

Inbound endpoints——on-prem 查詢 AWS

Route 53 Resolver inbound endpoint 是一組 ENIs（每個 AZ 一個），位於你的 VPC 內，各有一個 IP 位址供內部部署 DNS 伺服器轉送查詢。使用情境：內部部署的企業 DNS 伺服器設定轉發規則「所有 *.aws.example.com 查詢，發送到 inbound endpoint IPs」。Route 53 Resolver 接收查詢，在關聯到 resolver VPC 的 private hosted zone 中查找，回傳答案。

Inbound endpoints 按每個 ENI 計時收費，加上每次查詢費用。請至少在兩個 AZ 各配置一個 ENI 以確保 HA。

Outbound endpoints——AWS 查詢 on-prem

Route 53 Resolver outbound endpoint 是你 VPC 中一組 ENIs，Route 53 Resolver 透過它們將遞迴查詢轉發到內部部署 DNS 伺服器。你還要設定 Resolver rules，對網域名稱做 pattern 比對，並將符合的查詢路由到指定的目標 IPs（on-prem 伺服器）。使用情境：VPC 內的應用程式需要解析 corp.example.com（你的 on-prem Active Directory zone），因此建立轉發規則「*.corp.example.com 轉發到 10.0.0.53 和 10.0.0.54」，掛在 outbound endpoint 上。

Outbound endpoints 同樣按每個 ENI 計時收費，加上每次查詢費用。

Resolver rules

Rules 可跨 VPC 與帳號重複使用（透過 AWS RAM 共享）。常見模式：

• System rules（內建）用於 AWS 內部網域（amazonaws.com、aws.amazon.com）。
• Forward rules 對網域做 pattern 比對，並轉發到指定的目標 IPs。
• Recursive rules 明確使用 Route 53 Resolver 自身的遞迴（用於自主網際網路查詢）。

CloudFront Distribution 基礎

CloudFront distribution 是 CDN 設定的單位：每個公開網域（或 *.example.com 子網域模式）一個 distribution，包含一個或多個 origins、一個預設 cache behavior 加上可選的 path-pattern behaviors，以及在 AWS edge locations 的全球部署存在。

Distribution 類型

• Web distribution（目前 console 的唯一類型；舊版「RTMP」類型已停用）。透過 HTTP/1.1、HTTP/2 和 HTTP/3 提供 HTTP/HTTPS 內容。

一次請求的解剖

1. Viewer 對 cdn.example.com 發出 DNS 查詢，透過 Route 53 Alias 取得 CloudFront edge location IP。
2. TCP/TLS 連線在最近的 CloudFront edge 終止。
3. CloudFront 查找符合請求路徑的 cache behavior。
4. 若物件在 edge cache 中且未過期（cache hit），CloudFront 直接提供。
5. 若否（cache miss），CloudFront 將請求轉發到 origin（S3、ALB、EC2、自訂 HTTP），接收回應，依 cache behavior 的 TTL 選擇性快取，並回傳給 viewer。
6. TTL 視窗內的後續請求從快取提供。

Distribution 設定

• Alternate domain names（CNAMEs）：distribution 回應的公開主機名稱（例如 www.example.com、cdn.example.com）。每個 CNAME 都需要在 us-east-1 的 ACM 中有一張匹配的 SSL 憑證（CloudFront 是全球服務，從 N. Virginia 讀取 ACM）。
• SSL 憑證：預設 *.cloudfront.net 憑證，或自訂 ACM 憑證。
• Default root object：例如從 S3 提供 SPA 時，/ 請求回傳 index.html。
• Geographic restrictions：在 distribution 層級設定國家允許清單或封鎖清單。
• AWS WAF Web ACL：在 distribution 層級掛上 L7 防火牆規則。
• Logging：標準 logs 輸出到 S3，real-time logs 輸出到 Kinesis Data Streams。

CloudFront Origins：S3、ALB 與 Custom HTTP

CloudFront distribution 至少需要一個 origin。SOA-C02 測試 S3、ALB 與 custom HTTP origins 之間的維運差異。

S3 origin（REST endpoint）

最常見的模式：CloudFront distribution 前置於存放靜態資產的 S3 bucket。REST endpoint 形式（bucketname.s3.amazonaws.com）是 CloudFront origin 的建議選擇，因為它原生支援 OAC 與 signed URLs。CloudFront 將 GET 請求轉發給 S3，S3 回傳物件，CloudFront 依 cache behavior 快取。

關鍵點：S3 bucket 不應設為公開——OAC 確保只有 CloudFront 能讀取 bucket。

S3 origin（website endpoint）

Website endpoint 形式（bucketname.s3-website-us-east-1.amazonaws.com）只在你依賴 REST endpoint 不支援的 S3 靜態網站功能時才需要：目錄索引文件（/folder/ 回傳 /folder/index.html）、重定向規則，以及自訂錯誤頁面。Website endpoint 不支援 OAC——若要限制只有 CloudFront 能存取，只能依賴 bucket policy 中的 Referer header 秘鑰，安全性遠低於 OAC。

Application Load Balancer origin

動態內容（EC2 代管的應用程式、ALB 後方的 ECS 服務）以 ALB 作為 origin。透過 ALB 的 DNS name 連接；ALB 監聽規則的安全群組可以限制來源 IP 只允許 CloudFront managed prefix list（com.amazonaws.global.cloudfront.origin-facing），確保只有 CloudFront edge locations 能抵達 ALB。搭配 CloudFront 注入的自訂 header（例如 X-Custom-Origin-Verify: <secret>），以及 ALB 監聽規則過濾掉缺少該 header 的請求，就能達到與 OAC 等效的保護。

Custom HTTP origin

任何可透過公共網際網路到達的 HTTP/HTTPS endpoint——有公開 IP 的 EC2 instance、on-prem 資料中心、第三方 API。設定方式與 ALB 模式相同：通訊協定 policy、port、path、自訂 headers。

S3 Origin 的 OAC vs OAI：現代模式

Origin Access Control（OAC） 是 AWS 目前建議的 S3 origin 存取限制機制。Origin Access Identity（OAI） 是舊版機制，自 2022 年 8 月起已被 OAC 取代而棄用——現有 distributions 仍受支援，但不建議用於新建的 distributions。

OAC 的運作方式

1. 在 CloudFront 建立 OAC 資源（OriginAccessControl），指定名稱、簽名協定（SigV4——AWS Signature Version 4），以及簽名行為（Always——永遠簽名，建議選項；Never——永不簽名；或 No-Override——除非 viewer 已提供，否則簽名）。
2. 在 distribution 的 origin 設定中，將 OAC 附加到 S3 origin。
3. 更新 S3 bucket policy，授予 s3:GetObject（以及選擇性地 s3:GetObjectVersion）給 CloudFront service principal（cloudfront.amazonaws.com），並加上條件限定特定 distribution ARN（AWS:SourceArn）。
4. CloudFront 使用自身的 service-principal 憑證，以 SigV4 對每個發往 S3 的 origin 請求簽名，限定到特定 OAC 與 distribution。
5. S3 評估 bucket policy，只授權符合設定 CloudFront source ARN 的請求。

OAC 優於 OAI 的理由

• OAC 支援 SSE-KMS 加密的 S3 物件。 OAI 無法解密 SSE-KMS 物件，需要額外授權；OAC 在 SigV4 簽名中包含 KMS context。
• OAC 支援所有 AWS regions，包括 opt-in regions。 OAI 在部分較新的 regions 缺乏支援。
• OAC 支援 GET/HEAD 以外的 HTTP methods（PUT、POST 用於透過 CloudFront 上傳的模式）——OAI 僅限 GET/HEAD。
• OAC 透過 AWS:SourceArn 條件限定到單一 distribution；OAI 的限定是透過在 OAI 層級共享的 OAI principal（精確度較低）。

從 OAI 遷移到 OAC

遷移步驟直接明瞭：

1. 在 distribution 中建立一個 OAC。
2. 將 OAC 附加到 S3 origin（若逐步遷移，現有 OAI 可暫時保留）。
3. 在 S3 bucket policy 中新增一段，授予透過 CloudFront service principal（限定 distribution ARN）存取的權限。
4. 用一個範例物件測試——確認 CloudFront 透過 OAC 正常提供。
5. 從 S3 bucket policy 中移除 OAI principal 那段。
6. 從 distribution 卸下並刪除 OAI。

Cache Behaviors 與 TTL

Cache behavior 是附加到 path pattern 的規則，控制符合路徑的請求如何轉送、快取與修改。每個 distribution 有且僅有一個預設 cache behavior（*），加上零個或多個特定路徑 behaviors。Behaviors 按順序評估——第一個匹配的路徑勝出。

Behavior 設定項目

• Path pattern：例如 *.jpg、/images/*、/api/*、*（預設）。
• Origin：此路徑符合時，由哪個設定好的 origin 處理請求。
• Viewer protocol policy：HTTP and HTTPS、Redirect HTTP to HTTPS、HTTPS Only。
• Allowed HTTP methods：GET, HEAD（快取安全）；GET, HEAD, OPTIONS；GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE。
• Cache policy：可重複使用的 policy，控制 cache key（哪些請求屬性構成 cache key）與 TTLs。
• Origin request policy：可重複使用的 policy，控制 CloudFront 轉發到 origin 的 headers、cookies 與 query strings（與構成 cache key 的部分分開設定）。
• Response headers policy：在回應上附加/覆寫 headers（CORS、安全性 headers）。
• Function associations：在四個觸發點附加 CloudFront Functions 或 Lambda@Edge。

TTLs 與快取控制

CloudFront 的 TTL 行為同時由 cache policy 的 MinTTL / DefaultTTL / MaxTTL 和 origin 的 Cache-Control、Expires 回應 headers 共同決定：

• 若 origin 回傳 Cache-Control: max-age=N，CloudFront 使用 N（夾在 MinTTL 與 MaxTTL 之間）。
• 若 origin 未回傳任何快取 headers，CloudFront 使用 DefaultTTL（在 AWS 管理的 CachingOptimized policy 中預設為 24 小時 = 86,400 秒）。
• Cache-Control: no-store 或 no-cache 會被遵守——CloudFront 不快取。
• 將 MinTTL = MaxTTL = DefaultTTL = 0 可完全停用該路徑的快取（適合 /api/* 路徑）。

Cache key 組成

Cache key 是 CloudFront 用來索引快取物件的依據。相同 cache key 的兩個請求會收到相同的快取物件。Cache key 可包含的選項：

• Query strings：無、全部，或指定清單。
• Headers：無、全部，或指定清單。
• Cookies：無、全部，或指定清單。

包含越多屬性在 cache key 中，快取越碎片化（命中率越低），但允許差異化回應；包含越少則命中率越高，但回應趨於一致。

Cache invalidations

Cache invalidation 是對 distribution 發出「立刻讓這個物件過期」的明確請求。你提供路徑或 path pattern（/index.html、/css/*、/* 代表全部）。CloudFront 在幾分鐘內將 invalidation 傳播到所有 edge locations；後續請求會 cache miss 並重新從 origin 抓取。

Invalidations 要收費：每月每帳號前 1,000 個 invalidation paths 免費；超過後每個 path $0.005。萬用字元如 /* 計為一個 path。SOA-C02 有時會問「頻繁更新的內容應該 invalidate 還是設短 TTL？」——答案是短 TTL（或版本化檔名，如 app.v123.js），因為每次部署後執行 invalidation 既浪費又緩慢。

CloudFront Functions vs Lambda@Edge

CloudFront 支援兩種 edge 端的運算選項：CloudFront Functions 與 Lambda@Edge。兩者不可互換；SOA-C02 測試其差異。

CloudFront Functions

輕量 JavaScript，在最靠近 viewer 的 edge location 以自訂 V8-based 執行環境運行。限制：

• 僅限 JavaScript（ECMAScript 5.1 + 部分 async 子集）。
• 典型執行時間低於毫秒，最長 1 ms。
• 無網路存取（無法呼叫其他服務，無法讀取 S3）。
• 最大記憶體約 2 MB。
• 僅在 viewer-request 與 viewer-response 觸發點執行。
• 前 200 萬次 invocations 每月免費，之後每百萬次 $0.10。

適用於：header 重寫、URL 重寫、A/B 測試路由、簡單的驗證 token 驗證、重定向。

Lambda@Edge

標準 Lambda function，在 CloudFront 區域 edge caches（12 個 cache regions，不是全部 600 個以上的 edge locations）運行。限制：

• Node.js 或 Python 執行環境。
• viewer-request/viewer-response 最多 5 秒，origin-request/origin-response 最多 30 秒。
• 有網路存取，可連接 AWS 服務與網際網路。
• 最多 10,240 MB 記憶體。
• 在所有四個觸發點執行：viewer-request、origin-request、origin-response、viewer-response。
• 標準 Lambda 定價加上每次請求費用。

適用於：需要呼叫 AWS API 的複雜邏輯、需要 DynamoDB 查詢的動態回應、圖片處理、需要秘鑰的 signed URL 生成。

CloudFront Price Classes

CloudFront edge locations 按照 AWS 維運成本組織成定價層級。若你的受眾是區域性的，可以限制 distribution 到更便宜的層級。

• Price Class All — 使用全球每個 edge location。預設。效能最佳，成本最高。
• Price Class 200 — 排除最昂貴的南美洲、非洲和澳洲 edges。針對排除這些地區的全球受眾而言，是合理的平衡點。
• Price Class 100 — 限制在北美洲、歐洲和以色列。最便宜。當受眾集中在這些地區時使用。

限制 price class 只改變哪些 edges 快取和提供內容。被排除 region 的 viewers 仍能獲得服務——只是從更遠的 edge——因此他們的延遲會較高。SOA-C02 直接測試這點：「應用程式只有歐盟客戶使用；請在不更改公開 DNS 的情況下最小化 CloudFront 成本。」答案：Price Class 100。

S3 靜態網站代管

S3 可透過其 website endpoint 直接提供靜態網站，這個 URL 與 REST endpoint 不同，支援幾個對 HTML 友善的功能。

啟用靜態網站代管

1. 開啟 bucket → Properties → Static website hosting → Enable。
2. 設定 index document（通常是 index.html）與 error document（通常是 error.html 或 404.html）。
3. 選擇性設定 redirection rules（例如將所有 404 重定向到 /index.html 以支援 SPA 風格的路由）。
4. Bucket 現在可透過 http://bucketname.s3-website-region.amazonaws.com 存取。

公開存取要求

靜態網站代管需要 bucket 上的公開讀取存取——通常透過以下方式啟用：

1. 在 bucket 層級停用 Block Public Access。
2. 設定 bucket policy，授予 s3:GetObject 給 Principal: "*" 適用於整個 bucket 前綴。

這比透過 CloudFront + OAC 管控存取要不安全得多。考試的正確模式幾乎總是：保持 S3 私有，使用 S3 REST endpoint origin 與 OAC 在 bucket 前方放置 CloudFront，並從 apex（example.com）使用 Route 53 Alias record 指向 CloudFront distribution。

何時使用 website endpoint vs REST endpoint

場景解析：Failover 後流量跑錯 Region

這是 SOA-C02 的典型場景之一。生產環境在 us-east-1（Primary），DR warm standby 在 us-west-2（Secondary），設定了 Route 53 Failover routing 與 primary ALB 上的 health check。Primary 失效後，部分使用者立即路由到 us-west-2，但其他使用者仍繼續打到已故障的 us-east-1 長達數分鐘。疑難排解流程：

1. 確認 health check 確實已翻轉。 在 Route 53 console 中，health check 狀態應顯示 Unhealthy。若停留在 Healthy，health check 探針本身設定有誤——/health endpoint 可能太膚淺（例如回傳 200 的程序其實已當掉）。
2. 確認 failover record 指向正確的 secondary。 常見錯誤是 Secondary record 指向一個過時的 us-west-2 Alias。
3. 檢查 DNS record 的 TTL。 若 failover record 的 TTL 是 300 秒，全球 recursive resolvers 在 Route 53 將其標記為 Unhealthy 後仍最多快取 Primary 的 IP 長達 5 分鐘。部分使用者需等到快取條目過期才會看到新答案。修正：對 failover 關鍵 records，TTL 設為 60 秒甚至更低。
4. 檢查失敗門檻與間隔。 標準 30 秒間隔搭配 3 次失敗 = 90 秒才翻轉。再加上 60–300 秒的 TTL 以及 recursive resolver 的快取行為，總 failover 時間可能達到 4–5 分鐘。若要壓縮恢復時間，切換到 fast（10 秒）health checks。
5. 瀏覽器與作業系統快取。 即使 TTL 只有 60 秒，部分瀏覽器在 tab 的生命週期內都會快取 DNS。Route 53 對此無能為力——只能教育使用者重試或重新整理頁面。

修正方法很少是 routing policy 或 failover 設定本身——而是 TTL 調整與 health check 敏感度。SOA-C02 精確測試這個模式；答案通常是「降低 failover record 的 TTL 並使用 fast health checks」。

場景解析：S3 更新後 CloudFront 仍提供舊內容

網站團隊將 index.html 上傳到 S3 origin，但 viewers 繼續看到舊內容長達數小時。疑難排解流程：

1. 檢查快取物件的 TTL。 若 index.html 上傳時沒有 Cache-Control header，CloudFront 使用預設的 24 小時 TTL。新的副本要等 24 小時後才會被提供。
2. 確認 origin 確實已有新內容。 aws s3 cp s3://bucket/index.html - 應該印出新內容。若不是，代表上傳失敗。
3. 執行 invalidation。 aws cloudfront create-invalidation --distribution-id ABC --paths "/index.html" 在幾分鐘內從所有 edges 清除該路徑。每月前 1,000 個 paths 免費。
4. 修正根本原因以防再次發生。 在上傳時為 S3 物件 metadata 加上 Cache-Control: max-age=300（aws s3 cp ... --cache-control "max-age=300"），或在相關 cache behavior 上使用 DefaultTTL 較短的 cache policy，或改用版本化檔名讓快取自動失效。

常見陷阱：Alias 只能指向同類 AWS 服務目標

一個隱微的干擾項：考生誤以為 Route 53 Alias 可以指向任意 DNS 名稱。並不行——Alias 目標僅限於前面列出的受支援 AWS 資源類型（CloudFront、ALB/NLB/GWLB、API Gateway、Beanstalk、S3 website、VPC interface endpoint、Global Accelerator、另一筆 Route 53 record）。把 Alias 指向第三方 SaaS hostname 是無效的；請用 CNAME（這樣 record 就只能放在 apex 以外的位置）。把 Alias 指向任意 IP 同樣無效；請用 A record。

常見陷阱：CNAME at Zone Apex 是無效 DNS

值得重申，因為這是考最多次的規則：DNS 標準禁止 CNAME 在 zone apex（網域本身，如 example.com）出現，因為 apex 必須持有 SOA 與 NS record，而 CNAME 會與它們衝突。Route 53 的 Alias record 就是為了解決 AWS 資源目標的這個問題而存在。若 SOA-C02 的干擾選項提議「在 apex 建立一個 CNAME 指向 CloudFront distribution」，定義上就是錯的。Apex 請永遠使用 Alias。

常見陷阱：CloudFront 預設 TTL 是 24 小時

若 origin headers 不存在，CloudFront 依 cache policy 的 DefaultTTL 快取——在 AWS 管理的 CachingOptimized policy 中是 24 小時。不設定 Cache-Control 的即時內容網站會看到嚴重的舊內容問題。修正在 origin 端（設定 Cache-Control），而非在 CloudFront 層級（僅降低 MaxTTL 並不影響 origin 無聲時的預設行為）。

常見陷阱：OAI 已棄用——請使用 OAC

現有的 OAI 設定仍然有效，但所有新 distributions 都應使用 OAC。SOA-C02 明確測試「設定 CloudFront 與 S3 origin access control（OAC）」——這個措辭本身就在告訴你 OAC 才是預期答案。

SOA-C02 vs SAA-C03：維運視角的差異

SAA-C03 與 SOA-C02 都考 Route 53 與 CloudFront，但切入視角不同。

SAA 考生選擇 routing policy；SOA 考生診斷為何它在生產環境中沒有正常運作。

考試訊號：如何辨識 Domain 5.2 的題目

SOA-C02 的 Domain 5.2 題目遵循可預測的模式。認出它們，每題的作答時間大幅縮短。

• 「Apex 網域指向 CloudFront / ALB」 — 答案是 Alias。CNAME at apex 是無效 DNS。
• 「Failover 沒有翻轉」 — 檢查 health check 探針目標、失敗門檻，以及 record 上的 DNS TTL。
• 「CloudFront 提供舊內容」 — Origin 缺少 Cache-Control，預設 TTL 24 小時。在 origin 端修正或執行 invalidation。
• 「將 S3 限制為只有 CloudFront 可存取」 — OAC + bucket policy，以 cloudfront.amazonaws.com principal 限定 AWS:SourceArn。OAI 是過時的答案。
• 「混合 DNS，VPC 解析 on-prem AD」 — Route 53 Resolver outbound endpoint + forwarding rule。
• 「混合 DNS，on-prem 查詢 AWS private zone」 — Route 53 Resolver inbound endpoint + on-prem forwarder rule。
• 「降低區域受眾的 CloudFront 成本」 — Price Class 100 或 200。
• 「在 edge 進行輕量 URL 重寫」 — CloudFront Functions，不是 Lambda@Edge。
• 「Edge function 需要查詢 DynamoDB」 — Lambda@Edge，不是 CloudFront Functions。
• 「多 region active-active 追求效能」 — Latency-based routing 搭配 health checks。
• 「Active-passive DR」 — Failover routing 搭配 Primary 上的 health check。
• 「法規地理限制」 — Geolocation routing。
• 「手動微調 region 流量比例」 — Geoproximity 搭配 bias。
• 「小型服務群的低成本 round-robin」 — Multivalue answer routing。

決策矩陣——各 SysOps 目標對應的 Route 53 / CloudFront 構件

考試時用這張表快速查找。

常見陷阱總覽——Route 53 DNS 與 CloudFront

每次 SOA-C02 考試都會出現其中兩三個干擾項。

陷阱 1：CNAME at apex

Apex（裸 example.com）不能放 CNAME。請使用 Alias。

陷阱 2：Alias 指向非 AWS 目標

Alias 只解析到受支援的 AWS 資源。第三方 hostname 請用 CNAME（放在 apex 以外），或用 A record。

陷阱 3：Latency routing 沒有附 health checks

沒有 health checks，latency-based routing 在最近的 region 故障時仍持續回傳那個 region 的 record。Latency routing 一定要搭配 health checks。

陷阱 4：Failover routing 的 Primary 沒有 health check

沒有 health check，Route 53 沒有 Primary 失效的訊號，永遠不會回傳 Secondary。Health check 在 Primary record 上是必填項。

陷阱 5：TTL 對 failover 而言設太長

300 秒（或更長）的 TTL 意味著 Route 53 翻轉後，cached 的過期答案可能持續長達 5 分鐘。對 failover 關鍵 records，TTL 設 60s 或更低；搭配 fast health checks。

陷阱 6：CloudFront 預設 TTL 是 24h，不是 0

若 origin 不傳 Cache-Control，CloudFront 依 cache policy 的 DefaultTTL 快取——預設 24 小時。請在 origin 端設定 headers 或縮短 DefaultTTL 以提供新鮮內容。

陷阱 7：對新 distributions 使用 OAI

OAI 已棄用。請使用 OAC。

陷阱 8：靜態網站使用公開 S3 bucket

現代模式是讓 bucket 保持私有，透過帶有 OAC 的 CloudFront 管控存取。公開 bucket 只能接受用於示範。

陷阱 9：Inbound vs outbound resolver 方向搞反

Inbound = on-prem 查詢 AWS。Outbound = AWS 查詢 on-prem。依題目措辭核對解析的方向。

陷阱 10：CloudFront Functions 用於需要 Lambda@Edge 的場景

CloudFront Functions 無法發出網路呼叫。若情境需要 DynamoDB、S3 或任何 AWS API，必須使用 Lambda@Edge。

陷阱 11：頻繁 invalidation 而非版本化檔名

超過每月前 1,000 個 paths 後，invalidation 開始收費，且速度比讓版本化檔名的快取條目自然過期要慢。原生模式是內容雜湊檔名（main.a1b2c3.js）。

FAQ — Route 53 DNS 與 CloudFront

Q1：為什麼我不能在 example.com 建立 CNAME？

DNS 標準（RFC 1035）禁止 CNAME 與任何其他 record 在相同名稱共存，而 zone apex 必須持有 SOA record（zone 的起始授權記錄）以及至少一筆 NS record（zone 的名稱伺服器）。CNAME at apex 會與兩者衝突，因此標準不允許。Route 53 的 Alias record 是 AWS 的解決方案：它看起來像 A 或 AAAA record（與 apex 的需求相容），但動態解析到受支援 AWS 資源的 IPs。每當你需要將裸網域指向 CloudFront distribution、ALB、S3 website endpoint 或其他受支援資源時，請使用 Alias。

Q2：Failover routing 與 Latency-based routing 有何不同？

Failover 是 active-passive——Route 53 永遠回傳 Primary record，除非其 health check 失效才回傳 Secondary。Secondary 在正常情況下閒置。Latency-based 是 active-active——每筆 record（每個 region 一筆）都在輪流中，Route 53 回傳 requesting resolver 延遲最低的那筆，並可選擇性地透過 health checks 移除不健康的 region。Failover 用於 DR（另一個 region 的 warm standby）；latency-based 用於所有 region 都跑相同工作負載的跨 region 效能優化。SOA-C02 兩者都考，關鍵詞是「災難復原」（failover）vs「最小化全球使用者延遲」（latency-based）。

Q3：Route 53 可以多快完成 failover？

總 failover 時間是以下各項的總和：health check 偵測時間（間隔 × 失敗門檻）、record 上的 DNS TTL，以及任何客戶端的 DNS 快取。標準 30 秒間隔搭配 3 次失敗門檻，偵測需 90 秒。Record 上 60 秒的 TTL，recursive resolvers 在另外 60 秒內更新。大多數使用者的總計：約 150 秒，部分快取積極的客戶端會更長。若要壓縮預算，切換到 fast（10 秒）health checks（30 秒偵測），TTL 調低到 60 秒甚至 30 秒。純透過 DNS 通常無法達到 30 秒以下的 failover——要做到這點，請使用帶有 anycast IPs 的 Global Accelerator。

Q4：何時選 Geoproximity 而非 Geolocation？

Geolocation 將 resolver 的地理位置對應到固定的 region 集合（大洲、國家、美國州別），回傳符合的 record 或 Default。它是二元的——使用者要麼在西班牙，要麼不在。Geoproximity 使用地理距離對應到 AWS regions 或任意經緯度點，並有可調整的 bias 來擴大或縮小每個 region 的服務範圍。當有法規或授權限制（必須在特定國家）時，用 Geolocation；當需要效能驅動的路由，並想精細手動控制每個 region 吸收多少流量時，用 Geoproximity。

Q5：為什麼我更新 S3 物件後，CloudFront distribution 仍提供舊內容？

兩個可能原因。(a) Origin 物件沒有 Cache-Control header，所以 CloudFront 快取了 24 小時（AWS 管理的 CachingOptimized cache policy 的預設 TTL）。修正：在 S3 物件上設定 Cache-Control: max-age=300，或使用 DefaultTTL 較短的 cache policy。(b) Cache key 隨著更新沒有變化——CloudFront 依 URL 加上設定的 headers/cookies/query strings 作為 key；若 URL 相同且快取未過期，CloudFront 無論 origin 是否更新都回傳快取副本。若要強制重新抓取，(i) 對受影響的路徑發出 cache invalidation，或 (ii) 在檔名加上版本後綴讓 URL 改變。

Q6：新建 CloudFront-S3 設定應該用 OAC 還是 OAI？

新 distributions 一律用 OAC。OAI 自 2022 年 8 月起已棄用，由 OAC 取代。OAC 新增了對 SSE-KMS 加密 S3 物件的支援、所有 AWS regions（包括 opt-in regions）、其他 HTTP methods（PUT/POST），以及透過 AWS:SourceArn 條件進行每個 distribution 的限定。OAI 在現有 distributions 上仍受支援，但 SOA-C02 明確測試「設定 CloudFront 與 S3 origin access control（OAC）」——OAC 是預期的現代答案。從 OAI 遷移到 OAC 是一個四步驟的 bucket policy 更新；AWS 在 CloudFront Developer Guide 中發布了詳細程序。

Q7：Route 53 Resolver 的 inbound 與 outbound endpoint 有何不同？

Inbound 從 on-premises 接收進入 AWS 的 DNS 查詢。Endpoint 在你的 VPC 中配置帶有私有 IP 的 ENIs，on-prem DNS 伺服器可將其設定為轉發目標。使用情境：on-prem 應用程式需要從關聯到 resolver VPC 的 private hosted zone 解析 db.aws.example.com。Outbound 從 AWS 發送出去的 DNS 查詢到 on-premises。Endpoint 配置 Route 53 Resolver 用作已轉發查詢來源的 ENIs；你設定 Resolver rules，對網域名稱做 pattern 比對，並將其路由到指定的 on-prem 目標 IPs。使用情境：AWS 應用程式需要從 on-prem Active Directory 解析 corp.example.com。雙向混合 DNS 需要兩種 endpoints 都建立。

Q8：何時 CloudFront Functions 就夠用，何時需要 Lambda@Edge？

CloudFront Functions 在每個 edge location 執行次毫秒的 JavaScript，沒有網路存取，記憶體上限約 2 MB。適合 header 重寫、URL 重寫、簡單驗證 token 驗證、A/B 測試路由，以及 HTTP 到 HTTPS 的重定向。Lambda@Edge 在區域 edge caches 執行 Node.js 或 Python，有完整的網路存取（AWS API 呼叫、網際網路），最多 10 GB 記憶體，最多 30 秒執行時間。當需要查詢 DynamoDB、以 Secrets Manager 的秘鑰簽名 URL、轉換圖片，或呼叫外部 API 時，選 Lambda@Edge。CloudFront Functions 每百萬次 invocations 費用 $0.10；Lambda@Edge 按標準 Lambda 定價加上每次請求費，因此在兩者都可行時，預設選 Functions。

Q9：如何追蹤 CloudFront cache hit ratio？

CloudFront 在 CloudWatch 的 AWS/CloudFront namespace 下發布 CacheHitRate metric，dimension 為 DistributionId。此 metric 是從快取提供的 viewer 請求相對於轉發到 origin 的比例。健康的靜態內容 distribution 通常命中率 90% 以上；較低的數字表示 cache keys 過度碎片化（包含太多 headers/cookies/query strings）、TTL 太短，或 invalidation 太頻繁。搭配 CloudFront access logs（輸出到 S3）或 real-time logs（Kinesis Data Streams）——每筆請求的 x-edge-result-type 欄位顯示 Hit、Miss、RefreshHit、LimitExceeded 或 Error，可進行每個路徑的快取命中分析。

Q10：如何鎖定 ALB origin，確保只有 CloudFront 可以抵達？

兩層保護。網路層：設定 ALB 的安全群組，讓監聽 ports 的 inbound 只允許來自 CloudFront managed prefix list（com.amazonaws.global.cloudfront.origin-facing），AWS 會持續更新這個 prefix list 以反映所有 CloudFront edge IP 範圍。應用程式層：設定 CloudFront distribution 在所有 origin 請求中注入一個自訂秘密 header（例如 X-Custom-Origin-Verify: <隨機字串>），並設定 ALB 監聽規則只轉發帶有該 header 的請求——拒絕其餘的。兩層組合確保即使攻擊者發現了 ALB DNS 名稱，並從 CloudFront IP 範圍連接，仍然無法繞過 CloudFront，因為他們猜不到 header 秘鑰。SOA-C02 精確測試這個模式，作為 ALB origins 的 OAC 等效做法。

延伸閱讀與相關維運模式

• Amazon Route 53 Developer Guide
• Working with Hosted Zones
• Choosing a Routing Policy
• Configuring DNS Failover
• Route 53 Health Check Types
• Choosing Between Alias and Non-Alias Records
• Route 53 Resolver
• Getting Started with Route 53 Resolver Endpoints
• Amazon CloudFront Developer Guide
• Restricting Access to S3 Origins (OAC)
• Creating a CloudFront Distribution
• Increasing the Cache Hit Ratio
• Invalidating Files
• CloudFront Price Classes
• CloudFront Functions and Lambda@Edge
• S3 Static Website Hosting
• AWS SOA-C02 Exam Guide v2.3 (PDF)

Route 53 與 CloudFront 正確設定之後，下一個維運層是：VPC configuration and connectivity，提供 Route 53 Resolver endpoints、ALB origins 與 CloudFront origin access 連接的私有網路；WAF、Shield 與 network protection，掛在 CloudFront distribution 上的 L7 過濾與 DDoS 防護；backup and disaster recovery procedures，在區域中斷時驅動 failover routing policy；以及 CloudWatch metrics、alarms 與 dashboards，將 Route 53 health check 狀態與 CloudFront cache-hit metrics 納入維運儀表板。

• VPC Configuration, Subnets, NACLs, and Private Connectivity — SOA-C02 Study Notes
• WAF, Shield, and Network Protection Services — SOA-C02 Study Notes
• Backup, Restore, and Disaster Recovery Procedures — SOA-C02 Study Notes
• CloudWatch Metrics, Alarms, and Dashboards — SOA-C02 Study Notes