AWS帳號快速認證 AWS Route 53 私有託管區域設定指南

第一章：為什麼要用 Route 53 私有託管區域

很多團隊在內網做域名解析時，最常見的做法是自建 DNS（BIND、Knot、PowerDNS 等）。但自建的成本不只在服務器本身，還包含維運、備援、升級、權限管理、監控告警，以及當網路規模擴張後的調整流程。AWS 的 Route 53 私有託管區域（Private Hosted Zone）提供了一種更貼近雲端管理方式的選擇：你可以把 DNS 記錄放在託管區域中，並讓特定 VPC 內的資源透過 AWS 內部解析到正確的 IP。

它的核心價值在於三點。第一，私有託管區域不會公開到公網 DNS，降低外部曝光風險。第二，解析能力與 AWS 網路整合，查詢不必穿過複雜的跳板。第三，配置變更可以用流程化方式管理，對於多環境（開發、測試、正式）或多賬戶（account）的治理更友善。

但要把它用對，也需要理解「它到底是什麼、如何被查詢、哪些設定會影響解析結果」。下文會以實際設定步驟為主線，讓你能在遇到問題時知道從哪裡查起。

第二章：使用前的需求盤點

你需要解析哪些名稱

先把命名空間想清楚。常見情境是：在一個私有網域（例如 corp.example.com）下，解析不同環境或不同服務的主機名，例如：

• app-dev.corp.example.com 指向開發環境負載均衡器
• app-test.corp.example.com 指向測試環境
• db.corp.example.com 指向資料庫內網地址

你要決定的是：這些名稱是都落在同一個託管區域底下，還是拆分成多個託管區域。通常建議以「團隊邏輯」或「故障域」來拆，避免過度集中導致單一責任過大。

有哪些 VPC 需要解析同一組記錄

私有託管區域要對應到指定的 VPC。也就是說：當查詢發生在某個 VPC 內，Route 53 私有託管區域會根據你綁定的 VPC 來決定是否能返回答案。

因此在設計初期，你要回答：需要哪些 VPC 都能解析？它們是否透過 VPC Peering、Transit Gateway 或 AWS PrivateLink（不過 Route 53 私有解析與 PrivateLink 的關係另說，主要還是看 DNS 查詢路徑）連通。

簡單說：綁定範圍設錯，最常見的現象就是「某些實例能解析，另一些不能」，即使記錄本身完全正確。

解析方是誰：EC2 直接查 DNS 還是應用層指定

Route 53 私有託管區域的解析通常是透過 VPC 內的 DNS resolver 轉發到 Route 53。多數情況下，只要你使用預設的 VPC DNS 設定，EC2 會自動用到。

但若你在實例上改過 /etc/resolv.conf、或用自建 DNS 取代 VPC resolver，就會改變查詢路徑。你需要在設計中明確：解析流量到底從哪裡出發。

第三章：建立私有託管區域的基本流程

步驟 1：準備要綁定的 VPC

在建立私有託管區域之前，先確認你要綁定的 VPC。這裡的 VPC 是要讓其內部資源能對應記錄查詢。

如果你的架構包含多環境多 VPC（例如每個環境一個 VPC），你可以選擇：

• 為每個環境建立各自的私有託管區域，並綁定對應 VPC
• 建立一個託管區域，綁定多個 VPC，讓它們共享同一套命名規則與記錄（前提是記錄設計能避免衝突）

後者看似省事，但在維運上更容易出現「改動影響面太大」的風險。通常更穩妥的做法是：環境隔離明確時就分開。

步驟 2：建立 Hosted Zone（私有託管區域）

進入 Route 53 控制台，建立新的 Hosted zone 時選擇「Private hosted zone」。在網域名稱填入你的私有網域（例如 corp.example.com），然後選擇要綁定的 VPC。

這個流程的關鍵不在填表本身，而在兩件事：網域名稱要跟你的記錄階層一致；VPC 綁定要符合你預期的查詢來源。

