華為雲實名驗證帳號 AWS帳戶域名管理流程

前言：域名管理不是玄學，是流程

在雲端世界裡，域名就像你家門牌號。你可以不常看它，但你一定會在某天突然需要它：網站要上線、流量要導到新環境、憑證要更新、還有最可怕的——突然有人說「怎麼今天不通了？」然後你就開始回想：上次調 DNS 是什麼時候？誰改的？改了哪一條？為什麼沒有留下註記？

這篇文章要講的是一套「AWS 帳戶域名管理流程」。注意，是流程，不是口號。我會用比較落地的角度，把你從拿到域名那一刻，到用 Route 53 管理，直到 SSL、子網域、跨帳戶、以及日常維運都串起來。你看完應該可以直接把它做成團隊內 SOP，或至少拿去當 checklist，不用再憑運氣。

範圍與前置概念：你在管的到底是什麼

華為雲實名驗證帳號 「域名管理」在 AWS 主要圍繞幾個部分：

• DNS 解析：通常用 Route 53，管理 A/AAAA/CNAME/TXT 等記錄。
• 網路入口：例如 ALB/NLB/CloudFront 對外的導向方式。
• 憑證與驗證：ACM（AWS Certificate Manager）配合 DNS 驗證。
• 權限與帳戶：同一個域名是否要在多個 AWS 帳戶管理，跨帳戶如何授權。
• 環境規劃：dev/stage/prod 可能會用不同子網域或不同 Hosted Zone。
• 變更紀錄與監控：誰改了什麼、何時改、為什麼改。

你可以把流程拆成「盤點 → 設計 → 建置 → 變更治理 → 維運監控 → 故障排查」。下面開始正式上菜。

流程總覽：從拿到域名到日常維護

我建議的流程節點如下：

• 1. 盤點與命名規範：確認域名擁有權、使用情境、環境命名策略。
• 2. 建立 Route 53 Hosted Zone：決定是公開區還是私有區，以及是否拆分帳戶。
• 3. 設定 NS/委派：把域名指向 Route 53。
• 4. 設定 DNS 記錄：A/AAAA/CNAME/ALIAS、導向 ALB/CloudFront 等。
• 5. 設定 ACM 憑證：最好用 DNS 驗證，自動化續期。
• 6. 建立權限與跨帳戶策略：用 IAM、Resource Access Manager（如需要）、或集中式 DNS。
• 7. 變更治理：標記、版本/紀錄、審批與回滾。
• 8. 日常監控與警報：解析異常、到期憑證、健康檢查等。
• 9. 故障排查流程：從解析、快取、憑證到路由逐層檢查。

接下來逐段展開。

第一步：盤點與建立命名規範（先把未來的坑填起來）

1.1 確認域名來源與所有權

你要先搞清楚域名目前在哪裡管理：Registrar（域名註冊商）還是已有在 Route 53？

• 如果域名還在註冊商那邊（GoDaddy、Namecheap 等），你需要將其「指向」 Route 53：通常是更新 NS 記錄。
• 如果已委派到 Route 53，就確認對應的 Hosted Zone 是哪一個、在哪個 AWS 帳戶。

這裡常見失誤：很多團隊只記得「Route 53 有設」，但不知道是哪個帳戶、哪個 Hosted Zone。結果一遇上問題，就開始找人問密碼、問權限、問 Hosted Zone 名稱。

1.2 定義環境策略：子網域怎麼分

同一個主機服務常見拆法有兩種：

• 同域名不同子網域：例如 api.example.com、app.example.com、以及 dev-api.example.com。
• 分環境不同域名：例如 example-dev.com、example-prod.com（比較少見，但有些組織偏好）。

我建議用子網域分環境，因為：

• 好做統一管理與委派。
• ACM 憑證通常可更好規劃。
• 日後替換前端/後端時，不需要搬整個網域。

命名上也要一致。你不希望某天有人突然用 staging，有人用 stage，還有人用 preprod。最後你只好寫「猜測規則」來對照。

1.3 決定 Hosted Zone 的拆分方式

常見選擇：

• 一個 Hosted Zone 管理整個公開網域（example.com）。
• 為子網域建立獨立 Hosted Zone（例如 example.com 管主域，example.com 底下的 api.example.com 交給另一個 Hosted Zone）。

拆分會影響：

• 跨團隊責任切分。
• 跨帳戶管理難度。
• NS 委派與 DNS 查找路徑。

若你團隊成熟、權限明確，可以考慮拆分；若你剛開始，先集中管理通常比較穩。

第二步：建立 Route 53 Hosted Zone（以及公私網域的差異）

2.1 公開 Hosted Zone 與私有 Hosted Zone

