AWS公佈US-EAST-1區域服務中斷原因：DynamoDB DNS自動化模組衝突釀災

針對10月20日發生於其US-EAST-1 (北維吉尼亞)區域的大規模服務中斷事件，AWS稍早正式公佈事故調查結果。如同先前初步判斷，問題根源確實指向其核心資料庫服務DynamoDB，但具體肇因則是DynamoDB DNS軟體自動化模組的設計缺陷，導致了災難性的連鎖反應。

此次事故影響範圍廣泛，總計波及142項AWS服務與上千家客戶，並且耗時長達15小時才完全恢復。

自動化衝突：DNS Enactor清理程序誤刪關鍵IP

根據AWS說明，DynamoDB的DNS管理由兩個自動化模組負責，分別包含生成新DNS計劃的「DNS Planner」，以及負責將計劃佈署至Amazon Route53的「DNS Enactor」。爲提高可用性，AWS在三個不同可用區 (AZ) 獨立運行了三套DNS Enactor。

正常情況下，Enactor在佈署前會確認計劃版本，並且逐一更新端點，若遇衝突則重試，完成後再清理過期計劃。

不過，此次事故的觸發點在於：

• Enactor A開始佈署一個計劃，但在更新多個DNS端點時遭遇嚴重延遲，進度緩慢且不斷重試。與此同時，DNS Planner持續發佈新版計劃。

• 獨立運作的Enactor B取得了最新計劃，並且快速完成所有端點更新。而完成任務的Enactor B隨即啓動了清理程序。

• 關鍵衝突點：進度落後的Enactor A，此時才正要將過時計劃佈署到Enactor B剛剛更新完成的US-EAST-1區域服務節點上。

• 緊接着，Enactor B的清理程序，誤將Enactor A正在佈署的這個「過時計劃」視爲已無效而刪除。

結果導致US-EAST-1區域服務節點的所有IP位址全數被移除，DNS紀錄變成空白，無法被解析，同時也無法再佈署任何新計劃。

連鎖效應：EC2實例啓動受阻，NLB、Lambda癱瘓

AWS指出，儘管DynamoDB的核心DNS問題約在3小時內就獲得解決，但其引發的連鎖效應卻持續了十幾個小時。

主要原因是許多核心服務高度依賴DynamoDB，例如負責管理EC2實例狀態的工具DropletWorkflow Manager (DWFM)，在DynamoDB故障期間大量「租約」(leases)失效。當DNS恢復正常後，DWFM試圖同時重建數十萬筆租約，瞬間的龐大請求量導致其系統壅塞當機。

而DWFM的失效，直接導致新的EC2實例無法正常啓動，網路設定也出現延遲。這進一步衝擊了依賴EC2的網路負載平衡器 (NLB) 及無伺服器運算服務AWS Lambda等下游服務，導致整體故障時間被大幅拉長。

AWS緊急應對：全球暫停DynamoDB DNS自動化模組

此次事故再次凸顯了大型雲端架構中，自動化系統雖能提升效率，但也可能因其複雜的依賴關係與潛在的競態條件 (race condition)而引發災難。原爲提升可靠性而設計的多重自動化與分區冗餘機制，反而在極端條件下產生了非預期的衝突。

作爲應對措施，AWS宣佈暫時停用全球範圍內的DynamoDB DNS Planner與DynamoDB DNS Enactor自動化模組，直到完成相關的安全檢查、競態條件修正，以及更完善的控制機制導入。

US-EAST-1服務區域核心地位放大災情

US-EAST-1作爲AWS最早建立、規模最大也最核心的區域服務，承載了許多全球控制平臺與管理後端，其穩定性至關重要。而DynamoDB作爲AWS內部 (如 Amazon.com、Alexa)與外部客戶 (如 Netflix)最依賴的NoSQL資料庫服務之一，其DNS解析的短暫失效，便足以引發如此大規模的連鎖反應，也再次提醒了業界對於關鍵基礎設施依賴性的潛在風險。

《原文刊登於合作媒體mashdigi，聯合新聞網獲授權轉載。》