步驟 3：理解「自動 NS 記錄」與解析責任

私有託管區域通常會在建立後出現 NS 記錄等元資料。你不需要像自建 DNS 一樣自行維護權威伺服器；Route 53 會扮演權威解析方。

但要記得：對外查詢的路由不是靠你補 NS 給別人，而是靠 AWS 內部解析器把查詢導向正確的託管區域。若 VPC DNS 設定沒有啟用或路由不通，NS 再漂亮也沒用。

第四章：設計 DNS 記錄的策略（A、AAAA、CNAME、Alias）

建立私有託管區域之後，接下來就是記錄設計。很多人把重點放在「新增一筆 A 記錄」上，但真正決定穩定性的，是你怎麼定義變更與可用性。

TTL 怎麼選

TTL（Time To Live）決定解析結果在快取中的保留時間。私有網路通常 TTL 不必太大，因為變更希望能更快生效。一般可用的策略是：

• 相對穩定、少變更的服務：TTL 可能可以稍長（例如 300-900 秒）
• AWS帳號快速認證 會頻繁調整或快速迭代的環境：TTL 建議較短（例如 30-120 秒）

但不要只看 TTL，還要考慮：實例端的 DNS 解析器本身也可能有自己的快取行為。你不能保證每台主機都會嚴格遵守 TTL，因此在部署時最好做灰度，避免同時依賴解析變更。

A 記錄 vs CNAME 記錄

在 AWS 私有 DNS 中，A 記錄最直接：把主機名映射到 IP。

但你可能不希望某個記錄長期綁死到固定 IP。舉例：如果你面向的是負載均衡器（ALB/NLB），其 IP 可能會隨架構變動而改變。這時候你可以用：

• CNAME：指向另一個名稱（適用於你能確定目標名稱存在且解析鏈路清晰）
• Alias：Route 53 的別名概念，能夠直接指向某些 AWS 資源，並處理底層解析

AWS帳號快速認證 多數情境下，負載均衡器或靜態終點建議使用 Alias，因為它更貼合 AWS 服務的動態特性。

什麼時候使用 Alias

當你的目標是 ALB、NLB 或其他 Route 53 能對應的 AWS 端點，你可以用 Alias，讓 Route 53 替你處理最終目標解析。

這樣的好處是：

• 你不必手動管理目標的 IP
• 當目標資源變更時，Alias 的解析通常能保持更新
• 減少因 IP 漂移造成的連通故障

因此，實務上「服務入口」常常會用 Alias，而「內部固定節點」才考慮 A 記錄。

第五章：跨 VPC 的解析與綁定策略

AWS帳號快速認證 同一託管區域能綁哪些範圍

私有託管區域可以綁定多個 VPC（在同一個 AWS 區域內）。當一個查詢來源屬於其中某個 VPC，就可以返回該託管區域中的權威答案。

因此，跨 VPC 的 DNS 共享通常用兩種方式：

• 把所有需要共用的 VPC 綁到同一個私有託管區域（共享命名與記錄）
• 為不同 VPC 建立不同託管區域（隔離變更與風險）

如果你有一個「平台團隊」在管理共享服務（例如公司內的身份驗證、API 閘道、內部工具），共享託管區域會讓管理更集中。反之，如果你有嚴格的環境隔離要求，分開託管區域會讓治理更安全。

VPC 連通不是 DNS 連通

很多人會誤以為：VPC 之間只要網路連通（例如 Peering 或 TGW）就能解析內部域名。實際上 DNS 是否成功，仍取決於查詢是否能被送到正確的 resolver，以及私有託管區域是否包含該來源 VPC 的綁定。

換句話說，網路可達不等於 DNS 可解析。你要分別檢查兩件事：查詢路徑（resolver）與權威答案（hosted zone 綁定）。

第六章：與安全性相關的設定考量

不要把私有 DNS 當成「網路隔離」

