Day 14 的 ELB 建好後，AWS 會給它一個自動產生的名稱，例如 my-alb-1234567890.us-east-1.elb.amazonaws.com。這個名稱連得上，但太長、沒有意義，不適合給使用者輸入。ELB 背後的 IP 也會隨擴展和維護改變，無法把固定 IP 寫進網域設定。

使用者輸入的是 www.example.com，中間需要一個服務把這個名稱對應到 ELB，這個服務是 DNS。瀏覽器連線前先向 DNS 查詢「www.example.com 在哪裡」，拿到答案後直接連到目標。AWS 的 DNS 服務是 Route 53。

DNS 只回答這一次查詢，之後的請求和回應都不經過它。因此 Route 53 的「路由策略」不是在轉送流量，而是同一個名稱有多個候選答案時，決定回哪一個。

名稱對應完成後，還有連線速度的問題：源站在美東，台灣使用者的每次請求都要跨太平洋。這部分由 CloudFront 和 Global Accelerator 處理，放在後半段。

🗺️ 一次連線會經過的地方

後面五段依照一次連線的順序排列：

• ①～③ 發生在 Route 53 裡，決定回答哪個位址。查詢結束後，Route 53 就不再參與。
• ④、⑤ 位在連線路徑上，處理連線的速度與穩定度。

每一段處理的，都是上一段解決之後接著出現的問題。

🔗 ① 把網域指向 ELB：CNAME 與 Alias

一個網域的所有 DNS 記錄放在 Route 53 的 hosted zone 裡，一個網域對應一個 hosted zone。最基本的記錄是 A 記錄：把名稱對應到一個 IP。

ELB 的 IP 會變，無法用 A 記錄寫死 IP。需要的是「名稱對應到另一個名稱」：把 www.example.com 指向 ELB 自動產生的那串名稱。有兩種記錄做得到：

根網域是指沒有 www 這類前綴的 example.com 本身。DNS 規定 CNAME 不能和其他記錄共用同一個名稱，而根網域一定有 NS、SOA 這兩筆管理網域本身的記錄，所以根網域放不了 CNAME。Alias 不受這個限制：Route 53 收到查詢時，直接查出目標資源當下的 IP，以 A 記錄的形式回答。

指向 AWS 資源時用 Alias；根網域指向 ELB，只能用 Alias。

🧭 ② 一個名稱有多個目標：路由策略

網站只有一個 ELB 時，一筆 Alias 記錄就夠了。之後目標會變多：新版本放在另一個 ELB、在歐洲開第二個 Region、準備一個備援站。同一個名稱底下有多筆記錄時，路由策略決定這次查詢回哪一筆。

八種策略依「挑選的依據」分成四組：

依使用者位置的四種裡，Latency 和 Geolocation 最容易混淆：Latency 看哪裡快，Geolocation 看人在哪。 歐洲使用者連美國可能比較快，Latency 會回美國；法規要求歐洲的資料留在歐洲時，用的是 Geolocation。

Weighted 的記錄範例：

www.example.com  A  Weight 90  → ALB-v1（舊版）
www.example.com  A  Weight 10  → ALB-v2（新版）
→ 十次查詢大約九次回舊版、一次回新版；新版穩定後再把權重調過去

策略之間可以組合。第 ① 段提到 Alias 能指向同一個 hosted zone 的其他記錄，所以一筆 Geolocation 記錄可以再指向一組 Latency 記錄，組成兩層規則。

表格最後一列的 Failover，以及 Multi-value，都需要知道目標是否還活著，這是下一段的 health check。

🩺 ③ 判斷目標是否活著：Health check

Route 53 只負責回答，本身不知道目標有沒有壞。Failover 和 Multi-value 靠 health check 取得這個資訊：Route 53 從全球十幾個地點定期連線到目標，超過 18% 的地點回報正常就判定為健康。從多個地點檢查，是為了避免單一地點的網路問題造成誤判。

health checker 位在網際網路上，所以依目標能不能從網際網路連到，分成三種：

Failover 記錄
www.example.com  A  Failover PRIMARY    → ALB（us-east-1）  health check: hc-1
www.example.com  A  Failover SECONDARY  → S3 靜態維護頁
→ hc-1 失敗，Route 53 開始回 SECONDARY；恢復後自動切回

