AWS 故障官方復盤報告

今天 AWS 官方發布了 的事后復盤報告，細節比較豐富，算是少有的第一手資料。所以老馮把它翻譯成了中文，并附上解讀與評論，供大家參考。

故障公告：https://aws.amazon.com/cn/message/101925/[1]

我們希望就2025年10月19日至20日發生在美國東部弗吉尼亞北部（us-east-1）區域的服務中斷事件向您提供一些補充信息。此次事件始于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才完全解決。

DynamoDB

2025年10月19日23:48 至 10月20日02:40期間，美國東部（弗吉尼亞北部，us-east-1）區域的 Amazon DynamoDB API 錯誤率顯著升高。在此期間，所有依賴 DynamoDB 的客戶應用和其他 AWS 服務都無法與該服務建立新的連接。此次故障由 DynamoDB 服務的自動化 DNS 管理系統中的一個潛在缺陷所觸發，該缺陷導致 DynamoDB 服務端點的 IP 地址解析失敗。

AWS 許多大型服務都高度依賴 DNS 來實現無縫擴展、故障隔離與恢復、低延遲以及數據就近訪問。例如，DynamoDB 在每個區域維護著數十萬條 DNS 記錄，以管理該區域內龐大且異構的負載均衡集群。通過自動化頻繁更新這些 DNS 記錄，可以在新擴容資源上線時立即添加對應記錄，正確應對硬件故障，并高效地分配流量，優化客戶體驗。該自動化系統針對高彈性進行設計，使服務能夠從各種運行問題中快速恢復。除了提供公共區域端點以外，該系統還維護了多個 DynamoDB 的動態 DNS 端點，包括符合 FIPS 標準的專用端點、IPv6 專用端點，以及賬號級別的專屬端點。

此次問題的根本原因在于 DynamoDB DNS 管理系統中存在一個潛伏的競態條件（race condition）。該競態問題導致服務的區域端點 (dynamodb.us-east-1.amazonaws.com) 的 DNS 記錄被錯誤地清空，而自動化系統未能及時糾正這一狀況。為解釋這一情況，我們需要先介紹 DynamoDB DNS 管理系統的架構。出于高可用性的考慮，該系統分為兩個相互獨立的組件：

?DNS 規劃器（DNS Planner）：監控負載均衡器的運行狀況和容量，并定期為服務的每個端點創建新的 DNS “方案”（plan），其中包含一組負載均衡器及其權重。我們為整個區域生成統一的 DNS 方案，因為當多個端點共享資源容量時（例如公共區域端點和新推出的 IPv6 端點），統一的方案極大地簡化了容量管理和故障處理。?DNS 執行器（DNS Enactor）：被設計為幾乎無依賴，以便在任何場景下都能獨立運行恢復。DNS 執行器負責將 DNS 方案應用到 Amazon Route 53 服務中。為增強彈性，我們在三個不同的可用區（AZ）中各部署了一個完全獨立運行的 DNS 執行器實例。每個 DNS 執行器都會監聽新的方案生成，并通過 Route 53 事務嘗試將當前方案替換為新方案。這種機制可確保即使有多個 DNS 執行器并發地更新同一端點，也能讓該端點應用一致的方案。

此次競態條件源于兩個 DNS 執行器之間一次極為罕見的交互。正常情況下，DNS 執行器獲取最新方案后，會依次將其應用到服務的各個端點上。這個過程通常非常迅速，能夠確保 DNS 狀態保持最新。在開始應用新方案之前，DNS 執行器會一次性檢查其即將應用的方案是否比之前的方案更新。在遍歷端點列表應用方案的過程中，如果某個 DNS 執行器在更新某端點時被另一執行器暫時阻塞，它將反復重試直到成功。