私有託管區域提供的是解析面的隔離，不是防火牆。即使名稱只在內部可解析，仍要透過安全群組與 NACL 控制流量。DNS 只是告訴你「去哪裡」。真正的安全還是要回到連線層。

記錄治理與變更權限

在多人團隊環境，建議建立變更規範。因為 DNS 記錄改動可能造成整體服務可用性波動。你可以考慮：

• 限制誰能新增/刪除記錄
• 採用分支或審核流程（變更單）
• 用一致的命名規則避免重疊或混淆

第七章：實際設定範例（可直接套用的思路）

假設你有一個私有網域 corp.example.com，並在同一個區域內存在一個 VPC：vpc-prod-001。你要讓內部主機能解析：

• api.corp.example.com 指向一個 ALB
• db.corp.example.com 指向一台固定 EC2（或內網固定地址）
• cache.corp.example.com 指向另一個服務

你可以這樣做。

建立託管區域

Route 53 新建 Private hosted zone：

• 名稱：corp.example.com
• VPC 綁定：選擇 vpc-prod-001

完成後，託管區域就成為權威來源。

新增 API 記錄（使用 Alias 指向 ALB）

在 hosted zone 裡新增：

• Record name：api（或依你的顯示方式填 api.corp.example.com）
• Type：A 或 Alias 對應（依控制台選項）
• Alias target：選擇對應的 ALB

Alias 的概念讓你不用管理 ALB 底層 IP。

新增 DB 記錄（使用 A 指向內網 IP）

假設 DB EC2 內網 IP 是 10.0.2.50：

• Record name：db
• Type：A
• AWS帳號快速認證 Value：10.0.2.50
• TTL：例如 60 秒

如果 DB 不是固定 IP（例如是動態指派），你就需要另一套穩定手段，例如固定私有 IP、或用目標名稱再串聯到其他可確保一致性的解析來源。

新增 Cache 記錄（視情況選 CNAME 或 Alias）

若 cache 對應的是另一個負載端點，通常使用 Alias；若 cache 是內部服務域名的別名，可以用 CNAME 指向另一個受管理的名稱。

重點是：讓解析鏈路能被你控制且可追蹤，不要讓記錄變成無限制的轉發散彈。

第八章：測試與驗證：如何確保 DNS 真正可用

當你完成配置後，驗證要有順序。不要一口氣只做一次查詢結果判斷，那樣遇到問題很難定位。

測試步驟 1：在目標 VPC 的 EC2 上查詢

登入一台位於目標 VPC 的 EC2，執行 DNS 查詢，例如：

• 查 api.corp.example.com
• 查 db.corp.example.com

你希望看到的是：返回的值是你配置的 ALB 與 DB 目標。

AWS帳號快速認證 測試步驟 2：反向驗證與解析一致性

如果你有自動化或監控依賴解析結果，建議在多台主機做同樣查詢。原因是：有時候「某一台主機解析正常」是因為它使用了不同的 resolver 或特殊網路設定。

你應該至少驗證：

• 不同子網是否一致
• 不同安全組或不同主機映像是否一致

測試步驟 3：用實際連線確認服務可達

AWS帳號快速認證 DNS 解析成功不代表服務可用。你要進一步確認：

• 連到解析出的 IP/端口是否被安全組允許
• 目標服務是否正常運行
• 若是 ALB，Listener 與 Target Group 是否正確

DNS 只是第一步，後面才是真正的端到端。

第九章：常見故障與排查路徑

DNS 問題通常表面看似簡單，但背後原因常常是「綁定範圍、查詢路徑、記錄錯誤、或 resolver 設定」其中之一。以下整理一些最常見狀況。

AWS帳號快速認證 問題 1：有些 VPC 能解析，有些 VPC 不能

這通常意味著 hosted zone 沒有綁定到該 VPC。也可能是實例不使用 VPC DNS resolver，或它的 resolver 走向不同的 DNS 伺服器。

排查順序：

