2025 年 10 月 20 日，Amazon Web Services（AWS）發生了近年最嚴重的一次全球性中斷，導致包括金融、電商、遊戲與 AI 平台在內的多個系統無法運行。這起事件源於 AWS US-EAST-1（北維吉尼亞）資料中心內部的 DNS 子系統錯誤，一度癱瘓了全球超過 100 項核心雲端服務 。
這次事故不僅是技術事件，更是一堂關於「數位韌性」的課，提醒我們：當企業完全建構於單一雲供應商之上時，即使是世界最大規模的雲架構也可能因一個 DNS 錯誤而瞬間失效。
AWS 故障主因：DNS 解析錯誤引發連鎖效應
根據 AWS Health Dashboard 說明，本次事件起於 DynamoDB API 的名稱解析（DNS Resolution）異常，使多個依賴其 API 的內部服務無法正常連線 。
此錯誤影響範圍擴及：
- 控制平面（Control Plane）：IAM 驗證及 CloudFormation 佈署延遲。
- 資料儲存層：DynamoDB、S3、EFS 在多區發生 Access Timeout。
- 網路層與傳遞層：Route 53、API Gateway、CloudFront 出現 502/504 錯誤。
- 應用層：Lambda、ECS、Connect 等高依賴元件無法進行正常呼叫 。
短短數分鐘內，DNS 解析異常在 AWS 微服務間形成 Cascading Failure（連鎖中斷），導致服務全球性延宕達三小時。
衝擊實例：從銀行到遊戲全面停擺
本次故障波及「網際網路半數停擺」，多家主流平台與應用因 DNS 無法解析服務端點而中斷：
- 金融與電商：Coinbase、Robinhood、Shopify、Etsy 訂單與支付 API 全面延誤。
- 社交與通訊：Snapchat、Discord、Slack、Zoom 無法登入。
- 遊戲與媒體：Fortnite、Roblox、PUBG、Disney+ 全面離線達 2～4 小時。
- AI 與 SaaS 平台：OpenAI、Anthropic Claude、Mailchimp、Notion 等服務暫時中斷。
各服務的平均 RTO（復原時間目標） 落在 2～6 小時之間，AWS 自身 Route 53 及 DynamoDB 核心功能則約於 10:11 GMT 全面恢復。
雲端設計啟示：集中式 DNS 是最大脆弱點
Cloudmax 技術團隊觀察指出，此事件暴露三層架構性問題：
- 過度集中化的控制平面設計：AWS 多項核心服務依賴 US-EAST-1 區的 DNS 子系統，一旦異常即全球同步受影響。
- 缺乏跨供應商 DNS 檢驗層：內部 DNS Pool 缺乏多重解析備援，導致 Failover 無法觸發。
- 監控盲區：AWS Health Checks 在事件初期無法即時偵測異常，使修復延誤近 90 分鐘。
Cloudmax 的建議：以多雲容錯打造真實韌性
從本次案例出發，Cloudmax 強調企業應以 多雲與跨區 DNS 架構 取代單一供應商的集中式設計。具體措施包括：
- 多雲 DNS 解析層（Multi-Resolver Architecture）：導入 Cloudflare、Google DNS、Cloudmax DNS 並行運行，確保主要域名可跨供應商解析。
- 跨區服務佈署（Geo-Distributed Deployment）：核心系統採雙活（Active-Active）或主備（Active-Standby）配置，在失聯時能自動導向替代區域。
- 自動化故障轉移（Failover Automation）：利用 API Gateway 與健康檢查（Health Metrics）監控應用狀態並切換流量。
- 低延遲資料同步（Cross-Cloud Sync）：保持多供應商間 S3/NFS 同步，以確保 RPO < 5 秒、RTO < 30 分鐘。
此次 AWS 故障讓全球重新檢視「雲端集中化」的風險。歐美地區已逐漸強化雲端自主性，如德國的 Stackit、法國的 OVHcloud，而台灣與新加坡也在推動政府專用雲與在地數據治理策略 。
Cloudmax 匯智認為真正的高可用性不僅是架構設計問題，更是企業的戰略選擇。透過多雲架構（Multi-Cloud Architecture）與持續演練的災難復原計畫（DRP），企業能確保即使雲端巨人停擺，系統仍具備自我修復與持續運營的能力。
相關文章
歡迎轉載！請見：轉載原則。
Image by Tung Nguyen from Pixabay
