2025年10月20日，AWS最關(guān)鍵的 us-east-1 區(qū)域發(fā)生了一場(chǎng)持續(xù) 15 小時(shí)的重大故障，導(dǎo)致全球超過 1000 家企業(yè)服務(wù)中斷。 而這場(chǎng)故障背后的根因，竟然僅僅是一條 AWS 內(nèi)部 DNS 解析失效。

從凌晨的 DNS 解析失效開始，AWS DynamoDB、EC2、Lambda 等 142 項(xiàng)服務(wù)相繼受到影響，進(jìn)而導(dǎo)致全球互聯(lián)網(wǎng)的大部分功能停轉(zhuǎn)。 Snapchat、Roblox、Coinbase、Signal、Reddit、Robinhood 等熱門應(yīng)用離線，數(shù)十億美元在半天內(nèi)蒸發(fā)，這不啻于一場(chǎng)賽博世界的地震。

更有甚者，因?yàn)?us-east-1 是所有 AWS 區(qū)域的公共控制平面所在地，即使工作負(fù)載部署在歐洲或亞洲的企業(yè)也未能幸免。 這場(chǎng)故障暴露了云計(jì)算時(shí)代最根本的脆弱性：一條損壞的 DNS 就能引發(fā)數(shù)十億美元的經(jīng)濟(jì)損失。 這不是技術(shù)能力問題，而是架構(gòu)哲學(xué)的失敗 —— us-east-1 成了全球互聯(lián)網(wǎng)依賴的中樞神經(jīng)系統(tǒng)，而這個(gè)系統(tǒng)現(xiàn)在已經(jīng)證明，它會(huì)定期失靈。

賽博地震：數(shù)十億美元在半天內(nèi)蒸發(fā)

這場(chǎng)持續(xù)15小時(shí)的故障，在全球數(shù)字經(jīng)濟(jì)中掀起了一場(chǎng)"賽博地震"。Catchpoint CEO 受CNN采訪時(shí)表示：這次故障的預(yù)估經(jīng)濟(jì)損失達(dá)"數(shù)十億甚至數(shù)千億美元"。

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

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

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

故障根因：DNS失效引發(fā)的蝴蝶效應(yīng)

太平洋夏令時(shí)2025年10月19日晚11:49，us-east-1 區(qū)域的多個(gè)服務(wù)錯(cuò)誤率突然攀升。 直到22分鐘后，AWS 才在健康儀表板發(fā)布第一條確認(rèn)。截止到10月20日下午3:53分結(jié)束，整個(gè)故障持續(xù)了16小時(shí)。

根因看似簡(jiǎn)單：AWS 內(nèi)部系統(tǒng)的 DNS 解析失敗。但這個(gè)"小故障"卻觸發(fā)了驚人的級(jí)聯(lián)效應(yīng)。 DynamoDB 無法訪問，而它恰恰是 AWS 控制平面的基石 —— IAM、EC2、Lambda、CloudWatch 等關(guān)鍵服務(wù)全部依賴它。

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

級(jí)聯(lián)放大：互聯(lián)網(wǎng)的阿喀琉斯之踵

us-east-1 不是普通的數(shù)據(jù)中心，它是 AWS 全球基礎(chǔ)設(shè)施的中樞神經(jīng)系統(tǒng)。除了政務(wù)云和歐洲主權(quán)云，所有 AWS 區(qū)域的公共控制平面都在這里。

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

us-east-1 的特殊地位源于歷史 —— 作為 AWS 的第一個(gè)區(qū)域，19年的演進(jìn)讓它積累了大量技術(shù)債務(wù)。 重構(gòu)它？數(shù)百萬行代碼、數(shù)千個(gè)微服務(wù)、難以計(jì)數(shù)的客戶依賴，任何改動(dòng)都可能引發(fā)更大災(zāi)難。 于是 AWS 選擇了維持現(xiàn)狀，直到故障再次提醒我們這個(gè)選擇的代價(jià)。

技術(shù)解剖：小故障如何演變?yōu)榇鬄?zāi)難

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

循環(huán)依賴的死亡螺旋 : AWS 各項(xiàng)基礎(chǔ)服務(wù)依賴 DynamoDB，DynamoDB 又部署在 EC2 上，而 EC2/LB 又依賴 DynamoDB， —— 這種循環(huán)依賴會(huì)導(dǎo)致架構(gòu)復(fù)雜度指數(shù)增長， 系統(tǒng)復(fù)雜度被隱藏在微服務(wù)的層層抽象之下，極大拉高故障分析定位，處理解決的難度與時(shí)長。平時(shí)歲月靜好，故障時(shí)卻成為死亡陷阱。 我們已經(jīng)在 ，， 這些公司的翻車案例中見過太多類似的例子了。

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

