亞馬遜云崩完，微軟云崩！當全球第二大云“摔了一跤”：Azure 宕機背后的配置風險與警示

亞馬遜云崩完，微軟云崩！當全球第二大云“摔了一跤”：Azure 宕機背后的配置風險與警示

首先來回顧一下10天前的aws事故。

AWS事故簡介

此次事件始于10月19日 PDT23:48，結束于10月20日 PDT14:20。在此過程中，客戶應用的影響大致可分為三個不同階段：

首先，10月19日23:48至10月20日02:40，Amazon DynamoDB 在美國東部（弗吉尼亞北部，us-east-1）區域的 API 錯誤率顯著升高。

其次，10月20日05:30至14:09，網絡負載均衡器（Network Load Balancer，NLB）在該區域出現部分負載均衡實例連接錯誤率上升的情況（源于 NLB 集群的健康檢查失敗）。

第三，10月20日02:25至10:36，新的 EC2 實例啟動均告失敗；盡管從10:37開始實例啟動逐步恢復成功，但部分新啟動實例出現了網絡連接問題，直到13:50才完全解決。

事故原因：此次事件是由該服務的自動域名系統 (DNS) 管理系統中一個潛在缺陷引發的，該缺陷導致 DynamoDB 的終端節點解析失敗。

                                                           官方事故報告： https://aws.amazon.com/cn/message/101925/

這場持續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 的單點依賴。

微軟云Azure事故

2025 年 10 月 29 日，微軟 Azure 在全球范圍內發生大規模宕機，持續近 9 小時。受影響的不僅包括微軟自家核心服務（Office 365、Xbox Live、Copilot 等），還波及航空、醫療、零售等多個行業。

Downdetector 的統計顯示，短時間內全球上千起用戶報告，堪稱一次“互聯網半邊天的停擺”。

更具戲劇性的是，這一事故發生在微軟發布 2026 財年 Q1 財報的前夕，而財報中 Azure 云業務收入同比增長 40%，形成了鮮明反差。

根本原因

根據微軟初步調查報告：

• ? 觸發點 ：Azure Front Door（全球內容分發與應用加速服務）中一次 意外的租戶配置更改 。

• ? 問題機制 ：該更改引入了無效/不一致的配置狀態，導致大量 AFD 節點無法正常加載。

• ? 連鎖反應 ：異常節點退出全局池，健康節點流量驟增，進一步放大了宕機范圍。

• ? 防護缺陷 ：原本應阻止錯誤部署的保護機制因軟件缺陷失效，未能攔截。

微軟隨后采取措施：凍結所有新的配置更改、回滾至“上一次已知良好配置”，并逐步恢復流量分配。

事件起因是一次無意的租戶配置變更，該變更在 Azure Front Door 內部觸發了大范圍服務中斷，影響了依賴 AFD 進行全球內容分發的微軟服務和客戶應用。

該變更引入了無效或不一致的配置狀態，導致大量 AFD 節點無法正確加載，進而引發下游服務的延遲、超時和連接錯誤。

隨著不健康節點退出全局節點池，流量分布在健康節點間變得不平衡，放大了影響，導致即使部分地區仍健康也出現間歇性可用性問題。

我們立即阻止所有新的配置更改以防止錯誤狀態進一步傳播，并開始在全球范圍內部署“上一次已知的良好配置”。

恢復過程需要在大量節點上重新加載配置，并逐步重新平衡流量，以避免節點恢復時過載。

這種分階段恢復是為了在確保系統穩定的前提下恢復規模并避免問題復發。

觸發根因追溯到租戶配置部署流程中的缺陷。

本應阻止錯誤部署的防護機制因一個軟件缺陷而失效，使該部署繞過了安全驗證。

我們已審查并立即加強驗證與回滾控制機制，以防止未來出現類似問題。

影響范圍

受影響的 Azure 服務清單幾乎覆蓋其生態半壁江山，包括：

• ? PaaS 層 ：App Service、Azure SQL Database、Databricks

• ? 安全與身份 ：Entra ID、Defender EASM、Sentinel

• ? 開發與數據 ：Container Registry、Media Services、Video Indexer

• ? 終端體驗 ：Virtual Desktop、Azure Maps、Healthcare APIs

此外，Alaska Airlines、夏威夷航空等航空公司無法在線辦理登機手續，加拿大醫療機構 Santé Québec 報告部分系統停運，甚至開源社區的 Helm 官網也一度無法訪問。

行業警示

這不是孤立事件。僅僅不到10天前，AWS因DNS自動化管理系統的罕見軟件bug，引發了持續15小時的全球性故障。兩大云巨頭占據全球超55%的市場份額，它們的接連"掉鏈子"，讓云服務集中化風險再次成為焦點。

1. 1. 集中化風險 ：少數巨頭掌控互聯網神經中樞，一次配置錯誤即可波及全球。

2. 2. 韌性不足 ：即便是頂級基礎設施，仍存在防護機制失效的可能。

3. 3. 多云與冗余 ：企業在追求云的便利與彈性時，是否也該考慮多云部署與自主可控？

AWS事故的起因： 此次事件是由該服務的自動域名系統 (DNS) 管理系統中一個潛在缺陷引發的，該缺陷導致 DynamoDB 的終端節點解析失敗。

Azure事故的起因：無意的租戶配置變更？又想到了某位偉人說的： 這個世界是個巨大的草臺班子。。。

給整個云計算行業敲響了警鐘。

云計算的魅力在于規模化與自動化，但這也意味著**“一處失誤，全球震蕩”**。對于企業用戶而言，不能只依賴 SLA 和廠商承諾，更要在架構層面設計冗余與容災。對于云廠商而言，如何在快速迭代與穩定性之間找到平衡，將是未來十年的核心挑戰。