Amazon ANS-C01: DNS 與 Route 53 — 學習指南
屬於 AWS Advanced Networking Specialty ANS-C01 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.
核心概念
DNS 是將人類易讀的名稱與分散式端點連結起來的黏著劑，但在 AWS 中，它成為一個用於延遲路由、健康感知容錯移轉以及多帳戶私有名稱解析的主動控制平面。Amazon Route 53 透過公有託管區域 (public hosted zones) 支援權威性公有 DNS，並透過私有託管區域 (private hosted zones) 為 VPC 範圍內的解析提供私有 DNS。私有託管區域與一個或多個 VPC 相關聯，並且僅對源自這些 VPC 或透過 Route 53 Resolver 入站端點 (inbound endpoints) 的查詢回傳答案。這種 split-horizon (分裂視界) 行為——根據來源對相同名稱回傳不同答案——讓您能為網際網路用戶端暴露一個公有端點，同時在您的 VPC 內部將相同名稱解析為私有 IP。
Route 53 也將路由決策邏輯和主動健康狀態檢查整合到 DNS 中。路由政策包含 Simple (簡易)、Weighted (加權)、Latency (延遲)、Failover (容錯移轉，主要/次要)、Geolocation (地理位置) 和 Multi-Value Answer (多值答案)，以及 Traffic Flow (地理鄰近性和複雜流程)。使用 CreateHealthCheck 建立的健康狀態檢查允許 Route 53 從 DNS 答案中移除不健康的端點，或驅動容錯移轉紀錄集；健康狀態檢查可透過 HealthCheckConfig 欄位進行設定，例如 Type、FullyQualifiedDomainName、IPAddress、Port、ResourcePath、RequestInterval 和 FailureThreshold。由於 DNS 會被解析器和用戶端快取，Route 53 的 TTL 和頻繁的健康狀態檢查輪詢 (在特定設定下最短為 10 秒) 必須與 DNS 的傳播行為取得平衡，以因應容錯移轉和加權路由的變更。
關鍵服務與設定
當暴露 AWS 資源時，應使用 Alias 紀錄 (Alias records) 將 DNS 直接指向支援的 AWS 資源，以避免額外的躍點 (hops) 或 CNAMEs。Alias 紀錄使用一個 AliasTarget，它會參照 AWS 資源的託管區域 ID 和 DNS 名稱 (例如，一個 Elastic Load Balancer、API Gateway 自訂網域、CloudFront 發行版或 S3 網站端點)。建立或變更紀錄是透過 ChangeResourceRecordSets API 完成的；對於程式化的工作流程，請使用帶有 UPSERT/DELETE 操作的 ChangeBatch，並使用 SetIdentifier 來識別路由政策。對於容錯移轉，您需要建立兩筆同名的紀錄，並將 Failover 分別設定為 PRIMARY 和 SECONDARY，每筆紀錄都透過 HealthCheckId 參照一個您用 CreateHealthCheck 建立的健康狀態檢查。
對於跨帳戶和混合式 DNS 解析，Route 53 Resolver 提供了使用 CreateResolverEndpoint 建立的入站 (inbound) 和出站 (outbound) 端點。入站端點允許地端解析器將查詢轉發到 VPC 中 (這對於解析私有託管區域很有用)，而出站端點則讓 VPC 資源能將查詢轉發到地端 DNS 伺服器或其他解析器。解析器規則 (Resolver rules，使用 CreateResolverRule 建立) 讓您可以將特定網域的查詢轉發到指定的 IP 位址，並使用 AssociateResolverRule 將規則與 VPC 關聯起來。對於集中式 DNS 架構，您可以在一個中央帳戶中建立轉發規則，並將其與其他帳戶中的 VPC 透過 AssociateResolverRule 關聯，也可以選擇性地使用 AWS Resource Access Manager (RAM) 和 PutResolverRulePolicy 來控制這些關聯。
Route 53 Resolver DNS Firewall 提供基於網域的篩選和日誌記錄功能。您可以使用 CreateFirewallDomainList 建立網域名單，使用 CreateFirewallRuleGroup 建立規則群組，然後將規則群組透過 AssociateFirewallRuleGroup 與 VPC 關聯以強制執行規則。防火牆規則可以 BLOCK (封鎖)、ALLOW (允許) 或 OVERWRITE (覆寫) 回應，並且您可以將評估結果記錄到 CloudWatch Logs 或 S3。使用 CreateFirewallRule 和 PutFirewallRuleGroupPolicy 進行管理並應用具優先級的規則，特別是用於限制透過 DNS 的資料外洩，或封鎖來自 VPC 附加資源的惡意網域存取。
設計模式與權衡
對於高可用性、全球分佈的服務，請使用延遲路由或地理位置路由將用戶端導向至最近的健康端點，並搭配健康狀態檢查來移除不健康的區域性端點。延遲路由取決於 Route 53 的區域延遲表，適用於多區域 active-active (主動-主動) 設計；容錯移轉路由則更適合 active-passive (主動-被動) 的災難復原，在這種情境下，一次只應有一個區域接收流量。加權路由透過為紀錄指派權重值，並使用 ChangeResourceRecordSets 變更這些值，來支援漸進式的流量轉移 (藍綠部署或金絲雀部署)。多值答案路由可以回傳多個 IP 以進行用戶端負載分配，並且需要健康狀態檢查以確保只回傳健康的 IP。
私有託管區域和解析器端點是多帳戶、多 VPC 名稱解析的典型模式。對於擁有多個業務單位的情境，一個託管私有託管區域或解析器端點的中央共享服務 VPC 可以簡化管理：建立一個私有託管區域並使用 AssociateVPCWithHostedZone 來附加服務 VPC，或者運行 Route 53 Resolver 的出站/入站端點和轉發規則，這樣每個帳戶在依賴中央 DNS 政策的同時，仍能保持其 VPC 的隔離性。其權衡之處在於，與許多 VPC 關聯的私有託管區域會使 IAM 和變更控制變得複雜，且跨帳戶的關聯需要一個授權步驟。解析器轉發會帶來中央操作的額外負擔，但它具有擴展性，因為您不需要將每個 VPC 直接與每個託管區域關聯；取而代之的是，您關聯的是解析器規則。
在強制執行嚴格的存取路徑時——例如要求流量只能透過 Global Accelerator 流通——您必須設計安全群組和網路控制來與 DNS 匹配。Route 53 可以透過建立帶有加速器靜態 IP 位址的 A 紀錄，或使用 CNAMEs 指向一個由加速器管理的網域，來指向 Global Accelerator，但強制執行是在 ALB 安全群組和網路 ACL 層級完成的。ALB 安全群組應只允許來自 Global Accelerator 靜態 IP 位址的傳入流量；Global Accelerator 保證這些靜態 IP 將是傳入流量的來源，因此限制傳入流量可以維持「僅能透過加速器存取」的要求。
常見陷阱與決策標準
一個典型的陷阱是假設 Route 53 健康檢查會立即移除端點；DNS 快取 (TTL) 和用戶端解析器的行為意味著容錯移轉並非即時發生。對於關鍵的容錯移轉名稱，應保持較低的 TTL，但請記住，較低的 TTL 會增加查詢量和成本。另一個常見的錯誤是在不了解 VPC 關聯的情況下，在公有和私有託管區域中重複使用相同的名稱：與公有託管區域同名的私有託管區域，將會對源自關聯 VPC 的查詢遮蔽公有的答案，這對於分割視野 DNS (split-horizon) 來說通常是理想的，但如果沒有記錄下來，可能會讓人感到意外。
請謹慎選擇 Alias 和 CNAME 記錄：對於 ELB 和 CloudFront，建議使用 Alias 記錄，因為它們可以避免額外的 DNS 查詢，並且受到 Route 53 變更傳播邏輯的支援，但它們與 AWS 資源的託管區域 ID 綁定，不能用於任意的外部端點。在設計跨帳戶 DNS 時，若考量到規模或管理邊界，應優先選擇解析器規則和端點，而不是將多個 VPC 直接關聯到單一的私有託管區域；解析器規則提供更精細的控制，也更容易使用 CloudTrail 進行稽核。
實務問題：使用案例情境
公司：NimbusPay — 挑戰：為 EKS 後端提供安全的低延遲 gRPC 服務（透過 TLS 與相互 TLS），強制 Web 前端只能透過 Global Accelerator 存取，並允許多個跨帳戶的業務單位 VPC 使用集中式 DNS 控制來取用共用資料服務。
- 對於需要端對端 TLS、相互驗證及數千個並行連線的 gRPC 服務，請部署一個 Network Load Balancer (NLB)，在其 443 埠上使用 TCP 偵聽器，並將目標類型設為 ip，以便直接註冊 Pod IP。設定 AWS Load Balancer Controller 的註解
undefined
並將目標群組協定設為 TCP；不要在 NLB 終止 TLS（即不使用 TLS 偵聽器），這樣相互 TLS 就能通透傳輸到 Pod 容器中，由容器內的伺服器憑證和用戶端憑證驗證機制來執行。使用指向 NLB 的 Route 53 A 記錄 (Alias)，透過
undefined
進行設定；只有在需要快速容錯移轉時才建議使用低 TTL，否則為了 DNS 的穩定性，應保持一個較保守的 TTL。
為確保 Web 前端的 ALB 只接受來自 Global Accelerator 的流量，請佈建一個加速器，並將其兩個靜態 IP 位址指派給 NimbusPay。設定 Route 53 公有記錄，將公有名稱解析到加速器的 IP（使用帶有靜態 IP 的 A 記錄）。在 ALB 上，設定安全群組的傳入規則，只允許來自這些靜態 IP 位址的流量，並關閉 0.0.0.0/0。這會強制只有來自加速器靜態 IP 的流量才能到達 ALB。使用 CloudWatch Logs 和 VPC Flow Logs 來驗證傳入的來源 IP，並稽核非加速器的流量是否被阻擋。
對於需要存取共用服務的多個跨帳戶業務單位 VPC，請在共用服務帳戶中使用
undefined
部署一對中央的 Route 53 Resolver 輸出/輸入端點，並將這些端點放置在私有子網路中。在共用帳戶中為共用服務網域建立轉送規則 (
undefined
)，並使用 AWS RAM 共用這些規則，或使用
undefined
來允許關聯。每個業務單位將解析器規則與其 VPC 關聯 (
undefined
)，從而實現名稱解析，而無需將所有 VPC 直接附加到私有託管區域。對於敏感控制，可將 Route 53 Resolver DNS Firewall 規則群組 (
undefined
和
undefined
) 附加到共用 VPC，以阻擋不必要的資料外洩或強制執行網域允許清單。理由：NLB 的 TCP 通透傳輸保留了相互 TLS 並能擴展至大量並行連線；將 ALB 傳入流量限制為 Global Accelerator 的靜態 IP，強制了「僅能透過加速器存取」的原則；而使用集中管理的規則搭配解析器端點，則能在維持各帳戶 IAM 邊界和稽核能力的同時，擴展跨帳戶的 DNS 解析功能。
← Transit Gateway 與網路拓撲 · 所有領域 · 負載平衡與流量管理 →
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →