AWS帳號購買優惠 AWS Route 53 健康檢查自動故障轉移設定

一、為什麼 Route 53 健康檢查要認真做

很多團隊在上雲時，把「高可用」當成一套設定：開啟某個功能、填一些參數、看到狀態變成綠色就算完成。但在真實流量裡，健康檢查到底在判斷什麼、多久判定一次、判定錯了會怎樣、切換會不會造成雪崩——這些才是差距所在。

Route 53 的健康檢查（Health Checks）與自動故障轉移（Failover）結合後，DNS 層會把使用者導向可用資源。它的優點是：不依賴應用程式內建判斷、不需要你自己做複雜的路由服務；DNS 本身能在故障時快速調整解析結果。但同時 DNS 也有其特性：快取時間（TTL）與解析器行為會影響你切換的體感速度，所以設計一定要考慮。

把它做穩，通常不是「把狀態通了就好」，而是要建立一套可預期的判斷機制：什麼情況算健康、什麼情況就要切換、切換後要等多久才回切、以及你如何驗證整個流程。

二、核心概念先釐清：健康檢查與故障轉移的關係

1. 故障轉移的 DNS 邏輯

Route 53 自動故障轉移本質上是：針對同一個 DNS 名稱與記錄，建立「主要（Primary）」與「備援（Secondary）」兩組路由策略，並由健康檢查的結果決定哪一組會被回應。

在 Route 53 中你會看到類似這種結構：

• AWS帳號購買優惠 主要記錄：在健康檢查為 healthy 時回傳主要目標
• 備援記錄：在健康檢查變為 unhealthy 時回傳備援目標
• 切換與回切通常需要等待時間（例如過去幾次檢查都要不健康，才判定失效）

因此，健康檢查不是裝飾，它直接控制你的流量走向。

2. 健康檢查的判斷結果是“狀態”，不是“原因”

Route 53 健康檢查能測到的是：目標是否可連線、特定路徑回應是否符合預期、HTTP/HTTPS 的狀態碼是否符合、或是 TCP 連線是否建立成功。它不理解你的應用層為什麼壞了。

這意味著如果你用錯指標（例如把登入頁當作健康檢查、或只檢測 TCP 是否開啟），可能會出現：看起來 healthy 但實際服務不可用，或看起來 unhealthy 但只是偶發延遲。

3. TTL 與切換體感

健康檢查決定了「權威 DNS 會回什麼」，但使用者端拿到的解析結果仍可能受快取影響。TTL 越長，舊結果在快取期內仍會被用戶端使用，你切換時就不會立刻“全體到位”。

實務上你需要在穩定性與快切換之間做平衡：TTL 過低可能讓 DNS 查詢量增加，也可能帶來更多解析壓力；TTL 過高又會讓故障切換看起來慢。

三、規劃前的三個問題：先想清楚才設定

在你開始操作 Route 53 之前，建議先回答三個問題。你回答得越精確，後續設定越少返工。

1. 你要檢查的是哪一種“健康”？

常見健康面向有三種：

• 可連線（Reachable）：例如 TCP 連線能否建立
• 服務就緒（Ready）：例如 HTTP 回應狀態碼、或特定健康端點
• 應用可用（Usable）：需要你的端點能反映真實依賴（DB、快取、下游服務）是否正常

若你的應用只要能連到服務就行，那 TCP 可能足夠；但多數場景下你應該用「應用層健康端點」，讓健康檢查能反映更貼近使用者體驗的狀況。

2. 你要切到哪裡？是一個備援，還是多區輪流？

最常見的是：主要在 A 區，備援在 B 區；或主要指向某個負載平衡器，備援指向另一個。當你有多個端點時，建議你先用清楚的命名與拓撲圖把主備關係畫出來。

同時要考慮憑證與網路：如果備援端點在不同網段、防火牆規則不同、或 TLS 設定不同，健康檢查在“切換後”可能仍會失敗，導致你以為切到了，實際又沒切成功。

3. 你希望多快切換？多快回切？容忍多少抖動？

切換速度受健康檢查參數影響（例如檢查頻率、判定次數阈值等）。回切也會帶來風險：主站剛恢復可能還在抖動，若你太快回切，流量可能反覆跳。

AWS帳號購買優惠 要把這件事想成韌性設計，而不是只追求最快。

四、健康檢查類型：HTTP/HTTPS、TCP、以及它們的適用性

1. HTTP/HTTPS 健康檢查：最常用的路徑

HTTP/HTTPS 健康檢查通常會對某個 URL（例如 /healthz 或 /status）發送請求，並依回應狀態碼與回應內容（在部分設定可進一步比對）來判斷 healthy。

它的優勢是：你可以把健康端點設計成反映應用真正狀態。你可以做到：

• 依賴都正常才回 200
• 若 DB 或快取不可用，回 503 或其他非 200
• 短暫延遲可用回應時間與重試策略避免誤判