1. 確認 hosted zone 的 VPC 綁定清單是否包含來源 VPC
2. 檢查 EC2 的 DNS 設定（例如是否有自訂 resolv.conf）
3. 確認是否有中間 DNS 代理（公司網管或自建 DNS）接管查詢

問題 2：解析返回 NXDOMAIN 或 No answer

這多半是記錄名稱或網域層級拼錯。DNS 是嚴格匹配的，你必須確認：

• 你查詢的完整域名是否對應到 Hosted zone 的名稱層級
• AWS帳號快速認證 Record name 填的是子名還是全名（依控制台介面可能不同）
• Type（A/AAAA/CNAME/Alias）是否符合你預期

此外，TTL 快取也可能讓你看到舊結果。建議在測試時清理或使用短 TTL，避免誤判。

問題 3：解析到錯誤的 IP（或指到舊的目標）

這通常是因為：

• 你以為改了記錄，但實際改到另一個 hosted zone（多環境常見）
• 有快取存在，導致短時間仍回舊值
• 目標服務（例如 ALB）指向的 Alias 對應資源錯誤

排查順序：

1. 確認查詢的網域屬於正確 hosted zone
2. 對照控制台記錄，逐項核對 name/type/value
3. 使用新的測試主機確認是否還回到舊值

問題 4：DNS 查詢逾時，應用層卡住

逾時一般不是記錄錯誤，而是網路或解析服務不可達。你可以從這幾點查起：

• VPC DNS 設定是否啟用（DNS resolution、DNS hostname）
• EC2 是否在私有子網且缺少 NAT/路由（不過內部 DNS 通常不需要上網，但仍要確認路由與 resolver 設定）
• 安全群組是否阻擋 DNS 相關流量（通常 DNS 到 resolver 需要特定路徑，實務上多半在 VPC 內完成，但你仍要檢查）

如果你使用自建 DNS 作為轉發器，還要確認轉發器與 Route 53 間的規則。

第十章：運維與最佳實踐：讓 DNS 系統可長可久

建立命名規範與記錄分類

建議你把記錄分成類別來管理，例如：

• 入口類：api、web、gateway
• 數據類：db、cache
• 基礎服務：auth、registry

命名越一致，排查越快。尤其在多團隊協作時，避免「每個人都用自己的命名習慣」，最後同一個服務出現多個名稱映射或相互矛盾的記錄。

把變更納入流程，不要靠臨時操作

DNS 變更是影響範圍很廣的操作。你可以用以下方式降低風險：

• 在測試環境先驗證解析與連線
• 設定較短 TTL，讓切換更快
• 採用逐步切換（例如先切一小部分服務或一部分主機）
• AWS帳號快速認證 保留回滾方案（例如保留舊記錄或快速切回）

最怕的是：沒有回滾、沒有觀察指標、變更直接在正式環境一次到位。

監控：至少要知道解析是否有問題

DNS 本身常常沒有直接的「應用監控」，所以你需要把解析健康納入觀察。可以考慮：

• AWS帳號快速認證 在關鍵主機定期解析並記錄結果
• 監控應用端的連線錯誤是否因為名稱無法解析
• 若你有集中日誌，也可以追蹤 NXDOMAIN 或逾時事件

當問題來時，能快速確認是 DNS 層還是服務層，會省下大量時間。

結語：把私有託管區域當作「可管理的基礎設施」

Route 53 私有託管區域的設定並不複雜，但要做到穩定可用，關鍵在於把它當成一個基礎設施來治理：先釐清需求、再設計記錄與 TTL、確保 VPC 綁定正確、最後用可靠的測試路徑驗證。你只要在一開始就把「查詢來源—resolver—權威答案」這條鏈路理清，後續的擴張與排障會順很多。

當你下一次遇到「某些主機解析不了」或「剛改了記錄卻沒立即生效」這類問題，回到文中提到的排查順序：綁定範圍、記錄階層、解析路徑、快取與網路連通。把原因縮小到一到兩個選項，就能更快落地修正。