針對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解析的短暫失效，便足以引發如此大規模的連鎖反應，也再次提醒了業界對於關鍵基礎設施依賴性的潛在風險。
