- 登入
- 註冊
以為多區域備援就安全？AWS 當機提醒你檢查的 3 件事
內容目錄
顯示
從 DNS 故障到恢復壅塞，重新檢查你的備援是否真的有效
設計工具打不開、資料處理停住、登入與排程接連失敗。當看似無關的服務同時出問題，我們才發現：它們背後可能依賴同一套雲端基礎設施。
2025 年 10 月 20 日，AWS 北維吉尼亞區域（us-east-1）發生大規模服務異常。依官方報告，主要事件持續約 14.5 小時，但各項服務的受影響與恢復時間不同，並非整個 AWS 都停止運作。〔1〕
這場事故從 DynamoDB 的 DNS 錯誤開始，接著牽動 EC2、網路設定與其他依賴服務。更值得注意的是，即使最初的問題修好了，後續系統也沒有立刻恢復正常。
它提醒我們：備援不只是多準備一套系統，還要確認故障發生時，那套系統是否真的能接手。
核心問題
明明準備了備援，為什麼一個區域出問題，服務還是可能一起停擺？
因為主系統與備援系統看似分開，卻可能共用認證、設定或切換流程中的關鍵依賴。
而在恢復階段，累積的工作與反覆重試，也可能讓剛恢復的系統再次陷入壅塞。
關鍵洞察
真正有效的備援，需要同時處理「共同依賴」與「恢復負載」。
我們不只要問備援部署在哪裡，也要問：主區域失效時，還能不能啟動備援、把流量切過去，以及逐步消化累積的工作？
一個 DNS 錯誤，為什麼會牽動這麼多服務？
DynamoDB 是 AWS 的 NoSQL 資料庫。應用程式要連上它，通常需要先透過 DNS，把服務名稱解析成可連線的位址。
這次事故的起點，是 DynamoDB 自動化 DNS 管理系統中的競態條件：兩個更新程序在特定時序下互相干擾，讓較舊的設定覆蓋新設定，隨後又被清理程序刪除，造成區域端點的 IP 位址被清空。
結果是，依賴這個端點的應用程式與 AWS 內部服務，無法建立新的連線。
資料庫不一定消失了，但系統找不到通往它的路。
DynamoDB 的主要連線問題在接近三小時後恢復，然而，這只是整場事故的第一段。〔1〕
問題修好了，為什麼服務還沒恢復？
故障期間，部分依賴 DynamoDB 的 EC2 內部管理工作無法完成。當連線恢復，系統開始處理大量待恢復的狀態，卻因逾時與重新排隊，陷入持續壅塞。
接著，累積的網路設定更新拖慢了新啟動執行個體的連線準備，也干擾了網路負載平衡器（NLB）的健康檢查，進一步影響可用容量。
因此，不能把後續影響全部歸因於「客戶 SDK 同時重試」。官方報告描述的是多個內部恢復機制與依賴服務交互作用的結果。〔1〕
但它也帶出一個通用的提醒：恢復服務，不只要排除故障，還要管理恢復過程中的負載。
提醒一：檢查備援的共同依賴，別把鑰匙留在故障區
多區域備援可以降低區域故障的風險，但前提是，備援的運作與切換流程不能被同一個故障點卡住。
AWS 官方報告提供了一個例子：Support Center 已按設計切換到另一個區域，卻因帳號中繼資料子系統回傳異常內容，仍讓部分使用者無法存取支援功能。〔1〕
這不代表所有跨區域備援都失效，而是提醒我們：切換成功，不代表整條服務鏈都能正常運作。
團隊可以先盤點：
- 備援服務的認證、金鑰與設定，是否仍依賴主區域？
- 切換流量或啟動備援時，是否需要呼叫可能受影響的管理 API？
- 備援區域是否已有足夠的資料、設定與容量，還是故障後才臨時建立？
AWS 的災難恢復指引也提醒，切換流程應盡量減少對控制平面操作的依賴。控制平面負責建立、修改與管理環境；資料平面則負責實際提供服務。〔3〕
另外，同一區域內的「多可用區部署」，與跨區域備援是不同層次的保護，不能直接畫上等號。
提醒二：定期演練，確認備援真的切得過去
架構圖上有備援，不代表事故發生時就能順利接手。
演練的價值，是把「應該可以」變成可檢查的結果。
可以先在預備環境中模擬主區域無法連線，觀察：
- 應用程式是否真的切換到備援，而不是繼續呼叫原端點？
- 儀表板能否顯示「資料延遲」並維持部分功能，而不是直接報錯？
- 團隊是否知道由誰啟動切換，以及如何確認恢復成功？
除了能不能切換，也要量測需要多久恢復，以及可能損失多少尚未同步的資料。這分別對應恢復時間目標（RTO）與恢復點目標（RPO）。〔3〕
每月演練可以是一個起點，實際頻率仍應依服務重要性與風險決定；重大架構變更後，也值得重新驗證。
提醒三：限制重試，別讓恢復中的系統再次被壓垮
重試可以處理短暫故障，但如果大量請求在相同時間重新送出，就可能放大負載，形成「重試風暴」。
團隊應檢查主要 SDK、HTTP 客戶端與背景任務的重試設定，包括：
- **指數退避與抖動：**逐次拉長等待時間，並加入隨機間隔，避免請求同時回來。
- **重試上限與逾時：**設定最多嘗試次數或總等待時間，避免無限累積。
- **節流與適當的熔斷：**限制進入系統的工作量，必要時暫停明顯無法成功的呼叫。
也要避免應用程式、SDK 與背景工作各自重試，讓次數層層相乘。對於建立訂單、付款等操作，則需確認重複呼叫不會造成重複執行。〔2〕
好的重試策略，應該給系統恢復的空間，而不是只求一直再試。
別只問有沒有備援，還要問它能不能獨立接手
這場 AWS 事故，讓我們重新看見集中依賴的風險，也提醒團隊把恢復過程納入設計。
下一次檢查架構時，可以先問三個問題：
- 主系統與備援，是否仍共用可能一起失效的關鍵依賴？
- 我們是否演練過切換，並量測實際恢復結果？
- 故障期間累積的任務與重試，會不會拖慢恢復？
不必每個服務都採用最昂貴的備援方式，但需要根據業務能承受的停機時間與資料損失，做出清楚、可驗證的取捨。
金句啟發
「在雲端時代，真正的風險不是單一故障，而是我們對單一區域毫無防備的集體依賴。」
延伸閱讀
[2] 逾時、重試與含抖動的退避策略｜Timeouts, Retries, and Backoff with Jitter（Amazon Builders’ Library）
[3] 雲端災難恢復策略｜Disaster Recovery Options in the Cloud（AWS）
以上文章整理自【數創電子報 Vol.15】AWS 15 小時當機的 3 個關鍵提醒！你的雞蛋都在同個籃子嗎？
重點整理
做了多區域備援，就能避免區域故障嗎？
多區域備援可以降低風險，但仍要檢查共同依賴。如果認證、設定或切換流程需要依賴故障區域，即使備援服務部署在其他地方，也可能無法正常接手。
怎麼確認災難恢復方案真的有效？
透過定期演練，驗證主區域失效後，系統能否切換或降級運作，並量測恢復時間與資料損失。架構圖與操作文件是起點，實際測試結果才是判斷依據。
為什麼一直重試，反而可能讓服務更難恢復？
重試本身會消耗資源。如果大量請求同步重送，或多層系統各自重試，就可能放大負載。應設定退避、抖動、重試上限與節流，並確認重複操作不會產生額外副作用。
