S2E35 AWS 大當機內幕：Race Condition 拖垮全球網路

重點摘要

• DynamoDB DNS 紀錄因多個 DNS Enactor 同時寫入時的競態條件被清空，導致全球所有依賴 DynamoDB 的服務找不到這個核心資料庫
• 當機觸發四波連鎖故障：DynamoDB DNS（3 小時修復）→ EC2 Droplet 系統卡死（再 3 小時）→ 網路層路由積壓（再 5-6 小時）→ 清理收尾（最後 3 小時），合計 15 小時
• US-East-1 占整體 AWS 流量 35-40%，AWS 又占全球雲端市場三成，估計此次影響全球約 12% 的網路流量
• 受波及範圍包括 Snapchat、WhatsApp、Coinbase、Robinhood、英超半自動越位判決系統
• 預防之道在於多區域（Multi-Region）甚至多雲（Multi-Cloud）部署，並定期進行 Game Day 消防演練

詳細內容

事件背景：US-East-1 的核心地位

US-East-1（美東一區）是 AWS 2006 年最早建立的區域，大多數 AWS 服務的預設部署都在此，佔整體 AWS 流量的 35-40%。AWS 本身占全球雲端市場約三成，因此這次當機估計影響全球約 12% 的網路流量，規模極為龐大。

根本原因：Race Condition 清空 DynamoDB DNS

DynamoDB 的 DNS 管理架構由兩個元件組成：

• DNS Planner：監控負載平衡器（Load Balancer）的流量與健康狀態，產生 DNS 更新計畫，規劃每組 Load Balancer 應分配多少流量比重
• DNS Enactor：US-East-1 的每個可用區（AZ，共 6 個）各有一個，負責讀取計畫並寫入 AWS 自家 DNS 服務 Route 53

正常情況下，多個 Enactor 的速度差距很小，不會出問題。這次的問題是：

1. 某一個「一號 Enactor」處理速度異常遲緩
2. 其他 Enactor 已將最新 DNS 計畫寫入 Route 53
3. 一號 Enactor 仍在處理舊計畫，並準備寫入
4. 系統偵測到「這是已過時的舊計畫」，將其清除
5. DynamoDB 的 DNS 紀錄因此被抹空，全球服務找不到 DynamoDB 的 IP 位址

DNS 相當於網路世界的電話簿，DNS 紀錄一旦消失，服務就從網路上「蒸發」，無法被任何人連線。

連鎖崩潰的四個階段

第一階段（前 3 小時）：DynamoDB DNS 修復 工程師於 10 月 20 日凌晨 12 點左右發現問題，人工介入約 3 小時後將 DynamoDB DNS 記錄恢復，但噩夢還未結束。

第二階段（再 3 小時）：EC2 Droplet 系統卡死 EC2 內部的 Droplet Workflow Manager（功能類似 Kubernetes，管理 EC2 底層的虛擬資源「Droplet」的使用狀態）依賴 DynamoDB 追蹤每台資源是否被占用。DynamoDB 斷線期間，Droplet Workflow Manager 無法取得任何資訊，逾時後將全部資源判定為「已占用、無法使用」，向客戶端回報容量不足。

DynamoDB 恢復後，大量積壓的狀態確認請求同時湧入，又造成超時與重試風暴，Droplet Workflow Manager 因此無法自動復原。工程師花了 3 小時手動修復，虛擬機器才能重新啟動。

第三階段（再 5-6 小時）：網路層無路由 EC2 實例啟動後卻沒有網路連線，原因是 Network Manager（路由資訊管理系統）同樣面臨積壓請求過多、持續超時的問題，無法更新路由表。工程師降低 Network Manager 的負載後，網路才逐步恢復。

第四階段（最後 3 小時）：清理收尾 此階段內工程師先對 API 進行限流（Throttling），防止大量客戶端 retry 加劇壓力，再逐步解除限制，讓 113 個受影響的服務陸續重新上線。

廣泛的外部影響

• 社群媒體：Snapchat、WhatsApp、Signal、Zoom、Slack 均出現部分中斷
• 金融服務：加密貨幣交易所 Coinbase、股票交易平台 Robinhood 暫時無法執行交易
• 航空公司與政府網站：多個單位服務中斷
• 英超足球：某場比賽的半自動越位系統因 AWS 當機無法啟用。該系統透過場邊 10-20 台高速攝影機即時追蹤 22 名球員的關節位置，建立 3D 虛擬模型並結合球的感測器資料，在爭議進球發生時毫秒內判定越位。AWS 當機後裁判被迫回歸傳統人工畫線方式，雖最終裁定正確，但耗時更長，引發當場球迷不滿。