在本次事件發生前夕，一臺 DNS 執行器在更新多個端點時遭遇了異常高的延遲，不得不對幾個 DNS 端點進行了多次重試。當它以緩慢的速度逐步處理這些端點時，又發生了幾件事：首先，DNS 規劃器繼續運行并生成了多代更新的方案；其次，另一臺 DNS 執行器開始應用其中一個較新的方案，并快速地完成了對所有端點的更新。這一系列操作在時間上的巧合觸發了那個潛伏的競態條件。

當第二臺（較快的）DNS 執行器完成端點更新后，它啟動了方案清理進程，該進程會刪除所有比剛應用方案“陳舊得多”的舊方案。恰在此時，第一臺（較慢的）DNS 執行器終于將其早已過期的方案應用到了 DynamoDB 的區域主端點，結果把較新的方案覆蓋掉了。由于該執行器在開始應用時所做的新舊方案校驗因長時間延遲而變得過期無效，所以未能阻止舊方案覆蓋新方案。隨后，第二臺執行器的清理進程檢測到這個過期方案（相對于它剛應用的方案已過多代），便將其刪除。隨著這一方案被刪除，該區域端點的所有 IP 地址也從 DNS 記錄中被移除了。而且由于活動方案被移除，系統陷入不一致狀態，導致之后無論哪臺 DNS 執行器都無法再成功應用新的方案。最終，我們不得不通過人工干預來糾正這一狀況。

當上述故障于 PDT 時間10月19日23:48 出現后，所有通過公共端點連接美國東部（弗吉尼亞北部，us-east-1）區域 DynamoDB 服務的系統立刻遭遇 DNS 解析失敗，無法連接至 DynamoDB。這不僅影響了客戶流量，也影響了依賴 DynamoDB 的 AWS 內部服務流量。啟用了 DynamoDB 全局表（Global Tables）的客戶雖然能夠對其他區域的副本表成功發出請求，但與 us-east-1 區域對應副本之間出現了嚴重的復制延遲。相關 AWS 服務的工程團隊在事故發生后立即投入調查。到10月20日00:38，我們的工程師確認 DynamoDB 的 DNS 狀態正是這次中斷的根源。到了01:15，通過實施一系列臨時緩解措施，我們恢復了部分內部服務對 DynamoDB 的連接，并修復了關鍵的內部工具，為后續全面恢復掃清了障礙。到02:25，所有 DynamoDB 服務的 DNS 信息均已恢復正常，全球表的所有副本也在02:32 前完成了追趕同步。隨著 DNS 緩存逐步過期，客戶在02:25至02:40之間重新能夠解析 DynamoDB 區域端點并建立連接。至此，與 DynamoDB 服務相關的主要中斷階段宣告結束。

Amazon EC2

2025年10月19日23:48 至 10月20日13:50，在美國東部（弗吉尼亞北部，us-east-1）區域內，客戶遇到了 EC2 API 錯誤率上升、延遲增加以及新實例啟動失敗的情況。在整個事件持續期間，故障發生前已運行的 EC2 實例始終保持正常，未受到影響。在02:25解決 DynamoDB DNS 問題后，客戶啟動新 EC2 實例依然出現大量錯誤。恢復工作于10月20日12:01展開，至13:50 EC2 服務全面恢復。在此期間，新的實例啟動請求要么失敗并返回“請求超過限制”（request limit exceeded）錯誤，要么失敗并返回“資源不足”（insufficient capacity）錯誤。

要理解這一問題，我們需要先介紹幾個與 EC2 實例啟動以及新實例網絡配置相關的內部子系統。第一個子系統是 Droplet Workflow Manager (DWFM)，負責管理 EC2 用于承載實例的所有底層物理服務器——這些物理服務器我們稱之為 “droplet”。第二個子系統是 網絡管理器（Network Manager），負責管理網絡狀態并將網絡配置傳播至所有 EC2 實例和網絡設備。

