一次AWS DNS故障如何級聯癱瘓半個互聯網

2025年10月20日，AWS最關鍵的 us-east-1 區域發生了一場持續 15 小時的重大故障，導致全球超過 1000 家企業服務中斷。 而這場故障背后的根因，竟然僅僅是一條 AWS 內部 DNS 解析失效。

從凌晨的 DNS 解析失效開始，AWS DynamoDB、EC2、Lambda 等 142 項服務相繼受到影響，進而導致全球互聯網的大部分功能停轉。 Snapchat、Roblox、Coinbase、Signal、Reddit、Robinhood 等熱門應用離線，數十億美元在半天內蒸發，這不啻于一場賽博世界的地震。

更有甚者，因為 us-east-1 是所有 AWS 區域的公共控制平面所在地，即使工作負載部署在歐洲或亞洲的企業也未能幸免。 這場故障暴露了云計算時代最根本的脆弱性：一條損壞的 DNS 就能引發數十億美元的經濟損失。 這不是技術能力問題，而是架構哲學的失敗 —— us-east-1 成了全球互聯網依賴的中樞神經系統，而這個系統現在已經證明，它會定期失靈。

賽博地震：數十億美元在半天內蒸發

這場持續15小時的故障，在全球數字經濟中掀起了一場"賽博地震"。Catchpoint CEO 受CNN采訪時表示：這次故障的預估經濟損失達"數十億甚至數千億美元"。

金融服務首當其沖。Robinhood 在美東交易時段完全離線，數百萬散戶投資者被鎖在賬戶之外； Coinbase 的宕機讓加密貨幣交易者在市場波動中束手無策； Venmo 收到8000份故障報告，用戶的數字錢包瞬間"消失"。在現代無現金社會，這相當于所有人同時失去了錢包。

游戲行業損失同樣慘重。Roblox 7000萬日活用戶被迫下線，虛擬經濟瞬間停擺； Epic Games 的 Fortnite、任天堂的 Pokémon GO、育碧的彩虹六號集體失聲。 對這些依賴用戶粘性的平臺而言，每小時的宕機都可能意味著永久的用戶流失。

英國的政府網站，稅務，海關，銀行系統受到影響，多家航空公司內部系統受損導致部分航班運營混亂。 更諷刺的是，Amazon 自家產品全線翻車 —— 購物網站、Alexa、Ring 門鈴、Prime Video，甚至 AWS 自己的工單系統都未能幸免。 這充分說明：即使是 AWS 的創造者，也無法避免對 us-east-1 的單點依賴。

故障根因：DNS失效引發的蝴蝶效應

太平洋夏令時2025年10月19日晚11:49，us-east-1 區域的多個服務錯誤率突然攀升。 直到22分鐘后，AWS 才在健康儀表板發布第一條確認。截止到10月20日下午3:53分結束，整個故障持續了16小時。

根因看似簡單：AWS 內部系統的 DNS 解析失敗。但這個"小故障"卻觸發了驚人的級聯效應。 DynamoDB 無法訪問，而它恰恰是 AWS 控制平面的基石 —— IAM、EC2、Lambda、CloudWatch 等關鍵服務全部依賴它。

AWS 花了三個半小時修復 DNS，以為萬事大吉，卻沒想到積壓的請求產生了"重試風暴"，再次壓垮了 DynamoDB。 EC2、負載均衡器、Lambda 與 DynamoDB 之間的循環依賴讓系統陷入死局。 AWS 被迫采用手工限流的方式，通過限制啟動 EC2 實例，限流 Lambda/SQS 輪詢來緩解壓力，直到下午才逐漸恢復。

級聯放大：互聯網的阿喀琉斯之踵

us-east-1 不是普通的數據中心，它是 AWS 全球基礎設施的中樞神經系統。除了政務云和歐洲主權云，所有 AWS 區域的公共控制平面都在這里。

這意味著什么？即使你的應用部署在東京或法蘭克福，當需要進行 IAM 認證、配置 S3、訪問 DynamoDB 全局表、調用 Route 53 時，請求仍要路由到 us-east-1。 這次故障中，英國政府網站、Lloyds 銀行、加拿大 Wealthsimple —— 這些看似與美東無關的服務，都因這種隱性依賴而癱瘓。

us-east-1 的特殊地位源于歷史 —— 作為 AWS 的第一個區域，19年的演進讓它積累了大量技術債務。 重構它？數百萬行代碼、數千個微服務、難以計數的客戶依賴，任何改動都可能引發更大災難。 于是 AWS 選擇了維持現狀，直到故障再次提醒我們這個選擇的代價。