DNS 切換的限制：TTL

health check 失敗後，Route 53 立刻改回 secondary，但使用者不一定馬上連到 secondary。DNS 的答案會被客戶端和中間的 DNS 伺服器快取，快取時間由記錄的 TTL 決定；TTL 到期前，客戶端會繼續拿舊答案連到已經壞掉的主站。

計畫性的切換（例如搬移網站）會事先把 TTL 調短（例如 60 秒），切換完再調回去。即使如此，部分客戶端仍會快取得比 TTL 更久。這個限制在第 ⑤ 段會再出現。

🌍 ④ 縮短距離：CloudFront

①～③ 決定了使用者連到哪個 ELB，但距離沒有改變：開頭提到的美東源站，台灣使用者的每次請求仍然要跨太平洋。

CloudFront 在全球幾百個邊緣節點（edge location）快取內容。使用者連到最近的節點，節點有快取就直接回應，沒有才回源站（origin）取得。搭配 Route 53 時，網域用 Alias 指向 CloudFront，CloudFront 再把 ELB 設為源站，也就是總覽圖中 ④ 的位置。

快取對靜態內容效果最好。動態內容也能經過 CloudFront，但每次內容不同、快取命中率低，主要的好處是邊緣節點到源站這段改走 AWS 骨幹網路。

CloudFront 的前提是 HTTP/HTTPS 內容。下一段處理這個前提以外的情況。

⚡ ⑤ 非 HTTP 流量與秒級切換：Global Accelerator

CloudFront 處理不了兩種情況：

• 流量不是 HTTP：線上遊戲、IoT、VoIP 常用 UDP 或其他 TCP 協定，CloudFront 無法轉送。
• 切換不能受 DNS 快取影響：第 ③ 段提到，Route 53 的切換要等客戶端的 DNS 快取過期。

Global Accelerator 提供兩個固定的 anycast IP，全球的邊緣節點都用這兩個 IP 對外。使用者連到最近的邊緣節點後，流量走 AWS 骨幹網路到後端的 ELB；它不快取內容，支援任何 TCP/UDP。後端某個 Region 失效時，Global Accelerator 在數秒內把流量改送到其他 Region，使用者連的 IP 不變，所以不受 DNS 快取影響。固定 IP 也方便企業客戶加入防火牆白名單。

內容可以快取 → CloudFront；不是 HTTP、需要固定 IP、需要秒級切換 → Global Accelerator。

📌 補充

✅ 小結

摘要：Route 53 決定回答哪個位址——Alias 指向 AWS 資源，路由策略在多個目標間挑選，health check 排除壞掉的目標。答案回給使用者後，CloudFront 用快取縮短距離，Global Accelerator 處理非 HTTP 流量和不受 DNS 快取影響的切換。

🧠 AI 出題

問題 1

某跨國電商在 eu-central-1、us-east-1、ap-northeast-1 各部署一套網站，各自有一個 ALB，對外網域是 shop.example.com。法遵部門要求：歐洲使用者的請求一律由 eu-central-1 處理，不論哪個 Region 比較快；其他地區的使用者則要連到延遲最低的 Region。一位解決方案架構師需要用 Amazon Route 53 設定這個網域的 DNS 記錄。

哪一個設定方式符合需求？

• A. 對三個 ALB 各建立一筆 latency 記錄，並為 eu-central-1 那筆記錄掛上 health check
• B. 為三個 ALB 建立 geoproximity 記錄，把 eu-central-1 的 bias 調到最大，擴大它涵蓋的地理範圍
• C. 建立 geolocation 記錄：歐洲指向 eu-central-1，預設位置指向美、日兩個 ALB 各占一半的 weighted 記錄
• D. 建立 geolocation 記錄：歐洲指向 eu-central-1，預設位置以 alias 指向美、日 ALB 的 latency 記錄

問題 2

某公司的內部人事系統只在 VPC 內使用，以 private hosted zone 的 hr.corp.internal 解析到 us-east-1 的主要 EC2，這台機器只有 private IP。另一台位於 us-west-2 的備援 EC2 已持續同步資料。公司要求主要機器的應用程式無法回應時，DNS 要自動改為回應備援機器的 IP，兩台機器都不能暴露在網際網路上，並希望維運負擔最低。