每個 DWFM 在每個可用區內管理著一組 droplet，并為每個 droplet 維護一個租約（lease）。通過租約，DWFM 可以跟蹤 droplet 的狀態，確保無論是由 EC2 API 發起的操作，還是由實例操作系統內部觸發的關機或重啟操作，都能夠在整個 EC2 系統中正確反映狀態變化。為了維持這些租約，每臺 DWFM 主機需要每隔幾分鐘就與其管轄的每個 droplet 進行一次狀態檢查。

從10月19日23:48開始，上述 DWFM 的狀態檢查開始失敗——由于該過程依賴 DynamoDB 而 DynamoDB 當時不可用，檢查無法完成。雖然這并未影響任何正在運行的 EC2 實例，但對于任何涉及實例狀態變更的新操作，droplet 在執行前必須先與 DWFM 建立新的租約。于是，在10月19日23:48至10月20日02:24這段時間內，EC2 集群中 DWFM 與 droplet 之間的租約開始陸續因超時而失效。

02:25（DynamoDB API 恢復）之后，DWFM 開始在整個 EC2 集群中重新與各 droplet 建立租約。由于任何沒有有效租約的 droplet 都不會被視為新實例啟動的可用候選資源，因此此時 EC2 API 針對新的啟動請求返回“資源不足”的錯誤。DWFM 雖然著手重新為集群中的 droplet 建立租約，但由于 droplet 數量龐大，重新建立租約所需時間過長，以至于還未完成就再次超時。這使得大量重試操作排隊等待處理。此時，DWFM 陷入了一種“擁塞崩潰”（congestive collapse）的狀態，無法繼續推進租約恢復進程。

鑒于此前沒有針對這種情況的現成應急方案，工程師在處理 DWFM 問題時格外謹慎。嘗試了多種緩解步驟后，團隊于04:14采取措施：一方面限制新的任務進入隊列（對請求進行了限流），另一方面選擇性地重啟了部分 DWFM 主機。重啟操作清除了 DWFM 隊列，縮短了處理時間，并使 droplet 租約得以及時重新建立。到05:28，DWFM 已經與 us-east-1 區域內所有 droplet 恢復租約，新實例啟動也再次開始成功。不過，由于我們之前實施的請求限流措施尚未完全解除，許多啟動請求依然會遇到“請求超過限制”的錯誤。

當一個新的 EC2 實例啟動時，一個名為網絡管理器（Network Manager）的系統會將網絡配置下發給該實例，以使其能夠與同一虛擬私有云（VPC）內的其他實例、其他 VPC 的網絡設備以及互聯網進行通信。在05:28（DWFM 恢復后不久），網絡管理器開始向新啟動的實例以及事件期間曾經終止過的實例分發更新的網絡配置。然而，由于之前 DWFM 故障導致網絡配置傳播事件積壓，N. Virginia 區域的網絡管理器累積了大量等待處理的網絡狀態更新。06:21起，網絡管理器在處理這些積壓的網絡更新時出現了顯著的延遲。盡管新的 EC2 實例可以成功啟動，但由于網絡狀態傳播延遲，這些實例無法及時獲得必要的網絡連接。工程師通過降低網絡管理器的負載來縮短網絡配置的傳播延遲，并采取了額外措施加速恢復。到10:36，網絡配置傳播已恢復正常，新啟動的 EC2 實例也重新具備了正常的網絡連通性。

EC2 服務恢復的最后一步是解除此前為減輕各子系統負載而實施的請求限流措施。隨著 API 調用頻率和新實例啟動請求逐步恢復正常，工程師于11:23開始逐步放寬并最終移除這些限流限制。至13:50，所有 EC2 API 和新實例啟動均恢復正常運行。

網絡負載均衡器（NLB）

新實例網絡狀態傳播延遲的問題同樣波及到了 網絡負載均衡器（Network Load Balancer，NLB） 服務及其他使用 NLB 的 AWS 服務。在10月20日05:30 至 14:09期間，美國東部（弗吉尼亞北部，us-east-1）區域內部分客戶的 NLB 出現了連接錯誤率上升的現象。NLB 基于高度可擴展的多租戶架構構建，為用戶提供負載均衡訪問端點，并將流量路由至后端目標（通常是 EC2 實例）。該架構還包含一個獨立的健康檢查子系統，會定期對 NLB 體系結構內的所有節點執行健康檢查，并將任何被判定為不正常的節點移出服務。