技術解剖：小故障如何演變為大災難

從2017年到2025年，us-east-1 的每次重大故障都暴露了相同的架構反模式，而 AWS 似乎從未真正吸取教訓。

循環依賴的死亡螺旋 : AWS 各項基礎服務依賴 DynamoDB，DynamoDB 又部署在 EC2 上，而 EC2/LB 又依賴 DynamoDB， —— 這種循環依賴會導致架構復雜度指數增長， 系統復雜度被隱藏在微服務的層層抽象之下，極大拉高故障分析定位，處理解決的難度與時長。平時歲月靜好，故障時卻成為死亡陷阱。 我們已經在 ，， 這些公司的翻車案例中見過太多類似的例子了。

中心化的單點故障 : 在2020年 Kinesis 故障后，AWS承諾實施蜂窩架構以提供艙壁并限制爆炸半徑，但顯然并沒有落實到全局管控平面上來。 us-east-1 區域作為整個 AWS 全球全局控制平面的單點，牽一發而動全身，這種集中化創建了系統性風險。 盡管 AWS 聲稱在 us-east-1 部署了六個可用區提供冗余，但遇到 DNS 這種全局基礎服務故障時依然形同虛設。 這揭示了一個殘酷真相：再精妙的多區域設計，也敵不過一個單點依賴。

監控系統的自我失明 : 最荒謬的是，AWS 自己的監控工具也依賴被監控的服務。CloudWatch 也依賴 DynamoDB ，然而當 DynamoDB 失效，監控系統也隨之失明。 這創造了一個悖論：最需要監控數據的時候，恰恰是監控系統最不可用的時候。外部監控平臺如 Datadog 同樣托管在 AWS 上，形成了"自己監控自己"的閉環。 故障發生75分鐘后，AWS 狀態頁面仍顯示"一切正常" —— 也許不是他們在撒謊，而是監控系統自己也癱瘓了。

斷路器的集體缺席 : 盡管 AWS 發布了大量關于實施斷路器的最佳實踐指南，但這次故障顯示出，AWS 自己的內部服務網格可能并沒有實施這些機制。 斷路器本應在檢測到下游服務故障時自動"熔斷"，停止發送請求，避免雪崩。 但實際情況是，當 DynamoDB 出現問題，所有依賴服務繼續瘋狂重試，形成"重試風暴"。 AWS 最終被迫手動介入，通過人工限流來控制局面 —— 這種原始的應對方式，與其宣揚的"自動化一切"理念形成鮮明對比。

知識流失：組織功能障礙的技術表現

在運維圈里有句名言 —— “It’s always DNS” 。任何經驗豐富的 SRE 遇到這種事都會優先檢查 DNS。 但 AWS 團隊卻在黑暗中摸索了兩個多小時，然后又在斷路限流的路上掙扎了五個小時。精銳盡失的團隊難堪大任，這無疑是草臺班子理論的又一例證。

2022-2025年間，亞馬遜裁員超過27000人。內部文件顯示，各個級別 "不希望流失的人才" （Regretted Attrition）的流失率高達69-81%。 強制返回辦公室政策進一步推動高級人才離職。Justin Garrison 在2023年離職時就預言會有更多大規模故障[1] —— 事實證明他還是太樂觀。

Regretted Attrition：即企業本不希望他們離職、但他們仍主動離開的員工。 即在所有離職員工中，有 69–81% 屬于公司不希望失去的人。

機構記憶的流失是不可逆的。那些知道系統隱秘依賴關系的老工程師走了，留下的新人即使再努力，也缺乏診斷復雜級聯故障的直覺。 這種隱性知識無法通過文檔傳承，只能通過多年的事故響應經驗積累。 當下一個"邊緣案例"出現時，缺乏經驗的團隊只能眼睜睜看著系統崩潰，并花費老司機幾十倍的時間去摸索定位與笨拙處理。

云經濟學家 Corey Quinn 在《亞馬遜人才流失終于導致 AWS 走向衰落[2]》中辛辣諷刺道：“當你炒掉最優秀的工程師時，就別驚訝云廠商會忘記 DNS 是怎么工作的” —— "下一次大故障已經在醞釀中，只是哪個人手不足的團隊率先被哪個邊緣案例絆倒的問題而已。"

冷峻未來：應對云計算帶來的脆弱性

在幾個月前，，僅僅半年不到，AWS DNS 故障又再一次把全球互聯網拉下水。

