AWS企業帳號服務 AWS DNS故障轉移如何保障網站不中斷

第一章：為什麼會“不中斷”這麼難

很多人把網站不中斷想得太簡單：DNS 指到哪裡，流量就去哪裡。但現實裡，“不中斷”常常被幾個因素一起拉扯：使用者的 DNS 快取、瀏覽器與系統的緩存行為、解析器的再查詢節奏、服務端的健康狀態判斷、以及切換後連線能否立即恢復穩定。只要其中一環設計不周，切換就可能變成延遲飆升、部分請求失敗，甚至整體不可用。

AWS DNS 的故障轉移（以 Route 53 為核心）其實是在控制“影響面”。它不保證任何情況下零損失，但能讓失效從“你不知道什麼時候發生、也不知道會不會恢復”變成“有條件可監測、能在預期時間內切換到可用資源”。重點在於：你要提前回答三個問題：第一，什麼叫“故障”？第二，故障到切換需要多快？第三，切換後怎麼確保新目的地真正可用。

第二章：DNS 故障轉移在 AWS 的工作方式

DNS 故障轉移通常由 Route 53 的故障轉移路由策略完成。你會為同一個記錄（例如 www.example.com）建立主站（Primary）與備援站（Secondary），並為它們配置健康檢查。

當健康檢查判定主站不可用時，Route 53 會把該記錄對應的解析結果改為指向備援端。使用者下一次查詢 DNS 時，就會獲得備援端的地址。這裡要特別理解：DNS 本身沒有“即時推送”，它是“下一次解析才生效”。因此你能控制的是 TTL 與快取行為，而不是把切換變成瞬間。

同時，Route 53 的健康檢查可以針對端點做定期探測。若你的站點是由多層架構組成（例如 ALB 之後還有應用與資料庫），你要思考健康檢查探測的是“網路可連通”還是“服務真的可用”。如果探測只驗證 TCP 握手，可能出現：連得上但應用錯誤率極高，解析已切換但使用者仍然失望。

第三章：從網站架構角度設計故障轉移

要讓故障轉移真正保障網站不中斷，你不能只停在“DNS 能切”上。架構本身也要承接切換後的流量。常見做法是把應用部署在至少兩個可用區（AZ）或兩個區域（Region）。

選擇跨 AZ 還是跨 Region

跨 AZ：優點是成本與延遲較低；缺點是如果遇到整個區域級別的故障（例如整個 Region 的服務不可用），跨 AZ 的策略可能無法逃離影響。

AWS企業帳號服務 跨 Region：更能應對區域級事件，但設計更複雜：資料同步、延遲、成本、以及切換後的一致性都要考慮。對多數“需要高可用”的網站，至少要有跨 AZ；對嚴格的 SLA 或需要抵禦更大故障範圍的系統，會傾向跨 Region。

用何種入口承接流量

DNS 解析最後通常會指向某個“入口”。在 AWS 生態裡，常見入口包括 ALB、NLB、或 CloudFront 的分配。若你採用 ALB 作為入口，健康檢查可以針對 ALB 的目標狀態或應用提供的健康端點來判斷。

關鍵是：你要定義健康檢查的“真實性”。例如提供一個 /healthz 端點，在應用端檢查必要依賴（例如資料庫連線、關鍵緩存、核心服務）是否能正常回應。這比只靠“端口開著”更能避免錯切。

第四章：TTL 與快取——切換速度與穩定性的取捨

很多故障轉移失敗不是因為“切不過去”，而是因為“切得太慢或不一致”。根因就在 TTL。

TTL（Time To Live）是 DNS 記錄的存活時間。當解析器取得答案後會緩存，直到 TTL 到期才再查詢。如果你的 TTL 設得很大，故障發生後，部分使用者會繼續連到壞的目的地，導致可用性在短時間內大幅下降。

但 TTL 也不能設得太小。TTL 過小會增加查詢量，讓 DNS 系統承壓，並可能帶來更高的解析延遲與成本。更現實的是：對使用者而言，DNS 不是單一事件，快取策略可能由操作系統與瀏覽器決定，你即使把 TTL 設得很小，也不一定能讓所有用戶都立即跟上。