Route 53 常用兩種：

• Public Hosted Zone：互聯網可查詢的 DNS。
• Private Hosted Zone：只在特定 VPC 內可用（透過解析限制）。

若你的服務要對外（網站、API），主要用 Public Hosted Zone。

若你要做內部服務（例如公司內部 App 只給內網），可以用 Private Hosted Zone。注意：有時候你用錯 Zone 類型，就會出現「內網能通、外網不通」這種看似玄學的現象。

2.2 在同一帳戶還是不同帳戶建立 Hosted Zone？

這是設計題。常見兩種模式：

• 集中式 DNS（推薦初期）：由「網路/平台」帳戶集中管理所有 Hosted Zone，其他應用帳戶只透過權限或流程提交變更。
• 分散式 DNS（適合成熟團隊）：每個服務帳戶自己管理自己的子網域 Hosted Zone。

集中式 DNS 的好處是：你不會遇到同一條域名記錄在多個帳戶被不同人改得像在跳街舞。

分散式則需要更強的治理：誰擁有哪個子網域？變更怎麼審批？如何避免衝突？

第三步：委派（NS）與權威來源（Authority）

3.1 你必須把域名的「權威」指到 Route 53

當你的 Hosted Zone 建好後，你通常需要在註冊商端設定 NS 記錄（或在上層 DNS 做委派）。

流程概念如下：

• 在 Route 53 的 Hosted Zone 取得 NS 名稱與對應值。
• 回到註冊商或上層 DNS 進行 NS 更新。
• 等待 TTL 與傳播，通常短則幾十分鐘，長則可能到幾小時（甚至更久，取決於上游快取）。

最常見的問題是：更新了 NS 但沒有等傳播就開始改 DNS 或綁 ACM，結果你會以為配置錯，實際只是權威來源還沒切過去。

3.2 常見檢查方式

你可以透過 dig/nslookup 檢查目前解析是否落在你的 Route 53 權威上。重點不是「解析結果看起來對了嗎」，而是「查詢的權威來源是不是你預期的 Hosted Zone」。

如果你沒有檢查權威來源，只看最終 IP，很容易在錯誤緩存下被騙。

第四步：設定 DNS 記錄（把路由做成可預期的行為）

4.1 DNS 記錄類型快速對照

常見幾種：

• A / AAAA：指到 IPv4/IPv6。
• CNAME：指到另一個網域名稱。
• ALIAS（Route 53 特有）：可指到 AWS 資源（例如 ALB、CloudFront 等），且不需要固定 IP。
• 華為雲實名驗證帳號 TXT：常用於驗證（例如 ACM DNS 驗證、某些第三方驗證）。

在 Route 53 的世界裡，ALIAS 很香，因為你不用硬記 AWS 資源的 IP 會變。ALB/NLB 的 IP 可能變動，但 ALIAS 會幫你維持正確指向。

4.2 典型場景一：網站前端用 CloudFront

如果你的前端走 CloudFront，一般做法是：

• 在 Route 53 為 www.example.com 建立 ALIAS 指到 CloudFront distribution。
• 如果 apex（example.com）也要走 CloudFront，可以為 apex 使用對應 ALIAS（注意 AWS 支援方式）。

此時你還要確保 CloudFront 的 alternate domain names（別名）設定包含你的域名，否則就算 DNS 對了，仍可能看到「TLS/憑證錯誤」或 404。

4.3 典型場景二：API 用 ALB

如果 API 用 ALB，常見做法：

• 為 api.example.com 建立 ALIAS 指向 ALB。
• ALB listener 需配置對應證書（可由 ACM 管理）。

如果你有多環境（dev/stage/prod），你會把不同子網域（例如 api-dev.example.com）指向不同 ALB。

4.4 MX、SPF、DKIM、DMARC：你以為不重要，其實很重要

很多團隊把域名當成「網站」在管，卻忽略郵件相關紀錄。若你也要處理郵件投遞，至少要安排：

• MX：郵件伺服器位置
• SPF：允許哪些來源發信
• DKIM：簽名驗證
• DMARC：策略（隔離、拒收、回報）

不把這些紀錄管理清楚，後果是郵件進垃圾桶，客服開始收集「為什麼寄出去沒收到」的故事，而你在內心默默對 DNS 道歉。

第五步：ACM 憑證與 DNS 驗證（讓 TLS 自動續命）

5.1 為什麼推薦用 DNS 驗證

ACM 有兩種常見驗證方式：

• DNS 驗證：在 Route 53 建立 TXT 記錄（或由 ACM 指導）。
• Email 驗證：透過信件回覆。

實務上，如果你已經有 Route 53，DNS 驗證通常更適合自動化與跨環境。因為：