監(jiān)控系統(tǒng)的自我失明 : 最荒謬的是，AWS 自己的監(jiān)控工具也依賴被監(jiān)控的服務(wù)。CloudWatch 也依賴 DynamoDB ，然而當(dāng) DynamoDB 失效，監(jiān)控系統(tǒng)也隨之失明。 這創(chuàng)造了一個(gè)悖論：最需要監(jiān)控?cái)?shù)據(jù)的時(shí)候，恰恰是監(jiān)控系統(tǒng)最不可用的時(shí)候。外部監(jiān)控平臺(tái)如 Datadog 同樣托管在 AWS 上，形成了"自己監(jiān)控自己"的閉環(huán)。 故障發(fā)生75分鐘后，AWS 狀態(tài)頁面仍顯示"一切正常" —— 也許不是他們?cè)谌鲋e，而是監(jiān)控系統(tǒng)自己也癱瘓了。

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

知識(shí)流失：組織功能障礙的技術(shù)表現(xiàn)

在運(yùn)維圈里有句名言 —— “It’s always DNS” 。任何經(jīng)驗(yàn)豐富的 SRE 遇到這種事都會(huì)優(yōu)先檢查 DNS。 但 AWS 團(tuán)隊(duì)卻在黑暗中摸索了兩個(gè)多小時(shí)，然后又在斷路限流的路上掙扎了五個(gè)小時(shí)。精銳盡失的團(tuán)隊(duì)難堪大任，這無疑是草臺(tái)班子理論的又一例證。

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

Regretted Attrition：即企業(yè)本不希望他們離職、但他們?nèi)灾鲃?dòng)離開的員工。 即在所有離職員工中，有 69–81% 屬于公司不希望失去的人。

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

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

冷峻未來：應(yīng)對(duì)云計(jì)算帶來的脆弱性

在幾個(gè)月前，，僅僅半年不到，AWS DNS 故障又再一次把全球互聯(lián)網(wǎng)拉下水。

當(dāng)一家云廠商內(nèi)部的一條 DNS 記錄損壞，就能讓全球數(shù)千萬用戶的生活陷入混亂； 當(dāng)一個(gè)區(qū)域的數(shù)據(jù)中心網(wǎng)絡(luò)故障，能讓遍布五大洲的企業(yè)同時(shí)癱瘓，我們必須承認(rèn)：云計(jì)算在帶來便利的同時(shí)，也創(chuàng)造了前所未有的系統(tǒng)性脆弱性。

更何況，當(dāng)三家美國公司控制全球63%的云基礎(chǔ)設(shè)施，這已經(jīng)不僅是技術(shù)問題，更是地緣政治風(fēng)險(xiǎn)和數(shù)字主權(quán)挑戰(zhàn)。單一供應(yīng)商的便利性與全球性的脆弱性構(gòu)成了一個(gè)危險(xiǎn)的悖論。

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

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

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

在脆弱性中構(gòu)建韌性，在依賴與集中化中保持獨(dú)立自主 —— 這不是技術(shù)選擇，而是生存哲學(xué)。 us-east-1 還會(huì)再次故障 —— 不是是否，而是何時(shí)。所以真正的問題是：下一次故障發(fā)生時(shí)，你是否已經(jīng)準(zhǔn)備好了？

小廣告

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

老馮的 允許你在不依賴 DNS，S3，IAM，Docker，K8S，等外部系統(tǒng)的前提下，在物理機(jī) / 虛擬機(jī)裸 Linux 環(huán)境上一鍵部署企業(yè)級(jí)的 PostgreSQL RDS 集群，自帶 高可用，PITR，負(fù)載均衡，監(jiān)控系統(tǒng)， 424 個(gè) PG 擴(kuò)展，以及獨(dú)家 Supabase 支持 。軟件開源免費(fèi)，本地優(yōu)先 —— 即使斷網(wǎng)，也能持續(xù)擴(kuò)容，在云上云下運(yùn)行至地老天荒。

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

References

[1] Justin Garrison 在2023年離職時(shí)就預(yù)言會(huì)有更多大規(guī)模故障:https://justingarrison.com/blog/2023-12-30-amazons-silent-sacking/
[2]亞馬遜人才流失終于導(dǎo)致 AWS 走向衰落:https://www.theregister.com/2025/10/20/aws_outage_amazon_brain_drain_corey_quinn/
[3]Cherry Servers 在 2025 年發(fā)布的研究: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/

專欄：云計(jì)算泥石流

云故障

云資源

下云記