事件概覽
2025年10月20日，全球最大雲端服務供應商 Amazon Web Services (AWS) 的
US-EAST-1 區域（北維吉尼亞）發生近年來最嚴重的服務中斷事件。這起長達
14小時32分鐘的全球性災難，不僅震撼雲端產業，更成為雲端架構設計與危機管理的經典案例。
核心數據
| 指標 | 數據 |
|---|---|
| 中斷時長 | 14小時32分鐘 (2025-10-19 23:48 PDT → 2025-10-20 14:20 PDT) |
| 受影響服務 | 142 個 AWS 服務 |
| 官方更新次數 | 21 次（平均每 43 分鐘一次） |
| 受影響用戶 | 數百萬（Snapchat、Roblox、Robinhood、McDonald’s、United Airlines 等） |
| 預估損失 | 數十億美元（Catchpoint CEO 估計） |
| 受影響國家 | 全球性（包含美國、英國、歐洲等） |
| 事件回報數 | 超過 650 萬次（Downdetector 統計，涵蓋 1000+ 服務） |
影響範圍
受影響的關鍵服務： – 社交平台：Snapchat、Signal –
遊戲服務：Roblox、Fortnite – 金融科技：Robinhood、Coinbase、Venmo –
航空業：United Airlines（網站與 App） – 零售服務：McDonald’s App、Amazon
Ring 門鈴攝影機 – AI 服務：ChatGPT、Perplexity – 銀行業：Lloyds、Bank of
Scotland、Halifax（英國）
AWS 內部受影響服務：
EC2、DynamoDB、Lambda、S3、RDS、ECS、CloudWatch、CloudFront、IAM、STS、API
Gateway、ELB、SQS、SNS、Step
Functions、Redshift、Connect、Glue、Athena、Kinesis 等共 142
個服務。
完整事件時間軸
階段一：發現與初步調查（00:11 –
02:01）
timeline
title AWS US-EAST-1 重大事件時間軸（2025-10-20）
section 發現階段
23:48 (10/19) : 事件實際開始（DNS 問題觸發）
00:11 : 開始調查 US-EAST-1 多服務錯誤率升高
00:51 : 確認多個 AWS 服務受影響
01:26 : 確認 DynamoDB 端點顯著錯誤率
section 根因識別
02:01 : 識別「潛在根本原因」：DynamoDB DNS 解析問題
02:22 : 應用初步緩解措施，觀察早期恢復跡象
02:24 : 解決 DynamoDB DNS 問題（但服務未恢復）
02:27 : 大多數請求開始成功，處理排隊請求
section 連鎖故障處理
03:03 : 確認全球服務與 US-EAST-1 依賴功能恢復
03:35 : DNS 問題完全緩解，但 EC2 啟動仍失敗
04:08 : 持續處理 EC2 launch 錯誤與 Lambda 延遲
05:48 : 部分 AZ 中成功啟動新 EC2 實例
section 確認真正根因
07:29 : 確認多個服務網路連通性問題
08:04 : 識別問題源於「EC2 內部網路」
08:43 : 🎯 確認真正根因：NLB 健康檢查子系統故障
section 恢復階段
09:13 : 採取緩解措施，開始看到連通性恢復
09:38 : NLB health checks 恢復（關鍵轉折點）
10:03 : 驗證 EC2 修復方案，準備部署
11:22 : EC2 啟動成功率提升，網路問題減少
12:15 : 大多數服務持續恢復，Lambda 改善
section 完全恢復
13:03 : Lambda invocation 完全恢復
13:52 : EC2 限流降至事件前水平
14:48 : Connect 處理新會話正常，積壓處理中
14:20 : ✅ 所有 AWS 服務恢復正常運作
14:53 : 發布完整 Post-Event Summary詳細時間軸與 AWS 官方更新
23:48 PDT (Oct 19) –
事件實際開始
根據最終報告，事件在此時觸發，但 AWS 尚未察覺。
00:11 PDT –
首次發現問題
“We are investigating increased error rates and latencies for
multiple AWS services in the US-EAST-1 Region.”
分析： AWS 在事件開始 22
分鐘後才察覺問題，顯示監控系統存在檢測延遲。
00:51 PDT –
確認影響範圍
“We can confirm increased error rates and latencies for multiple AWS
Services in the US-EAST-1 Region. This issue may also be affecting Case
Creation through the AWS Support Center or the Support API.”
分析： 甚至連支援系統都受影響，顯示問題嚴重性。
01:26 PDT –
識別表面症狀
“We can confirm significant error rates for requests made to the
DynamoDB endpoint in the US-EAST-1 Region. This issue also affects other
AWS Services in the US-EAST-1 Region as well.”
分析： 將 DynamoDB
識別為主要症狀，但尚未找到根本原因。
02:01 PDT –
初步根因假設（後證實為誤判）
“We have identified a potential root cause for error
rates for the DynamoDB APIs in the US-EAST-1 Region. Based on our
investigation, the issue appears to be related to DNS
resolution of the DynamoDB API endpoint in US-EAST-1. We are
working on multiple parallel paths to accelerate recovery.”
分析：
使用「potential」（潛在）一詞，顯示工程師尚未完全確定。後續證實 DNS
只是觸發器，非真正根因。
02:24 PDT – DNS
問題解決（但災難持續）
“After resolving the DynamoDB DNS issue at 2:24 AM, services began
recovering but we had a subsequent impairment in the
internal subsystem of EC2 that is responsible for launching EC2
instances due to its dependency on DynamoDB.”
關鍵發現： DNS
修復後，服務並未恢復，反而觸發連鎖故障。這是理解整起事件的關鍵證據。
08:04 PDT –
縮小問題範圍
“We continue to investigate the root cause for the network
connectivity issues that are impacting AWS services. We have identified
that the issue originated from within the EC2 internal
network.”
分析： 花費 6 小時才將問題範圍縮小至 EC2
內部網路。
08:43 PDT –
確認真正根本原因
“We have narrowed down the source of the network connectivity issues
that impacted AWS Services. The root cause is an underlying
internal subsystem responsible for monitoring the health of our network
load balancers.”
重大突破：
終於找到真正根因！不再使用「potential」，而是明確的「The root
cause is」。
從 02:01（DNS 假設）到 08:43（NLB Health Check 確認），AWS 工程師花費
6 小時 42 分鐘才找到真正原因。
09:38 PDT – 關鍵轉折點
“We recovered the Network Load Balancer health checks at 9:38
AM.”
分析： NLB health checks
恢復後，服務開始大規模恢復。這證明 NLB 監控系統才是真正的罪魁禍首。
14:20 PDT – 完全恢復
“By 2:20 PM, all AWS services returned to normal operations.”
總結： 從實際開始（23:48）到完全恢復（14:20），共
14 小時 32 分鐘。
根本原因技術解剖
表面觸發器 vs 真正根因
表面觸發器：DNS
解析問題
- 時間：2025-10-19 23:49 PDT
- 症狀：DynamoDB 服務端點 DNS 解析失敗
- 修復時間：02:24 PDT（2.5 小時）
真正根本原因：NLB
Health Monitoring System 故障
- 時間：確認於 08:43 PDT，實際可能更早開始
- 本質：內部子系統無法正確監控 Network Load Balancer 健康狀態
- 影響持續時間：02:24 → 09:38（7.2 小時）
- 完全恢復時間：09:38 → 15:01（5.4 小時）
為何 AWS 一開始誤判？
原因一：症狀與根因混淆
表面現象：DynamoDB DNS 解析失敗
↓
實際機制：NLB Health Check 系統故障
↓
無法正確監控 DynamoDB 端點健康狀態
↓
將正常的 DynamoDB 端點標記為「不健康」
↓
DNS 解析系統返回錯誤（因為沒有「健康」的端點可返回）
↓
表面上看起來像「DNS 問題」類比： – 症狀：病人發燒（DNS 錯誤） –
根因：免疫系統失效（NLB Health Monitoring）
修復發燒（DNS）無法解決免疫系統問題，因此病情持續惡化。
原因二：連鎖反應的複雜性
AWS 基礎設施的服務間依賴關係極其複雜：
graph TD
A[NLB Health Monitoring<br/>System] -->|監控失效| B[DynamoDB 端點]
B -->|被標記為不健康| C[DNS 解析返回錯誤]
C -->|依賴 DynamoDB| D[EC2 Instance Launch]
D -->|無法啟動| E[Lambda 執行環境]
D -->|無法啟動| F[CloudWatch 資料收集]
D -->|無法啟動| G[其他 142 個服務]
A -->|同時影響| H[其他服務的<br/>NLB Health Checks]
H -->|網路連通性失效| I[Lambda/CloudWatch/<br/>API Gateway 等]
style A fill:#ff6b6b
style H fill:#ff6b6b
style C fill:#ffa500
style D fill:#ffa500原因三：漸進式調查是標準 SRE 實踐
AWS 採用「逐層剝洋蔥」的標準故障排查方式：
- 第一層（表面症狀）：錯誤率升高 → 需要縮小範圍
- 第二層（服務層）：DynamoDB 錯誤 → 找到症狀焦點
- 第三層（基礎設施層）：DNS 解析問題 →
找到觸發器 - 第四層（內部系統層）：EC2 內部網路 → 縮小範圍
- 第五層（控制平面層）：NLB Health Monitoring →
真正根因
這種方法雖然耗時，但能確保不遺漏任何可能性。
時間證據：為何 DNS
不是真正根因？
| 關鍵時間點 | 事件 | 說明 |
|---|---|---|
| 02:24 | DNS 問題解決 | AWS 解決了 DynamoDB DNS 解析問題 |
| 02:24 – 09:38 | 災難持續 | 7.2 小時 —— 如果 DNS 是根因，服務應在此時恢復 |
| 09:38 | NLB Health Check 恢復 | 關鍵轉折點，服務開始大規模恢復 |
| 09:38 – 14:20 | 逐步恢復 | 4.7 小時 —— 處理積壓與限流解除 |
結論： DNS 修復後仍有 12
小時的中斷，證明 DNS 只是觸發器，NLB Health Monitoring System
才是真正的病根。
NLB Health Monitoring
System 的致命角色
什麼是 NLB Health
Monitoring System？
定義： Network Load Balancer (NLB) Health Monitoring
System 是 AWS 內部的控制平面子系統，負責：
- 監控 NLB 後端目標的健康狀態
- 定期向後端服務發送健康檢查請求
- 判定哪些後端是「健康」(Healthy)，哪些是「不健康」(Unhealthy)
- 控制流量分配
- 只將流量路由到「健康」的後端
- 自動從負載均衡池中移除「不健康」的後端
- 影響服務發現 (Service Discovery)
- DNS 解析系統依賴健康檢查結果返回 IP 地址
- 如果所有後端都被標記為「不健康」，DNS 解析會失敗
- 維持內部網路連通性
- EC2 instance 啟動依賴 NLB 提供的內部網路連通性
- Lambda 執行環境需要 NLB 提供的網路路由
為何這個子系統會引發全球性災難？
問題一：監控者本身需要被監控（Who
Watches the Watchers?）
正常架構：
NLB Health Monitoring → 監控 → DynamoDB/EC2/Lambda
事件中的悖論：
NLB Health Monitoring 自己故障了
↓
但沒有「上層監控系統」檢測到這個故障
↓
它繼續運作，但判斷錯誤
↓
將所有「健康」的服務標記為「不健康」
↓
引發全局性災難根本問題： AWS
缺乏「Meta-監控」機制，無法及時發現監控系統本身的異常。
問題二：控制平面與數據平面隔離不足
理想架構：
控制平面（Control Plane）：負責管理、監控、配置
- 故障時應該只影響「新操作」（如新 EC2 啟動）
- 不應影響「已運行服務」（如已運行的 EC2）
數據平面（Data Plane）：負責實際流量處理
- 應該能在控制平面故障時繼續運行AWS 事件中的現實：
NLB Health Monitoring（控制平面）故障
↓
影響了已運行的 EC2 instance 網路連通性（數據平面）
↓
違反了「平面隔離」原則結果： 不僅新的 EC2
無法啟動，連已運行的服務也失去網路連通性。
問題三：單點依賴與缺乏容錯
架構脆弱點： 1. 全球服務依賴單一區域
(US-EAST-1) – IAM、STS（全球身份驗證）的主要端點 – DynamoDB
Global Tables 的協調中心
- NLB Health Monitoring System 缺乏冗餘
- 沒有備份監控系統
- 單一子系統故障即引發連鎖災難
- 過度耦合的服務依賴
- EC2 啟動為何需要依賴 DynamoDB？
- Lambda 為何受 NLB health checks 影響？
- 缺乏「降級運行」(Degraded Mode) 機制
連鎖故障機制詳解
雙重連鎖反應路徑
路徑一：DNS → DynamoDB
→ EC2 → 上層服務
graph LR
A[NLB Health<br/>Monitoring 故障] --> B[DynamoDB 端點<br/>被誤判為不健康]
B --> C[DNS 解析失敗]
C --> D[EC2 Instance<br/>Launch 失敗]
D --> E[Lambda 執行<br/>環境無法建立]
D --> F[ECS Container<br/>無法啟動]
D --> G[Glue Job<br/>無法執行]
style A fill:#ff6b6b
style B fill:#ffa500
style C fill:#ffa500
style D fill:#ffa500受影響服務：
ECS、Glue、RDS、Redshift、EMR、SageMaker（所有依賴 EC2 的服務）
路徑二：NLB
Health Check → 網路連通性 → 全局服務
graph LR
A[NLB Health<br/>Monitoring 故障] --> B[NLB Health Checks<br/>全面失效]
B --> C[網路連通性<br/>失效]
C --> D[Lambda<br/>Invocation 失敗]
C --> E[CloudWatch<br/>無法收集指標]
C --> F[API Gateway<br/>無法路由請求]
style A fill:#ff6b6b
style B fill:#ff6b6b
style C fill:#ff0000受影響服務： Lambda、CloudWatch、API Gateway、Step
Functions、EventBridge
為何修復時間如此漫長？
階段一：DNS 修復（2.5
小時）
- 相對快速，因為是表層問題
- 但修復後問題未解決
階段二：連鎖故障處理（7.2
小時）
- 需要識別 NLB Health Monitoring 故障（耗時 6.5 小時）
- 修復 NLB Health Check 系統（耗時 0.7 小時）
階段三：服務逐步恢復（5.4
小時）
- 為何不能立即全速恢復？因為 AWS 採取「限流策略」
限流原因： 1. 避免 Thundering Herd
問題 – 如果所有服務同時重啟，會對基礎設施造成巨大壓力 –
可能引發「二次崩潰」
- 確保穩定性優於速度
- 逐步解除限流（EC2 啟動、Lambda 調用、SQS 輪詢）
- 確認每個階段穩定後再進入下一階段
- 處理積壓任務
- CloudTrail、EventBridge、Connect 等服務有大量積壓
- 需要時間逐步清空
結論： AWS 選擇「慢即是快」(Slow is Smooth, Smooth
is Fast) 的恢復策略，犧牲速度換取穩定性。
142 個受影響服務清單
核心基礎設施服務
- 計算：EC2、Lambda、ECS、EKS、Fargate、Batch
- 儲存：S3、EBS、EFS、FSx
- 資料庫：DynamoDB、RDS、Aurora、Redshift、ElastiCache、DocumentDB、Neptune
- 網路：VPC、ELB (ALB/NLB/CLB)、CloudFront、Route
53、API Gateway、Direct Connect、VPN
開發者工具
- CI/CD：CodeBuild、CodePipeline、CodeDeploy
- 監控：CloudWatch、X-Ray、CloudTrail
- 管理：Systems
Manager、CloudFormation、Config、OpsWorks
應用服務
- 訊息佇列：SQS、SNS、EventBridge、Kinesis、MQ
- 工作流程：Step Functions、SWF、Glue
- AI/ML：SageMaker、Bedrock、Comprehend、Rekognition、Polly、Transcribe、Translate
企業服務
- 身份驗證：IAM、Cognito、STS、IAM Identity
Center - 安全：Secrets Manager、WAF、Security
Hub、GuardDuty、Firewall Manager - 分析：Athena、EMR、QuickSight、DataZone、Lake
Formation
客戶服務
- 通訊：Connect、Chime、WorkMail、Pinpoint、SES
- 終端使用者：WorkSpaces、AppStream 2.0、WorkSpaces
Thin Client
完整清單共 142 個服務 —— 這顯示 US-EAST-1 區域對 AWS
全球架構的重要性。
事後分析：AWS
最終報告的根本原因修正
即時判斷 vs. 完整調查報告
在事件發生的當下，AWS
工程師經歷了一個「逐步逼近真相」的過程。然而，在完整的 Post-Event
Summary（2025年10月23日發布）中，AWS 基於深入的事後調查（Root Cause
Analysis, RCA），重新定位了各元件在這次事件中的角色。
即時更新中的判斷（事件進行中）
02:01 PDT – AWS 首次提出假設： > “We have
identified a potential root cause for error rates for
the DynamoDB APIs… The issue appears to be related to DNS
resolution.”
關鍵詞：使用「potential」（潛在），表示尚未完全確定。
08:43 PDT – AWS 確認判斷： > “We have narrowed
down the source… The root cause is an underlying
internal subsystem responsible for monitoring the health of our network
load balancers.”
關鍵詞：不再使用「potential」，而是明確的「The
root cause is」。
最終報告中的結論（事後深入調查）
在完整的 Post-Event Summary 中，AWS 給出了不同的結論：
“The root cause of this issue was a latent
race condition in the DynamoDB DNS management system that
resulted in an incorrect empty DNS record for the service’s regional
endpoint.”
關鍵差異：根本原因從「NLB Health Monitoring
System」改為「DynamoDB DNS race condition」。
為什麼會有這個差異？
原因一：即時恢復
vs. 根本原因分析的目標不同
即時恢復階段（事件進行中）： –
目標：盡快恢復服務 –
關注點：「修復什麼能讓服務恢復？」 –
結論：修復 NLB Health Monitoring → 服務恢復 →
因此判定為根本原因
事後調查階段（Post-Event Summary）： –
目標：找出「為什麼會發生」 –
關注點：「如果沒有發生 X，整個事件會不會根本不存在？」
– 結論：如果沒有 DNS race condition，NLB 不會開始誤判 →
DNS race condition 才是起點
原因二：因果鏈的複雜性
兩個結論都有其合理性，但觀察的層次不同：
即時判斷的邏輯（由下而上）：
觀察到的現象：所有服務失效
↓
找到恢復關鍵：修復 NLB Health Monitoring
↓
結論：NLB Health Monitoring 是根本原因事後分析的邏輯（由上而下）：
起點：DynamoDB DNS race condition
↓
觸發：DynamoDB endpoint 無法解析
↓
導致：EC2 實例啟動失敗（依賴 DynamoDB）
↓
導致：網路配置傳播延遲
↓
導致：NLB 健康檢查開始誤判
↓
放大：反覆移除/恢復循環
↓
結果：服務持續不穩定 14.5 小時原因三：「根本原因」的定義差異
在事故分析中，「根本原因」有兩種常見定義：
定義 A：Critical Path（關鍵路徑） –
「移除哪個問題，恢復速度最快？」 – 即時判斷採用此定義 → NLB Health
Monitoring
定義 B：First Cause（起始原因） –
「如果時光倒流，阻止哪個問題，整個事件不會發生？」 – 事後分析採用此定義
→ DynamoDB DNS race condition
重新定位各元件的角色
基於 AWS 最終報告，我們需要重新理解各元件的角色：
| 元件 | 即時判斷中的角色 | 最終報告中的角色 | 技術定位 |
|---|---|---|---|
| DynamoDB DNS race condition | 表面觸發器 | ✅ 根本原因 | First Cause |
| NLB Health Monitoring System | ✅ 根本原因 | 次級影響與放大器 | Critical Path |
| EC2 實例啟動失敗 | 次級影響 | 直接影響 | Intermediate Effect |
| 142 個服務中斷 | 最終結果 | 最終結果 | Final Impact |
正確的完整因果鏈
根據 AWS 最終報告，完整的技術因果鏈應為：
【起點】DynamoDB DNS race condition
↓
兩個獨立的 DNS Enactor 互動出現競態條件
↓
一個 Enactor 套用舊的 DNS 計劃
另一個 Enactor 同時刪除該計劃
↓
DynamoDB regional endpoint 的 DNS 記錄變為空白
↓
【直接影響】DynamoDB endpoint 無法解析
↓
EC2 實例啟動依賴 DynamoDB → 啟動失敗
↓
新啟動的 EC2 實例網路配置傳播延遲
↓
【次級影響】NLB 健康檢查子系統受影響
↓
NLB 對網路延遲的 EC2 實例執行健康檢查
↓
健康檢查失敗（但實際上實例是正常的）
↓
【放大機制】反覆移除/恢復循環
↓
NLB 移除「不健康」的實例（從 DNS 刪除）
↓
下一次檢查時實例已就緒 → 檢查成功
↓
NLB 恢復實例（加回 DNS）
↓
不斷重複此循環，增加系統負載
↓
健康檢查系統本身效能下降
↓
觸發自動 AZ DNS failover
↓
【最終結果】服務持續不穩定 14.5 小時時間證據的重新解讀
讓我們重新審視關鍵時間點，從「完整因果鏈」的角度：
| 時間 (PDT) | 事件 | 原先解讀 | 正確解讀 |
|---|---|---|---|
| 23:48 | 事件開始 | DNS 問題觸發 | ✅ DNS race condition 發生（根本原因） |
| 02:24 | DNS 問題解決 | 表面修復 | ✅ 修復了起始問題，但連鎖反應已啟動 |
| 02:24 – 09:38 | 災難持續 7.2 小時 | 證明 DNS 不是根因 | ❌ 錯誤推論：這段時間是次級影響與放大機制的作用時間 |
| 09:38 | NLB Health Check 恢復 | 真正根因修復 | ✅ 關鍵路徑修復，但非根本原因 |
| 14:20 | 完全恢復 | 所有問題解決 | ✅ 積壓處理完畢 |
關鍵洞察： – DNS 修復後服務未恢復，並非證明「DNS
不是根因」 –
而是因為連鎖反應已經啟動，即使移除起始原因，已啟動的次級問題（NLB
誤判）仍需單獨處理 –
類比：森林火災由閃電引起，但滅掉閃電無法撲滅已燃燒的大火
AWS 工程師的診斷演進
理解這個演進過程，對學習事故調查非常有價值：
階段 1（00:11 – 02:01）：發現表面症狀 –
觀察：DynamoDB 錯誤率升高 – 假設：可能是 DNS 問題 – 狀態：症狀層分析
階段 2（02:01 – 02:24）：嘗試修復假設原因 –
行動：修復 DNS 問題 – 預期：服務應該恢復 – 結果：❌ 服務未恢復
階段 3（02:24 – 08:43）：重新調查 –
發現：問題比想像的更複雜 – 深入：EC2 內部網路有問題 –
進展：逐步縮小範圍
階段 4（08:43）：找到關鍵路徑 – 突破：NLB Health
Monitoring System 故障 – 判斷：這是根本原因（即時判斷）
– 理由：修復它就能恢復服務
階段 5（事後 10/23）：完整 RCA – 回溯：NLB
為什麼會開始誤判？ – 發現：DNS race condition 是起點 – 修正：DynamoDB
DNS race condition 才是根本原因（最終結論）
本文的記錄價值
重要說明：本文保留了 AWS
即時判斷的演進過程，這是非常有價值的學習資料。
為什麼保留即時判斷？ 1.
真實性：反映事件當時的真實狀況 2.
教育價值：展現大型分散式系統故障調查的複雜性 3.
SRE 實踐：說明為何即時恢復與事後 RCA 的結論會不同 4.
歷史記錄：AWS 更新內容的演變本身就是重要資料
如何正確閱讀本文： –
「根本原因技術解剖」章節：記錄事件當時的判斷（即時分析） –
「事後分析」章節（本章節）：補充最終報告的結論（完整 RCA） –
兩者結合：完整理解從即時恢復到深入分析的全過程
關鍵學習點
學習點 1：即時恢復 ≠
根本原因分析
即時恢復： – 目標：快速恢復服務 – 方法：找到
Critical Path（關鍵路徑） – 問題：可能誤判起始原因
根本原因分析： – 目標：防止再次發生 – 方法：找到
First Cause（起始原因） – 需要：事後冷靜深入調查
學習點 2：連鎖反應的慣性
複雜系統的連鎖反應具有「慣性」： –
即使移除起始原因，連鎖反應可能已無法自動停止 –
需要在連鎖反應的每個關鍵節點進行干預 – 這也是為什麼修復 DNS
後服務未恢復
學習點
3：兩種「根本原因」都重要
從實務角度： – First Cause（DynamoDB DNS race
condition）：需要修復以防再發生 – Critical Path（NLB
Health Monitoring）：需要加強以縮短恢復時間
兩者都需要改進措施！
參考資料
- AWS 官方 Post-Event
Summary：https://aws.amazon.com/message/101925/
(2025-10-23) - 本文「根本原因技術解剖」章節：記錄事件當時的即時判斷演進
- 資料查證日期：2025-10-24
經典場景：當監控者失效
哲學問題：Who Watches the
Watchers?
這句拉丁諺語 “Quis custodiet ipsos custodes?”
在這次事件中得到了現實印證：
傳統監控架構：
監控系統 → 監控 → 業務系統問題： 當監控系統本身故障時，誰來發現？
AWS 事件中的體現：
NLB Health Monitoring System
↓（故障但無人發現）
繼續運作，但判斷錯誤
↓
將正常服務標記為異常
↓
引發全局災難
↓
AWS 工程師花費 6.5 小時才發現監控系統本身有問題解決方案：Meta-監控架構
改進架構：
Meta-監控層（監控監控系統）
↓
監控系統層（監控業務系統）
↓
業務系統層（實際服務）實施方式：
-
獨立的 Meta-監控系統
監控目標：NLB Health Monitoring System 的行為是否正常 檢測指標： - Health Check 請求成功率 - 判定結果的合理性（是否突然大量標記為不健康） - 系統響應時間 -
異常檢測 (Anomaly Detection)
# 偽代碼示例 if (unhealthy_targets / total_targets) > 0.5: # 超過 50% 被標記為不健康，極不合理 alert("NLB Health Monitoring System 可能故障") trigger_failover_to_backup_monitoring_system() -
冗餘監控系統
- 主監控系統 + 備份監控系統
- 兩者使用不同的技術棧（避免共同模式故障）
- 當主系統異常時自動切換
類似歷史案例
Google Cloud 2019-06-02
事件
- 根因： 網路配置錯誤導致流量路由失效
- 相似點： 控制平面問題影響數據平面
- 持續時間： 4.5 小時
- 教訓： Google
後續實施「配置變更的漸進式推出」機制
Azure 2018-09-04
事件
- 根因： DNS 配置錯誤
- 相似點： DNS 問題引發連鎖故障
- 持續時間： 24 小時
- 教訓： Microsoft 加強 DNS 系統冗餘
Cloudflare 2019-07-02
事件
- 根因： WAF 規則部署錯誤
- 相似點： 監控/防護系統反而成為攻擊者
- 持續時間： 3.5 小時
- 教訓： Cloudflare 實施更嚴格的配置驗證
AWS 事件的獨特性： – 持續時間最長（15 小時） –
影響服務數量最多（142 個） – 根因最深層（監控系統本身故障） –
恢復策略最保守（大量使用限流）
關鍵發現與技術啟示
發現一：US-EAST-1
的「特殊地位」是系統性風險
為何 US-EAST-1 如此關鍵？
- 歷史原因
- 2006 年 AWS 首個上線的區域
- 承載大量遺留架構與技術債
- 全球服務依賴
- IAM、STS 全球身份驗證主要端點
- DynamoDB Global Tables 協調中心
- CloudFront 配置管理中心
- 客戶慣性
- 最早期客戶集中於此
- 遷移成本極高（數據、網路延遲、合規性）
風險分析：
US-EAST-1 故障 → 全球服務受影響
→ 其他區域無法完全獨立運作
→ 違反「區域獨立性」設計原則發現二：控制平面與數據平面耦合是致命缺陷
理論 vs 現實：
| 設計原則 | AWS 承諾 | 事件中的現實 |
|---|---|---|
| 控制平面故障不影響數據平面 | ✅ 宣稱隔離 | ❌ NLB Health Check 故障影響已運行服務 |
| 區域獨立性 | ✅ 每個區域獨立運作 | ❌ 其他區域依賴 US-EAST-1 全球服務 |
| 降級運行能力 | ✅ 核心服務應可降級 | ❌ EC2 無法啟動，無降級機制 |
改進方向： – EC2 應有「無 DynamoDB
啟動模式」（降級但可用） – 全球服務應真正實現多區域主備 –
監控系統故障不應影響已建立的網路連接
發現三：漸進式根因分析是雙刃劍
優點： – 避免草率結論導致錯誤決策 –
逐層排查確保不遺漏問題
缺點： – 耗時過長（6.5 小時才找到真正根因） –
初期誤判（DNS）可能誤導客戶
最佳實踐：
並行調查 + 透明溝通
同時進行：
1. 表層症狀緩解（DNS 修復）
2. 深層根因調查（NLB Health Monitoring）
3. 對外溝通時明確區分「症狀」vs「根因」發現四：限流策略體現成熟的
SRE 文化
AWS
選擇犧牲恢復速度換取穩定性，展現了「可靠性優先於速度」的核心價值：
限流實施： – EC2 instance launch throttling – Lambda
invocation throttling – SQS polling rate limiting – Asynchronous
operations throttling
哲學：Slow is Smooth, Smooth is Fast –
快速恢復可能引發二次崩潰（Thundering Herd） –
漸進式恢復確保不重蹈覆轍
結果： – 沒有「二次崩潰」 – 恢復過程穩定可控 –
但總時長延長至 15 小時
系列文章預告
本文是 AWS US-EAST-1
重大事件系列分析的第一篇，完整記錄了事件的來龍去脈與技術根因。
想了解： – AWS 如何處理這次危機？溝通策略有哪些值得學習？ –
企業如何從中學習，設計容錯架構與多雲策略？ –
技術決策者應該採取哪些立即行動？ – SRE 團隊如何複製 AWS
的優秀實踐，避免類似錯誤？
請閱讀系列第二篇： AWS
架構韌性深度解析：從 US-EAST-1 事件看 Multi-AZ/Multi-Region
設計原則
參考資料
- AWS 官方來源
- AWS Health
Dashboard – US-EAST-1 Operational Issue (2025-10-20) - AWS Service Health Dashboard 事件記錄（21 次狀態更新完整記錄）
- AWS Health
- 媒體報導
- CNN Business: “AWS global outage, Amazon, Snapchat, Roblox and
Fortnite down” (2025-10-20) - NPR: “Outage at Amazon Web Services disrupts websites across the
internet” (2025-10-20) - TechRadar: “Amazon fixes huge AWS outage that broke much of the
internet” (2025-10-20) - Bloomberg: “AWS Outage: Amazon Cloud Restored; Hit Snapchat, Roblox,
Robinhood” (2025-10-20)
- CNN Business: “AWS global outage, Amazon, Snapchat, Roblox and
- 技術社群分析
- DEV Community: “The AWS Outage on Oct 20, 2025: What Broke, Why It
Felt Global, and How Amazon Stabilized It” - DEV Community: “The Great AWS Outage of October 2025: When the
Internet’s Backbone Buckled” - GeekWire: “AWS outage was not due to a cyberattack — but shows
potential for ‘far worse’ damage”
- DEV Community: “The AWS Outage on Oct 20, 2025: What Broke, Why It
- 專家評論
- Catchpoint CEO: 總損失估計數十億美元
- Betsy Cooper（網路安全專家）: “這突顯出依賴少數公司的脆弱性”
📌 關於本系列
這是雲端服務史上的經典案例，值得所有技術決策者、架構師、SRE
工程師深入研究。我們將透過兩篇系列文章，完整剖析事件始末與實戰啟示。
第一篇（本文）： 事件完整記錄與技術解剖
第二篇： AWS
架構韌性深度解析：從 US-EAST-1 事件看 Multi-AZ/Multi-Region
設計原則