• 可用 IaC 或流程化腳本。
• 證書續期更順。
• 團隊更容易追蹤變更。

5.2 憑證範圍：單網域、萬用字元、與多域名

你需要先決定證書策略：

• 單一網域：例如只涵蓋 api.example.com
• 萬用字元：例如 *.example.com（對子網域覆蓋方便）
• 多域名（SAN）：一次涵蓋多個主機名（取決於需求）。

常見做法是：如果你的子網域很多且會持續新增，萬用字元通常比較省事。但若你對某些子網域有不同策略（例如不同服務團隊不同憑證生命週期），就要更精細規劃。

5.3 CloudFront 的證書注意事項

CloudFront 通常要求：

• 憑證需與該 distribution 綁定
• 使用的證書必須包含該域名
• 域名別名（CNAME aliases）與憑證域名要一致

如果你有遇過「DNS 沒問題，但瀏覽器顯示憑證不符合」，通常就是上面幾點其中之一。

第六步：權限與跨帳戶策略（不然你改一次域名要請全世界開會）

6.1 角色劃分：誰能改 DNS？誰能審批？

在團隊內，建議建立至少三種角色：

• DNS 管理員：具備 Route 53 Hosted Zone 變更權限。
• 應用所有者：提出變更需求，但不直接改 DNS（或僅限特定子網域）。
• 審批/治理：確保變更符合規範（可以是平台團隊、資安或運維）。

你不一定要一刀切，但至少要避免所有人都用同一把「超級管理員鑰匙」。那樣的管理方式很有風險，因為你無法追溯責任。

6.2 集中式 DNS 的跨帳戶做法（常用且實務）

如果集中式 DNS：應用帳戶不直接管理 Hosted Zone，你可以做：

• 流程：工單/PR 提交 → 審批 → 由 DNS 管理員套用設定。
• 權限：限制應用帳戶只能提需求，不能變更。

這種方式雖然看起來「慢」，但實際上可以大幅降低出錯率。因為域名是共享資源，一次錯誤可能影響多服務。

6.3 分散式 DNS：跨帳戶共享 Hosted Zone 的難點

若你採分散式，你要注意：

• Hosted Zone 的歸屬要清楚（是在哪個帳戶創建）。
• 跨帳戶的權限授權要可審計。
• 避免多個帳戶同時管理同一份 zone 或同一條記錄。

很多事故不是因為人壞，而是因為「誰管哪個區」不清楚。流程的目的，就是把這種不確定性清掉。

第七步：變更治理（把「我改完了」變成「我改對了且可追溯」）

7.1 版本化：用 IaC 管理 DNS（強烈建議）

DNS 如果只是手動在控制台改，短期很快，長期就會變成「每個人都記得當初怎麼改，但每個人說得不一樣」的故事。

建議使用：

• Terraform / CloudFormation / CDK 來管理 Route 53 記錄與 ACM 驗證紀錄。
• 讓 PR 作為變更入口。
• 用差異檢視（diff）查看將要變更哪些記錄。

當你可以用 diff 看見「只新增一條 TXT 驗證紀錄」，你就不會在凌晨發現自己把全站導到錯誤 ALB。

7.2 TTL 策略：變更時降低風險

在 DNS 變更期間，TTL（Time To Live）會影響傳播速度。你可以採取策略：

• 在高風險變更前（例如切流量、更新權威），降低 TTL。
• 變更完成後再恢復合理 TTL（避免長期過低造成查詢負擔）。

Route 53 的 TTL 是整體管理的一部分，你要讓它成為流程，而不是臨時想到才調。

7.3 回滾方案：如果切錯了怎麼辦

你要提前準備回滾：

• 保持舊記錄可快速恢復（IaC 版本回退、或保留上一版配置）。
• 確保變更窗口有人值班，能在合理時間內處理。
• 建立觀測指標（解析成功率、HTTP 5xx 比例等）。

域名切換失敗最常見的感覺不是「完全不通」，而是某些地區或某些時間仍解析到舊 IP，讓你追到懷疑人生。所以回滾要把「傳播延遲」也算進去。

第八步：日常監控與警報（把問題抓在它變大之前）

8.1 警報清單：憑證、解析、以及健康檢查

我建議至少監控：

• ACM 憑證到期：可用 AWS 事件（EventBridge）或 CloudWatch 相關機制。
• DNS 解析變更：可以搭配變更紀錄（例如 AWS CloudTrail）檢查 Route 53 的 API 呼叫。
• 端點健康：例如 Route 53 Health Check（若使用）或 ALB/CloudFront 的健康狀態。
• 網站可用性：HTTP 監控（外部探測或內部服務）。