但注意：健康端點要輕量且穩定。若你的健康端點本身會很重、或需要複雜流程，反而會讓檢查造成壓力。

2. TCP 健康檢查：適合“服務是否在”的場景

TCP 健康檢查只驗證連線是否建立成功。它常見於：

• 你不方便提供 HTTP 健康端點
• 服務協定本身不是 HTTP，但只要端口可連就算健康

但它無法保證應用真的能處理請求。若應用卡住、或下游故障導致服務不可用，TCP 仍可能看起來 healthy，切換就失去了意義。

3. HTTPS 與憑證問題：別忽略驗證與成本

若你使用 HTTPS 健康檢查，要確保健康檢查服務能正確連到目標，且憑證設定不會在備援切換時出現差異。常見坑是：

• 備援環境的憑證尚未部署完成
• 憑證域名不匹配
• 安全群組或網路 ACL 阻擋了健康檢查來源

這些問題通常只在切換觸發後才暴露，所以部署時就要把它當成第一優先檢查項。

五、設定自動故障轉移：從建立記錄到串起健康檢查

以下以通用流程描述（不同帳號權限與界面版面可能略有差異），但邏輯一致。

1. 準備你的 DNS 名稱與目標

你要決定：

• DNS 名稱：例如 app.example.com
• 主要目標：例如主要 ALB / NLB 的別名（Alias）或固定 IP
• 備援目標：例如備援 ALB / NLB

建議優先使用 Alias 指向 ALB/NLB，因為它能避免你手動管理 IP；也更貼合雲端動態伸縮的特性。

2. 建立健康檢查：把判斷“定義清楚”

健康檢查本體有幾個關鍵設定：

• Protocol：HTTP、HTTPS 或 TCP
• Endpoint：主機（或負載平衡器的對應）與連線埠
• Path：若是 HTTP/HTTPS，設定健康端點路徑
• Response codes：設定成功條件，例如 200-299 或 200
• Check interval 與 unhealthy threshold：決定判定快慢

設計原則是：你要讓判斷與“使用者真的遇到問題”的時間盡量對齊，而不是只抓連線層。

例如：如果你的應用在 DB 故障時會回 503，那健康端點就應該在 DB 停止時立即反映；同時要避免因為偶發慢查詢導致一兩次失敗就判定 unhealthy。

3. 建立故障轉移的 Route 53 記錄（Primary/Secondary）

在 Route 53 建立記錄時，選擇「故障轉移」（Failover）路由策略。通常會出現兩筆記錄：

• 記錄 A：路由策略為 Primary，並指定主要目標
• 記錄 B：路由策略為 Secondary，並指定備援目標

同時要把兩筆記錄關聯到同一個或對應的健康檢查。多數情況下：只要主要的健康檢查為 unhealthy，就切到備援。

如果你設計的是雙向切換（主備都要檢查），就要小心健康檢查來源、判斷邏輯與回切策略，否則可能出現兩邊都判斷 healthy 或都判斷 unhealthy 的狀態。

AWS帳號購買優惠 4. TTL 與記錄策略：讓切換可預期

在故障轉移中，TTL 通常要設為相對合理的值。具體要看你對切換速度的要求與查詢量成本。

• 希望故障切換更快：TTL 可以設低一些
• 希望穩定、減少解析波動：TTL 可以設高一些

注意：就算 TTL 很低，也要考慮解析器行為。有些客戶端或中間層即使尊重 TTL，也可能因快取策略不同導致體感略慢。

六、參數設計的“工程化”：避免誤切與抖動

健康檢查參數的目的，是在“快速”與“穩定”間找到平衡。這裡最常出問題的不是設定錯，而是把參數設得過於激進或過於保守。

1. 檢查間隔與判定次數：讓系統有緩衝

典型的健康檢查會有：

• 檢查頻率（interval）
• 判定 unhealthy 需要的連續失敗次數或時間窗口
• 從 unhealthy 回 healthy 可能也需要連續成功次數

如果你的 interval 設得太短、unhealthy 閾值太低，短暫的網路抖動或單次超時就可能觸發切換。切換一旦發生，這個抖動還可能讓系統在主備之間反覆跳。

如果反過來閾值太高，故障持續很久才切走，等於讓主要問題“撐到最後”。

2. 健康端點的回應語意：讓判斷更貼近真實故障

健康端點要清楚區分：

• 存活（Liveness）：程式還在跑
• 就緒（Readiness）：可以接收流量

Route 53 的健康檢查通常更需要的是 readiness。因為你的目標是避免把流量導向不可用服務。

實務上，你可以讓健康端點在依賴不可用時回應 503，讓 DNS 切換發生得更合理。

AWS帳號購買優惠 3. 回切策略：不要把“恢復”當成“已穩定”

很多系統在主站恢復後會有一段熱身期：連線重新建立、快取重新載入、快照或背景工作恢復。若健康檢查立刻判定 healthy，DNS 可能立刻回切。