在此次事件期間，NLB 的健康檢查子系統開始記錄到大量健康檢查失敗。原因在于健康檢查子系統將新啟動的 EC2 實例納入服務時，這些實例的網絡配置尚未完全傳播。因此，即使相關 NLB 節點和后端目標本身是健康的，這些實例的健康檢查仍會失敗。結果就是健康檢查狀態在“失敗”和“正?！敝g來回波動：一次檢查失敗，該節點及其目標就被從 DNS 中移除；下一次檢查恢復正常時，它們又被重新加入服務。

我們的監控系統在06:52檢測到了這一異常，工程師隨即展開了補救工作。健康檢查結果的反復“閃爍”使健康檢查子系統負載加重，導致檢查延遲，并觸發了可用區級別的自動 DNS 故障切換（AZ Failover）。對于跨多個可用區部署的負載均衡器而言，這意味著部分可用區的負載均衡節點被判定故障而下線。如果剩余的可用容量不足以支撐應用負載，就會出現客戶連接錯誤。09:36，工程師手動停用了 NLB 的自動健康檢查故障切換功能，讓所有健康的 NLB 節點和后端目標重新回到服務中。這一措施消除了受影響負載均衡器的連接錯誤。在 EC2 服務完全恢復后，我們已于14:09重新啟用了 NLB 的自動 DNS 健康檢查故障切換功能。

其他 AWS 服務

在10月19日23:51 至 10月20日14:15期間，us-east-1 區域的客戶在使用 AWS Lambda 函數時遇到了 API 錯誤和延遲問題。最初，由于 DynamoDB 區域端點不可用，Lambda 函數的創建和更新請求無法完成，SQS/Kinesis 事件源的處理出現延遲并伴隨調用錯誤。到02:24，除 SQS 隊列拉取外的 Lambda 服務功能均已恢復；SQS 隊列處理仍然受阻，是因為負責輪詢 SQS 隊列的內部子系統發生故障且未能自動恢復。我們于04:40修復了該子系統，并在06:00前清理完所有消息積壓。但在07:04左右，受 NLB 健康檢查故障影響，一部分 Lambda 內部系統實例被異常終止，導致計算容量不足。由于 EC2 實例啟動尚未完全恢復，我們對 Lambda 事件源映射和異步調用實施了限流，以優先保障對延遲敏感的同步調用。到11:27，我們恢復了足夠的運行容量，錯誤率開始下降。隨后我們逐步解除限流，并于14:15之前處理完所有積壓任務，Lambda 服務恢復正常。

在10月19日23:45 至 10月20日14:20期間，美國東部（弗吉尼亞北部，us-east-1）區域的 Amazon Elastic Container Service（ECS）、Amazon Elastic Kubernetes Service（EKS）和 AWS Fargate 服務均出現了容器啟動失敗和集群擴容延遲的問題。這些服務均已于14:20恢復正常。