解決方案架構師應該怎麼做？

• A. 建立直接對主要機器的 private IP 發送 HTTP 請求的 health check，再設定 failover 記錄
• B. 建立反映應用程式狀態的 CloudWatch alarm 與監控該 alarm 的 health check，再設定 failover 記錄
• C. 為主要機器配置 Elastic IP，Security Group 只放行 Route 53 health checker 的 IP，再設 failover 記錄
• D. 建立 multivalue answer 記錄同時回應兩台機器的 IP，並把記錄的 TTL 調降到 10 秒加快切換

問題 3

某新創公司把網域 example.com 的 DNS 從其他業者搬到 Route 53。網站架在一個 ALB 後方，使用者有時直接輸入 example.com，有時輸入 www.example.com，每個月的 DNS 查詢量約數億次。在原本的業者那邊，www.example.com 是用 CNAME 指向 ALB 的 DNS 名稱。公司要求兩個網址都要能正常連到網站，並希望 DNS 相關的費用最低（MOST cost-effective）。

哪一個設定方式最符合需求？

• A. 為 example.com 與 www.example.com 都建立指向 ALB 的 alias A 記錄
• B. 為 example.com 與 www.example.com 都建立 CNAME 記錄，值設為 ALB 的 DNS 名稱
• C. 查出 ALB 目前使用的 IP 位址，為兩個名稱都建立指向這些 IP 的 A 記錄，TTL 設為 60 秒
• D. example.com 建立指向 ALB 的 alias 記錄，www.example.com 以 CNAME 指向 example.com

問題 4

某線上課程平台把影片存在 Amazon S3，透過 CloudFront 提供給使用者觀看。授權合約規定影片只能提供給台灣與日本的使用者；資安團隊也要求 S3 bucket 不能被任何人直接存取，只能透過 CloudFront 取得內容。公司希望以維運負擔最低（LEAST operational overhead）的方式滿足這兩項要求。

解決方案架構師應該採取哪兩項做法？（選擇兩項）

• A. 在 CloudFront distribution 啟用 geo restriction，以允許清單只放行台灣（TW）與日本（JP）
• B. 在 Route 53 建立 geolocation 記錄，只對台灣與日本發出的查詢回應 CloudFront 的網域名稱
• C. 設定 Origin Access Control，並把 bucket policy 改成只允許這個 distribution 讀取
• D. 在 bucket policy 加入 aws:SourceIp 條件，只允許台灣與日本各家 ISP 的 IP 網段讀取影片物件
• E. 對 bucket 啟用 S3 Transfer Acceleration，讓影片改經邊緣節點傳送，並開啟 Block Public Access

問題 5

某遊戲公司的多人連線伺服器使用 UDP，部署在 us-west-2 與 eu-west-1 兩個 Region 的 NLB 後方，玩家遍布全球。公司要求：玩家連線要從最近的進入點盡快進入 AWS 骨幹網路；某個 Region 失效時，要在數秒內自動改連另一個 Region，不能受玩家端的 DNS 快取影響；企業客戶也需要固定 IP 加入防火牆白名單。公司希望以維運負擔最低的方式設計。

哪一個方案最符合需求？

• A. 建立 CloudFront distribution，以兩個 Region 的 NLB 分別作為 origin group 的主要與備援來源
• B. 建立 AWS Global Accelerator，把兩個 Region 的 NLB 分別加入各自的 endpoint group
• C. 在 Route 53 建立 latency 記錄並為每筆記錄掛上 health check，再把記錄的 TTL 調降為 10 秒
• D. 為兩個 Region 的 NLB 綁定 Elastic IP，在遊戲客戶端內建這些 IP，連線失敗時由客戶端自行切換

💡 解答

1. D

這是兩層規則：第一層用 geolocation 保證「人在歐洲就去 eu-central-1」，這是法遵要求，不能被延遲蓋過；其他地區都落到 geolocation 的預設位置（Default），而預設位置的記錄再用 alias 指向同一個 hosted zone 裡另一組只含美、日 ALB 的 latency 記錄，由第二層挑延遲最低的。Route 53 允許 alias 指向同一個 hosted zone 的其他記錄，就是為了組出這種巢狀的規則。