因此在健康端點與健康檢查閾值上，你可以加入“穩定窗口”的概念：例如要求連續成功多次才算 healthy，或在應用內部加入一段冷卻期間。

七、常見誤區與排查思路

誤區 1：只檢查端口開啟，卻以為是服務可用

AWS帳號購買優惠 TCP 健康檢查會讓很多依賴故障漏掉。若你看到 DNS 沒切換但使用者抱怨仍存在，往往是健康判斷不足。

排查方法：

• 直接對健康端點做 HTTP/HTTPS 檢查（狀態碼與回應時間）
• 檢查健康端點是否正確反映依賴狀態
• 確認安全群組或防火牆允許健康檢查來源

誤區 2：健康端點太重，反而成為故障源

如果 /health 會去查大量資料、或做複雜聚合，健康檢查本身也會消耗資源，導致系統在高負載下變得更不穩。

排查方法：

• 設計健康端點只做必要檢查（例如依賴連線可用、版本正確）
• 避免對外部慢服務做長時間等待
• 加上快速超時與保護機制

誤區 3：TTL 設太高，切換“看起來沒動”

故障切換發生了，但你在用戶端或測試端看不到變化，是因為快取。尤其是你用瀏覽器測時，瀏覽器或系統 DNS 快取可能影響觀感。

排查方法：

• AWS帳號購買優惠 在多個解析器或使用測試工具明確查詢權威 DNS
• 檢查 TTL 設定與實際解析行為
• 在測試時清除本機快取（或使用不同網路環境）

誤區 4：備援環境沒準備好，結果切過去仍 unhealthy

如果你只驗證主要環境正常，卻忽略備援端點的網路、憑證、健康端點路徑或安全群組，切換後會再次卡住。

AWS帳號購買優惠 排查方法：

• 在未切換前就針對備援端點做同樣的健康驗證
• 確認健康端點路徑與回應碼一致
• 確認防火牆允許檢查來源連線

八、實務落地：一份可直接照做的設定檢查清單

以下清單可以當作你在正式上線前的“最後一公里”。你可以照順序逐項核對。

1. 健康端點

• 有獨立路徑（如 /healthz）且語意是 readiness
• 依賴不可用會回非 200（如 503）
• 回應時間快且具備超時
• 在主與備援環境行為一致

AWS帳號購買優惠 2. 網路與存取

• AWS帳號購買優惠 安全群組允許來自健康檢查來源的連線（與你的健康檢查模式一致）
• 埠號正確，HTTP/HTTPS 對應端口正確
• 備援環境的防火牆規則與路徑一致

AWS帳號購買優惠 3. Route 53 記錄與健康檢查關聯

• Primary 記錄指向主要目標
• Secondary 記錄指向備援目標
• 健康檢查與記錄關聯正確（不是綁錯到另一個環境）
• TTL 設定符合切換需求

4. 切換與回切測試

• 模擬主站失效（例如暫停應用或讓健康端點返回失敗碼）觀察是否切到備援
• 觀察切換需要多久（健康檢查閾值 + DNS 快取的總效果）
• 恢復主站後觀察回切行為，確認不會抖動

九、如何驗證“真的可用”：別只看綠燈

驗證健康檢查綠燈很重要，但那只是第一層。你還需要驗證切換後的整體可用性。

1. 用者體感指標：延遲與錯誤率

當切換發生時，你要觀察：

• HTTP 5xx/4xx 是否下降（至少 5xx 不應大幅增加）
• 回應時間是否合理
• 是否出現 TLS handshake 失敗或憑證錯誤（特別是 HTTPS）

2. DNS 行為指標：查詢結果與權威回應

不要只依賴瀏覽器快取。你可以：

• 從不同網路環境查詢同一域名
• 使用工具直接查詢 DNS，確認權威回應是否已切換

3. 日誌與告警：把問題定位到層級

當切換失敗時，你要能回答三個問題：

• Route 53 判斷主站真的變 unhealthy 了嗎？
• 切到備援後，備援端點是否也健康？
• 使用者端解析到正確的目標了嗎？

把這些觀測點補齊，你會更快修復，而不是猜測。

十、設計建議總結：把健康檢查當成“產品規格”

Route 53 健康檢查與自動故障轉移不是簡單設定，而是你在 DNS 層定義的“服務品質規格”。它決定了流量在故障時如何被分配，也決定了你能否在最需要的時候維持可用。

把它做好，通常遵循以下原則：

• 用反映 readiness 的健康端點，而不是只檢查端口
• 設定合理的檢查頻率與阈值，避免誤切與抖動
• 考慮 TTL 與快取，讓切換速度可預期
• 備援環境在上線前就要驗證為可用，而不是切換後才發現問題
• 用戶體感與 DNS 行為要一起驗證，不要只看綠燈

當你把健康檢查當成規格在管理，你的故障轉移就不會停留在“幸運時能用”，而是能做到“可控、可測、可持續”。