因此實務上要做的是：根據你希望的切換時間窗來設定 TTL，並配合監控與演練驗證。你可以把 TTL 當作“風險調節旋鈕”：在可接受範圍內降低切換延遲，同時確保 DNS 解析不會成為新的瓶頸。

第五章：Route 53 故障轉移路由策略的核心設定

在 Route 53 中，你通常會建立一個故障轉移路由記錄，並配置兩個值：主（Primary）與備（Secondary）。健康檢查決定哪個應答會被使用。

常見做法是：

• 為主站與備援站各自建立相對應的目標（可以是 ALB 的別名記錄、或其他端點）。
• 為每個目標配置健康檢查。健康檢查會周期性探測端點。
• AWS企業帳號服務 選擇與業務相符的健康判定方式：連通性、HTTP 狀態碼、以及回應內容等。
• 設定狀態切換的頻率與閾值（依 Route 53 的配置項而定）。

值得強調的是：健康檢查不是越“敏感”越好。若你的應用偶爾有短暫抖動，過於敏感會導致頻繁切換（flapping），讓使用者體驗反而變差。你需要在“切換速度”和“誤判容忍”之間找到平衡。

第六章：健康檢查怎麼做才可靠

如果健康檢查只看表面指標，那故障轉移就可能變成“切到看似正常但實際不可用”。因此要設計健康檢查的分層思路。

至少要包含三類檢查信號

• 網路可達：目標端點是否回應 HTTP / TCP。
• 應用可用：核心 API 是否能在合理時間內返回預期狀態碼。
• 依賴可用：例如資料庫連線、關鍵外部服務是否能正常回覆或在超時前可用。

實際上，不建議在健康檢查裡做太重的運算。健康檢查應該快、穩定、可預期。你可以把“真正需要的可用性”聚焦到最關鍵的依賴上：例如用資料庫的輕量查詢判斷連線與基本讀能力。

健康端點的語義要清楚

把 /healthz 與 /readyz（就緒）區分開是常見做法：/healthz 偏向“程序是否還活著”，/readyz 偏向“能否接收流量”。故障轉移更需要的是就緒語義，避免把“還在初始化”的節點判成可用。

此外，健康端點的回應內容可以包含版本、延遲等信息，便於排查。即使你不把這些內容直接用來判斷，也能在告警和日誌中快速定位問題。

第七章：從切換到恢復——回切策略要小心

故障轉移不只是一個方向的事件，還有回切（failback）。如果主站恢復後你立刻切回，可能遇到主站“剛恢復就不穩定”的情況。結果就是在短時間內來回切換。

因此回切需要節奏。你可以採用以下原則：

• 確定主站恢復後，健康檢查連續達到“穩定可用”的狀態，再進行回切。
• 在主站恢復期間，觀察錯誤率、延遲、以及依賴系統的穩定性，避免僅看健康端點。
• 如果主站資料需要追上（例如跨區同步），要確認一致性要求滿足，再回切。

在一些高要求場景，回切甚至可能採取“人工介入”或“延遲回切”。自動回切可以，但你必須確保恢復的定義與切換的閾值足夠嚴謹。

第八章：監控、告警與演練——讓切換可預期

DNS 故障轉移最怕兩件事：第一是你不知道它正在發生；第二是你演練過但沒驗證效果。要真正保障不中斷，你需要把切換流程納入日常運維。

AWS企業帳號服務 監控的重點應該覆蓋三層

• DNS 層：Route 53 的健康檢查狀態、解析行為是否已轉移。
• 入口層：ALB/NLB 的目標狀態、轉發延遲與錯誤率。
• 應用層：關鍵交易成功率、回應時間分位數、以及下游依賴是否恢復。

告警策略要避免“只告訴你 DNS 切了”。切了不代表可用，只代表流量換了目的地。你需要同時關注業務指標，例如登入成功率、購物下單成功率或核心 API 的 5xx 比率。