有些問題你不監控就不會發現。比如證書快到期，但由於恰好沒有流量暴增，你可能以為一切正常，結果到期那天突然「全部變不安全」。

8.2 變更可追溯：CloudTrail 不能少

把 Route 53、ACM 相關的操作寫入 CloudTrail，並設定告警：

• 誰在什麼時間改了 Hosted Zone？
• 建立/刪除記錄？修改狀態？
• ACM 憑證是否重新簽發、是否進入錯誤狀態？

華為雲實名驗證帳號 你不必把所有細節都拿來看，但你需要在需要時能查到。這是流程治理，不是鑑古學。

第九步：故障排查流程（照表操作，你就不會慌）

當出事時，建議你採用「由外到內」的排查順序。下面給你一個可當SOP的檢查樹。

9.1 先確認：是 DNS 問題還是憑證/應用問題

1. 用 dig/nslookup 查當前解析結果：A/AAAA/ CNAME/ALIAS 指向是否符合預期。
2. 華為雲實名驗證帳號 確認權威來源與 Hosted Zone：解析是否由你期待的 authority 提供。
3. 如果解析正確，檢查瀏覽器/用戶端的錯誤訊息：例如憑證不匹配、連線逾時、HTTP 5xx。

很多人一上來就進控制台改，結果其實是憑證或 ALB listener 問題。你要先分流問題類型。

9.2 DNS 常見問題

• NS 委派未完成：權威還沒切過去。
• 記錄拼錯：例如 CNAME 設錯了、或 TTL/重複記錄導致預期之外行為。
• 快取造成的延遲：你以為改了，實際還在舊值。

處理上通常就是等 TTL、或針對特定記錄降低 TTL，並重新確認解析。

9.3 ACM/SSL 常見問題

• 憑證未完成驗證：DNS 驗證 TXT 記錄可能沒建立或沒傳播。
• CloudFront alternate domain names 沒包含目標域名。
• ALB 使用的證書未更新到新版本。

你可以先看 ACM 的狀態（issued/pending/failed），再對照 Route 53 是否有對應驗證記錄。

9.4 服務端常見問題（DNS 沒錯但就是不通）

即使 DNS 指向正確，仍可能有問題：

• ALB listener 規則沒匹配（host-based routing 等）。
• Security Group 或 NACL 阻擋。
• 目標群組健康檢查失敗（Target 健康狀態不為 healthy）。
• CloudFront origin 或行為路由設定錯誤。

這時候就要回到該服務的觀測指標，而不是一直在 DNS 上面旋轉木馬。

華為雲實名驗證帳號 實務建議：把流程變成「團隊可執行的模板」

如果你要把這套流程落地，我建議你做三件事：

• 建立清單：每次新增域名/子網域，必做盤點、Hosted Zone、DNS 記錄、ACM 憑證、權限確認、監控驗證。
• 建立範本：例如 dev/stage/prod 的子網域命名範本、記錄範本（ALIAS 到 CloudFront/ALB、TXT 驗證範本等）。
• 建立審核規則：例如任何變更都要有 PR、要附上影響範圍與回滾計畫、要在部署窗口內進行。

你不需要把每一步都做得像火箭發射，但至少要保證「所有人都知道下一步是什麼」。這才是流程的價值。

華為雲實名驗證帳號 常見踩雷點（看完你會少掉一些白頭髮）

• 同一域名多處管理：有人在註冊商、有人在 Route 53、有人在別的 DNS 服務混用，最後誰也不知道權威在哪。
• 忘記 CloudFront 的別名：DNS 對但 TLS 不對，瀏覽器直接罵你。
• ACM DNS 驗證 TXT 沒傳播完成就以為成功：狀態仍 pending/失敗，但你已把服務切上線。
• 沒有變更紀錄與審計：出事時找不到「誰改的、改了哪條」。
• 把 TTL 調太低長期不管：查詢頻率上升，成本與延遲都可能變麻煩。

踩雷不可怕，可怕的是踩了還不知道自己踩在哪個點。

結語：讓域名管理變成一件「你能交代清楚」的事情

AWS 帳戶域名管理流程的核心，不只是「設定 Route 53」而已，而是把 DNS、憑證、權限、變更治理、監控排在同一套邏輯裡。當你能清楚回答：這條記錄是誰創建的、目的是什麼、如何驗證、如果失敗怎麼回滾，你的域名管理就從「靠感覺」升級成「可運維、可追溯、可擴展」。

最後送你一句（有點像吐槽但是真理）：域名不是用來相信的，是用來被驗證的。每次你改完 DNS，至少做到「解析查證 + 憑證狀態 + 觀測指標」。你會發現，世界突然就沒那麼愛跟你作對了。