當一家云廠商內部的一條 DNS 記錄損壞，就能讓全球數千萬用戶的生活陷入混亂； 當一個區域的數據中心網絡故障，能讓遍布五大洲的企業同時癱瘓，我們必須承認：云計算在帶來便利的同時，也創造了前所未有的系統性脆弱性。

更何況，當三家美國公司控制全球63%的云基礎設施，這已經不僅是技術問題，更是地緣政治風險和數字主權挑戰。單一供應商的便利性與全球性的脆弱性構成了一個危險的悖論。

在云服務商的營銷話術中，“99.99% 可用性”、“全球多活冗余”、“企業級可靠性”是標配承諾。 但將 AWS、Azure、Google Cloud 近年的實際故障記錄擺在一起，云可靠性的神話開始動搖。 Cherry Servers 在 2025 年發布的研究[3] 揭示了殘酷的數據： 過去一年 AWS 發生了 38 次重大事件，平均恢復時間 1.5 小時；Google Cloud 發生了 78 次，平均 5.8 小時；Azure 雖僅 9 次，但平均時長高達 14.6 小時。

“下云” 正從異端想法變成現實選項。在此次 AWS 宕機中，馬斯克旗下的社交平臺 X（原推特）因使用自己的數據中心運營而安然無恙。老馬在 X 對 AWS 發出多次嘲諷與揶揄。 知名 SaaS 廠商 37signals 則早在 2022 年就決定將 Basecamp 和 HEY 郵件服務遷出公有云，。 Dropbox 更是在 2016 年便開始逐步減少對 AWS 的依賴，重返自建數據中心。這并不是技術倒退，而是對過度集中化風險的理性校正。

對于有能力的企業來說，混合部署——將核心系統自主可控部署，本地掌握底線，而將彈性擴展需求交給云端處理，可能是更明智的選擇。 每一家依賴云的公司都需要認真思考：是否所有工作負載都必須上云？那些關鍵系統是否應該保留獨立運行的能力，以在云崩潰時維持最基本的服務？

在脆弱性中構建韌性，在依賴與集中化中保持獨立自主 —— 這不是技術選擇，而是生存哲學。 us-east-1 還會再次故障 —— 不是是否，而是何時。所以真正的問題是：下一次故障發生時，你是否已經準備好了？

小廣告

老規矩，寫文章不打廣告約等于沒寫。如果你想減少對集中式云服務的依賴，在故障時擁有自救的能力而非干坐著等死，那么從最重要的 PaaS 數據庫自建著手，增強自主可控與跨云運營的能力，或許是一個明智的選擇。

老馮的 允許你在不依賴 DNS，S3，IAM，Docker，K8S，等外部系統的前提下，在物理機 / 虛擬機裸 Linux 環境上一鍵部署企業級的 PostgreSQL RDS 集群，自帶 高可用，PITR，負載均衡，監控系統， 424 個 PG 擴展，以及獨家 Supabase 支持 。軟件開源免費，本地優先 —— 即使斷網，也能持續擴容，在云上云下運行至地老天荒。

歡迎訪問 https://pgsty.com / https://pigsty.cc 了解更多詳情。

References

[1] Justin Garrison 在2023年離職時就預言會有更多大規模故障:https://justingarrison.com/blog/2023-12-30-amazons-silent-sacking/
[2]亞馬遜人才流失終于導致 AWS 走向衰落:https://www.theregister.com/2025/10/20/aws_outage_amazon_brain_drain_corey_quinn/
[3]Cherry Servers 在 2025 年發布的研究:https://www.cherryservers.com/blog/cloud-outages
[4]AWS: Update - AWS services operating normally:https://www.aboutamazon.com/news/aws/aws-service-disruptions-outage-update
[5]AWS: Service Health, Operational issue - Multiple services (N. Virginia):https://health.aws.amazon.com/health/status
[6]HackerNews: AWS multiple services outage in us-east-1:https://news.ycombinator.com/item?id=45640838
[7]CNN: Amazon says systems are back online after global internet outage:https://edition.cnn.com/business/live-news/amazon-tech-outage-10-20-25-intl
[8]Register: Today is when the Amazon brain drain finally sent AWS down the spout:https://www.theregister.com/2025/10/20/aws_outage_amazon_brain_drain_corey_quinn/
[9]Converge: DNS Failure Triggers Multi-Service AWS Disruption in US-EAST-1: https://convergedigest.com/aws-reports-major-outage-in-us-east-1-region/

專欄：云計算泥石流

云故障

云資源

下云記