演練不是“把線拔掉看看”

真正的演練應該可控、可觀測、有結果。可以從以下幾個方向做：

• 模擬健康檢查失敗：例如讓健康端點返回 500 或延遲超時，觀察切換時間是否符合預期。
• 模擬入口層故障：例如讓 ALB 的目標不健康或關閉特定規則，驗證解析後是否能立即恢復。
• AWS企業帳號服務 模擬回切：在主站恢復後監測是否出現切換震盪，並調整閾值。

演練結束後要留痕：切換需要多久？TTl 設定是否符合結果？使用者端體驗是否一致？這些都是你後續調參的依據。

第九章：常見坑位與排查思路

AWS企業帳號服務 故障轉移設計得再好，也可能被實際情況“教做人”。以下是一些常見坑位，以及你可以如何思考排查。

坑位一：TTL 設得過高，切換效果不一致

你可能在監控中看到 Route 53 已切換，但使用者仍抱怨連不到站。多半是快取導致解析尚未更新。解法是：降低故障轉移相關記錄的 TTL，並用演練驗證切換時間。

坑位二：健康檢查判斷太寬，導致“錯誤切換”

健康端點只檢查網路可達，卻沒有檢查應用依賴，結果備援也許能回應健康檢查，但實際服務仍是錯誤狀態。解法是：健康端點要更貼近“能不能提供服務”。

坑位三：備援端不是完整可用，而是“能接但跑不動”

切到備援後才發現容量不足、資料不同步或限流策略過嚴，導致延遲爆炸。解法是：備援端必須是可承接流量的真實部署，而不是只做了最小能跑的影子系統。

坑位四：回切後抖動，產生 flapping

主站剛恢復就被健康檢查判為可用，切回後又不穩定。解法是：延長可用判定所需的連續成功次數，或採用回切延遲策略。

第十章：實戰建議：把策略落地成可維護的流程

如果你希望團隊真的能用這套機制保障不中斷，而不是在事件發生時手忙腳亂，我建議把故障轉移當成“工程流程”，包含設計、測試、監控與迭代。

第一步：明確定義故障與可用性

什麼叫“主站故障”？是 5xx 達到某比例？健康端點返回非 200？還是依賴超時？先把定義寫成清楚的判斷標準，後續健康檢查與告警才不會互相矛盾。

第二步：確保資料與會話策略一致

如果你的站點依賴會話（session）或資料一致性，跨區切換時要處理好：例如使用集中式會話存儲、或確保備援端能讀到一致的資料版本。否則 DNS 切得再快，用戶也可能遇到“登不上或資料對不上”的體驗問題。

第三步：設定切換時間目標（RTO）與容忍（RPO）

RTO（復原目標時間）回答“要在多久內恢復服務”；RPO（允許的資料遺失時間）回答“允許丟失多少資料”。DNS 故障轉移多半影響 RTO，而資料同步設計影響 RPO。你要把兩者一起考慮，否則切換後雖然服務回來了，資料面卻無法滿足需求。

第四步：演練並收斂參數

TTL、健康檢查頻率、閾值、回切延遲，這些參數不是一次設好就永遠正確。隨著服務體系變更（例如依賴變多、流量型態改變），參數也要更新。把演練納入變更流程，讓調整有數據支持。

結語：真正的不中斷，是“可控的故障處理”

AWS DNS 故障轉移能夠提供的是一種可控的路徑：當主站不可用時，把解析結果引導到備援端；當主站恢復時，依照你定義的可用標準回到主站或保持在備援端。它不是魔法，也不是承諾絕對零影響的保證，而是讓故障從不可預測變成可預期。

想要網站不中斷，你要做的不是追求“切換秒級成功”，而是把健康判定、TTL 快取、架構承接、資料與會話策略、以及監控演練一起打通。當這些環節都被同一套標準約束，你就會得到一種更成熟的韌性：即便發生區域級或鏈路級異常，你仍能在使用者感受到之前，把服務帶回可用狀態。