SLA 賠償義務

DynamoDB 合約保證 99.99% 的可用性，換算為每個月僅允許約 4.5 分鐘停機。此次 DynamoDB 中斷約 3 小時，遠超標準，AWS 須向受影響客戶退款或提供服務額度（Credit）。加上其他 112 個受影響服務，AWS 這個月對這些客戶的帳單可能改為退款或補償。

股價反應與市場視角

事件發生後 Amazon 股價幾乎不受影響，甚至小幅上漲。這與 AWS 內部工程師的緊張感形成反差。講者分析，外部投資人認為這是可修復的系統程式錯誤（非駭客攻擊或內部惡意行為），屬於已知可控風險；若是安全漏洞或人為蓄意破壞，市場反應才會更劇烈。這也提醒我們，身陷其中時容易陷入「管窺效應」（Tunnel Vision），放大事件的嚴重性。

如何預防類似事件

AWS 自身的改進

• 暫停 DNS Planner 與 DNS Enactor 的自動更新機制，待競態條件修復後重新啟用
• 於事件後第四天發布 Post-Mortem 檢討報告，列出多項改進措施

客戶端的因應策略

• Multi-Region（多區域）部署：在美東、美西、亞洲、歐洲各部署服務副本，單一區域故障不影響整體可用性
• Multi-Cloud（多雲）策略：同時使用 AWS、Azure、Google Cloud，降低對單一供應商的依賴
• 制定 Incident Response SOP：明確的緊急應變手冊，規定發生故障時要查看哪些 Dashboard、依照哪些步驟處理
• 定期 Game Day 演練：在測試環境模擬故障（例如切斷某個資料中心的電源），訓練團隊在真實事故中的反應速度

講者強調，「防堵所有低機率事件」的成本可能遠高於「接受偶發損失」，每間公司應評估自身規模與風險承受度，找到合理的投入點。他也以 CrowdStrike 事件作對比：那次是 Windows 端點設備大規模崩潰，需逐台手動修復，影響持續數週，比這次雲端服務當機更難收拾。

精選語錄

「意外之所以是意外，就是因為它是意料之外。一定會有我們把所有事情都想通了，結果就發現它在意想不到的情況下又掛了。」

「不管你再怎麼小心，在軟體工程的領域裡面，你做了多少的保護措施，都還是有可能會出事。我們做的只是降低這件事情發生的機率，以及如果這件事情發生了，我可以多快把我的服務再上線。」

「有的時候或許強迫大家離線是件好事情……很多人說 Facebook、IG 當機的時候，突然覺得清閒的不少，好像心情好了不少。」

時間軸

• 00:00 — 引言：10/20 AWS US-East-1 大當機事件概述，113 個服務、15 小時中斷
• 約 04:00 — AI 新聞疲乏感的個人觀察與頻道內容方向說明
• 約 08:00 — US-East-1 的核心地位與事件規模（全球約 12% 網路流量受影響）
• 約 11:00 — 事件直接原因：DynamoDB DNS 紀錄被清空
• 約 14:00 — Amazon 股價反應與市場視角分析（管窺效應）
• 約 17:00 — SLA 說明：99.99% 可用性換算每月僅 4.5 分鐘停機容忍度
• 約 20:00 — 受影響服務列舉：社群媒體、金融交易所、航空、政府單位
• 約 22:00 — 英超半自動越位系統的運作原理與受影響經過
• 約 27:00 — 技術深度解析：DNS Planner、DNS Enactor、Race Condition 機制
• 約 34:00 — 連鎖崩潰：EC2 Droplet Workflow Manager 的積壓重試風暴
• 約 39:00 — 網路層 Network Manager 積壓問題與修復過程
• 約 42:00 — 15 小時完整修復時間軸回顧
• 約 44:00 — 預防措施：Multi-Region、Multi-Cloud 策略與成本效益評估
• 約 50:00 — Incident Response SOP 與 Game Day 消防演練的重要性
• 約 53:00 — 結語：與 CrowdStrike 事件比較、擁抱工程領域不確定性的心態