在10月19日23:56 至 10月20日13:20期間，使用 Amazon Connect 的客戶在處理呼叫、聊天和工單（Cases）時遇到了顯著的錯誤提升。DynamoDB 區域端點恢復后，Amazon Connect 的大多數功能已經恢復，不過客戶在05:00之前發送聊天消息時仍然會遇到錯誤。從07:04開始，由于 NLB 故障以及 Lambda 函數執行錯誤，客戶在接入新來電、處理聊天、任務、郵件和工單時再次出現大量錯誤。具體來說：呼入電話的主叫方會遇到忙音、錯誤消息或連接失敗；由座席發起的外呼電話（無論人工或通過 API）均無法接通；即使已接聽的電話也可能出現提示音播放失敗、無法路由至座席或通話中斷等問題。此外，座席在處理聯絡時會遇到錯誤，一些座席甚至無法登錄?？蛻粼谡{用 Connect 提供的 API 或執行聯系搜索時同樣碰到錯誤。實時和歷史儀表板的數據更新也出現延遲，數據湖的數據更新被延后，我們將在10月28日之前補齊所有數據。隨著 Lambda 函數調用錯誤率的恢復下降，到13:20 Amazon Connect 服務的可用性已經恢復。

在10月19日23:51 至 10月20日09:59期間，AWS 安全令牌服務（AWS Security Token Service，STS）在 us-east-1 區域出現了 API 調用錯誤率上升和延遲增加的情況。DynamoDB 區域端點恢復后，STS 已于01:19恢復正常。但在08:31 至 09:59期間，受到 NLB 健康檢查故障的影響，STS API 錯誤率和延遲再次升高。到09:59，STS 從 NLB 健康檢查故障中恢復，服務恢復正常運行。

在10月19日23:51 至 10月20日01:25期間，通過 IAM 用戶登錄 AWS 管理控制臺的客戶遇到了較高的身份驗證失敗率，原因是弗吉尼亞北部（us-east-1）區域的 DynamoDB 故障導致 IAM 驗證服務受損。將 AWS IAM 身份中心（原 AWS SSO）配置在 us-east-1 區域的客戶也無法通過身份中心完成登錄。使用 Root 用戶憑證登錄，或使用指向 signin.aws.amazon.com 的身份聯合登錄方式嘗試訪問其他區域 AWS 管理控制臺的客戶，同樣遇到了錯誤。隨著 DynamoDB 區域端點在01:25重新可用，IAM 登陸服務恢復正常。

在10月19日23:47 至 10月20日02:21期間，客戶在 us-east-1 區域創建、修改 Amazon Redshift 集群或對現有集群執行查詢時遇到了 API 錯誤。Redshift 查詢處理依賴 DynamoDB 來讀寫集群的元數據。隨著 DynamoDB 區域端點的恢復，Redshift 查詢操作得以恢復，到02:21 時，Redshift 客戶已經可以成功查詢集群并創建或修改集群配置。然而，一些 Redshift 計算集群在 DynamoDB 恢復后仍然處于受損不可用狀態。原因是：當集群節點憑證過期且未被及時刷新時，Redshift 自動化會嘗試啟動流程，用新的 EC2 實例替換底層故障節點。但由于當時 EC2 實例無法啟動，這些替換流程被阻塞，集群因此卡在“修改中”（modifying）狀態，無法處理查詢。我們的工程師在06:45采取措施，阻止替換流程隊列繼續增長。當 Redshift 集群從14:46開始陸續成功啟動新的替換實例后，積壓的替換流程也開始逐步消化。到10月21日04:05，AWS 運維人員已完成對所有受此問題影響集群的可用性恢復。

此外，在10月19日23:47 至 10月20日01:20期間，由于 Redshift 的一個缺陷——其在解析用戶組時調用了 us-east-1 區域的 IAM API——導致所有 AWS 區域的 Amazon Redshift 客戶都無法使用 IAM 用戶憑證執行查詢。在此期間 IAM 服務的故障使 Redshift 無法完成這些查詢。使用 Redshift 本地用戶憑證連接集群的客戶不受該問題影響。

其他一些依賴 DynamoDB、新 EC2 實例啟動、Lambda 執行和 Fargate 任務啟動的 AWS 服務（例如 Amazon Managed Workflows for Apache Airflow、Outposts 生命周期管理操作以及 AWS Support Center 等）在 us-east-1 區域也受到了此次事件的影響。

結語

對于此次事件給我們的客戶帶來的影響，我們深表歉意。我們在高可用服務運營方面一直保持著良好的記錄，但我們深知我們的服務對于客戶、客戶的應用及終端用戶乃至其業務而言有多么關鍵。這次事件對許多客戶產生了重大影響，我們將盡最大努力從中汲取經驗教訓，并以此進一步提升服務的可用性和可靠性。

老馮評論

10-20 日，AWS 出了一場讓人嘆為觀止的級聯雪崩故障 —— 一個 DNS 服務的設計缺陷被級聯放大到影響半個互聯網。老馮昨天也已經 。

這次故障是一場讓人嘆為觀止的級聯雪崩，一個區域內的 DNS 服務的設計缺陷被級聯放大到影響半個互聯網。毫無疑問是一次架構哲學的大失敗。接下來，讓我們一起看一下 AWS 在此次故障中的三個問題。

DNS 問題

這份故障報告披露了 DNS 故障的原因 —— DNS 管理控制面的設計缺陷。其實這是一個相當標準的數據庫事務問題，DNS 更新踩踏完全可以在元數據庫層面用事務機制來規避 —— 當然 AWS 可能會主張他們的規模會有這樣那樣的問題沒法實現操作的原子性，這也就算了；

但最離譜的是，一個執行器把另一個執行器的計劃給清理了，另一個執行器的合理行為是 —— 執行計劃都沒了就別執行了 —— 而不是直接把 DNS 解析給刪掉。然后，這個 BUG 還卡住了后續的 DNS 計劃更新，導致最后只能依賴人工介入處理。

老實說看到這個原因，老馮真心覺得匪夷所思：都知道 DNS 是基礎中的基礎，更新 DNS 的服務竟然會有如此低級的 BUG ？任何并發程序設計都要考慮的競態條件處理，竟然實現的如此粗糙？這種失智行為讓人懷疑這些代碼到底有沒有經過測試？是不是用 Vibe Coding 糊出來的東西？

另一個槽點是幾乎是整個運維圈都在吐槽的 —— 定位到是 DNS 的問題用了 40 分鐘，手工修復這個問題又用了 37 分鐘，最后又是 70 分鐘才恢復正常，一個 DNS 故障處理總共歷時 2小時 52 分鐘，對于 AWS 這樣的云廠商來說，這個戰績可謂是慘不忍睹了 —— 引用 Corey Quinn 的評論就是 —— “當你炒掉最優秀的工程師時，就別驚訝云廠商會忘記 DNS 是怎么工作的” 。

EC2 問題

第二場次生故障是 EC2 Droplet 租約系統對 DynamoDB 的高度依賴與“擁塞崩潰”。

大體上來說，AWS 把 DynamoDB 當作 Consul，etcd 這樣的 DCS 來用，存儲各種核心系統的云數據，比如 EC2 的租約。AWS 把物理機叫做 “Droplet” （液滴），管理這些物理機的管控組件叫做 DWFM （液滴工作流管理者）。 DWFM 需要存儲在 DynamoDB 里面的租約才可以執行管理操作，但是現在 DynamoDB 掛了，DWFM 的租約一過期，就失去管理權限了。

據稱，這次故障并沒有影響已有 EC2 的運行，影響的是EC2的管理操作，即管控面 。在故障的第一階段 —— DynamoDB 下線階段，EC2 表現為新啟動 EC2 提示 “資源不足”，因為 DWFM 都因為丟失租約而失去權限。在故障的第二階段，DynamoDB 重新上線，大量的 DWFM 爭搶著去申請新的租約，這就直接把 DynamoDB 給打爆了。

按理說，AWS DynamoDB 號稱可以自動彈性伸縮，但是現在底下的彈性計算 EC2 管控服務又處于故障狀態，沒有辦法創建新的 EC2 ，于是就卡死了。 AWS 的解決辦法是不讓用戶新創建 EC2，然后祭出了 重啟大法。把 DWFM 分批重啟了一遍清空了重試隊列。

這個部分讓老馮非常疑惑的點有：重試似乎沒有指數退避擁塞控制機制？還是說根本沒有重試前超時取消的機制？難道連個斷路器都沒有嗎？當然，要說最滑稽的，應該是 —— “鑒于此前沒有針對這種情況的現成應急方案，工程師在處理 DWFM 問題時格外謹慎。”

通常來說，重啟大法能解決 90% 的問題，但是重啟 DWFM （都不是重啟物理機）這個決定，AWS 團隊花了 100 分鐘才拍版決定下來。然后重啟后又花了 74 分鐘才恢復過來，這個決斷能力與擔當實在是過于拉胯了。

NLB 故障

當 EC2 開始恢復的時候，網絡負載均衡器 NLB 又開始出問題了。這又重新導致 元數據庫 DynamoDB，CloudWatch 監控，以及 Lambda 執行引擎出現網絡連接問題。

因為網絡配置沒有及時下發，所以根據 NLB 的健康檢查規則，就會將新節點從服務列表中移除。AWS 通過停用 NLB 的自動健康檢查故障切換功能解決了這個問題。從 6:52 檢測到問題，到 9:36 手工停用健康檢查 —— 兩個半小時的決斷時間。

當然，DynamoDB，EC2，NLB 的故障其實還引發了許多服務的次生故障，比如 AWS 自己的工單支持系統，STS，IAM，Redshift，等等等等。這里特別提一下 IAM ，之前 ，以及 ，都與身份認證這項基礎服務有關。而 IAM 是使用 DynamoDB 存儲身份認證策略的，因此在 23:51 - 01:25 這94分鐘里是受到影響的。這里 AWS 對IAM 故障輕描淡寫一筆帶過，但其實很有可能是 DynamoDB 故障擴散到 142 項服務的關鍵路徑。

老馮感想

有 AWS 的客戶在事故發生后和老馮吐槽 —— 看到這個故障處理的過程，他對 AWS 幻滅了，原來光鮮亮麗的云計算一哥也是草臺班子。 當然，草臺班子也有層次之分，相比某些云廠商諱莫如深，故障后裝死，AWS 肯在故障事后公開技術細節和不足，這份坦誠還是難能可貴的。

老馮認為，云廠商的核心資產不僅是服務器和骨干網絡，更是經驗豐富的專家們。但對于云廠商來說，這些老專家是成本中心，他們的水平沒法體現在財報里。因此在過去幾年的裁員中，很大一部分精英都流失了，機構的記憶也隨之離去。留下的新人已經不再知道老系統的隱秘依賴關系，再加上 “75%的代碼由 AI 生成” ，最終導致工程團隊缺乏診斷復雜級聯故障的直覺，以及在危急關頭拍版決斷的能力，最終導致如此拉胯的響應表現。

老馮覺得，規模帶來的復雜度已經開始反噬云廠商了。縱觀最近幾年的云故障，因為機房起火斷電之類不可抗力事件的并不多，反而那些超大規模故障幾乎都是因為管控軟件缺陷，人為配置操作失當導致的。

額外復雜度是架構設計中的大敵，有時候，簡簡單單在數據中心里租倆機柜，跑幾套數據庫 + Docker 跑跑應用這種經典的架構，異地對象存儲備份一下，足夠絕大多數企業一路干到 IPO 了。如果你的問題本質復雜度如果沒有 Amazon Google 的規模，卻非要使用他們的基礎架構 —— 那么成本可不僅是高昂的云上財務開銷，還有架構復雜度帶來的風險 —— 而這幾次大故障毫無疑問的證實了這一點。

當一家云廠商內部的一條 DNS 記錄損壞，就能讓全球數千萬用戶的生活陷入混亂； 當一個區域的數據中心網絡故障，能讓遍布五大洲的企業同時癱瘓，老馮覺得：云計算在帶來便利的同時，也創造了前所未有的系統性風險。 而這可不是互聯網誕生的初衷！

要想解決這個問題，也許最后還是需要監管介入。像當年 FCC 拆分 AT&T 一樣，拆分幾大云廠商。

References

[1]: https://aws.amazon.com/cn/message/101925/

專欄：云計算泥石流

云故障

云資源

下云記