A 是這篇強調過的混淆：latency 看的是「哪裡快」，歐洲使用者如果連美國比較快，就會被送去美國，違反法遵。B 的 geoproximity 是依距離劃範圍，bias 只能把範圍拉大或縮小，沒辦法保證「歐洲的使用者一個不漏、歐洲以外一個不收」。C 的方向對了一半，但 weighted 是依比例分配，不是依延遲挑選，其他地區的使用者不一定會連到最快的 Region。

2. B

Route 53 的 health checker 在網際網路上，打不到 VPC 裡的 private IP。這種情況要反過來做：先用 CloudWatch 指標建立一個反映應用程式狀態的 alarm，再建立「監控這個 alarm 狀態」的 health check，把它掛到 failover 記錄的 primary 上。alarm 進入 ALARM 狀態，health check 就判定失敗，Route 53 開始回應備援機器的 IP；兩台機器都不用對外開放。

A 是誤解：health check 不能直接檢查 private IP，這筆 health check 根本打不到機器。C 技術上能讓 health checker 打到機器，但主要機器等於暴露在網際網路上，違反要求。D 的 multivalue answer 沒有掛 health check，兩台的 IP 都會一直被回應，主要機器掛了，客戶端還是有一半的機會拿到它的 IP；調低 TTL 只影響快取時間，不會讓壞掉的那筆消失。

3. A

alias 記錄可以放在根網域（example.com），也可以指向 ALB；而且 alias 指向 AWS 資源的查詢不收費，每月數億次的查詢都不用付查詢費用。兩個名稱都用 alias 指向 ALB，就能正常運作，費用也最低。

B 是誤解：CNAME 不能放在根網域，example.com 那筆根本建不起來。C 也是誤解：ALB 的 IP 會隨擴展和維護改變，寫死 IP 遲早會連到錯的地方。D 技術上可以運作，也是最容易被選的干擾項：example.com 那筆沒有問題，但 www.example.com 用的是 CNAME，而 CNAME 的查詢要收費，查詢量大的時候費用就會比 A 高。

4. A、C

CloudFront 的 geo restriction 依使用者的所在國家決定要不要回應，設定允許清單只放行 TW 與 JP，其他國家的使用者會直接收到 403，這是 CloudFront 內建的功能，不用額外維護。Origin Access Control 則讓 CloudFront 用自己的身分讀取 S3，bucket policy 只允許這個 distribution，任何人直接存取 bucket 都會被拒絕。兩項各自滿足一個要求，合起來才完整。

B 是誤解：DNS 只是回答「名字對應到哪」，其他國家的使用者只要換一台 DNS 伺服器，或直接連 CloudFront 的網域名稱，就能繞過這個限制。D 會讓台灣和日本的使用者可以直接存取 bucket，違反「只能透過 CloudFront」；而且各家 ISP 的 IP 網段一直在變，維護這份清單的負擔很重。E 的 Transfer Acceleration 是加速上傳和下載到 S3 的功能，跟地區授權無關，也沒有限制「只能透過 CloudFront」讀取。

5. B

Global Accelerator 提供兩個固定的 anycast IP，玩家連到最近的邊緣節點後，就走 AWS 骨幹網路到後端；它支援 UDP，會持續檢查每個 endpoint group 的健康狀態，某個 Region 失效時在數秒內把流量改送到另一個 Region。IP 本身不變，所以不受 DNS 快取影響，企業客戶也能把這兩個 IP 加進白名單。

A 是誤解：CloudFront 只處理 HTTP/HTTPS，不能轉送 UDP 的遊戲流量。C 依賴 DNS，即使 TTL 設得很短，很多客戶端和中間的解析器仍會快取更久，做不到保證數秒內切換，也沒有固定 IP 可以給客戶加白名單。D 要把 IP 寫死在客戶端、自己寫切換邏輯，IP 一改就得更新所有玩家的客戶端；企業客戶要加進白名單的 IP 也變成四個，而且玩家不會經過 AWS 骨幹網路加速。