AWS 故障揭示雲端服務脆弱性 全球企業損失料達數十億美元

Amazon Web Services 位於美國維珍尼亞州北部的 US-EAST-1 數據中心於 2025 年 10 月 20 日發生重大故障,全球超過 1,000 個網站及應用程式服務中斷超過 12 小時。DynamoDB 域名系統解析問題觸發連鎖效應,影響 EC2 虛擬伺服器啟動及網絡負載平衡器健康檢查系統。網絡監測公司 Catchpoint 行政總裁估計,事故造成的財務損失將達數十億美元(折合約數百億港元)。

Amazon Web Services 位於美國維珍尼亞州北部的 US-EAST-1 數據中心於 2025 年 10 月 20 日發生重大故障,全球超過 1,000 個網站及應用程式服務中斷超過 12 小時。DynamoDB 域名系統解析問題觸發連鎖效應,影響 EC2 虛擬伺服器啟動及網絡負載平衡器健康檢查系統。網絡監測公司 Catchpoint 行政總裁估計,事故造成的財務損失將達數十億美元(折合約數百億港元)。

 

核心服務故障引發全球連鎖反應

AWS 於太平洋時間 10 月 20 日凌晨 12 時 26 分確認 DynamoDB 服務端點域名系統解析問題導致事故,並於凌晨 2 時 24 分完成初步修復。US-EAST-1 數據中心建於 2006 年,作為 AWS 全球最早及最繁忙的雲端運算樞紐,處理全球約 35% 至 40% 的流量。眾多服務依賴這個核心區域進行身份驗證、元數據管理及應用程式介面查詢,單一區域的故障迅速波及全球各地的應用程式。

受影響服務包括社交平台 Snapchat、遊戲平台 Roblox 及 Fortnite、通訊應用程式 Signal、加密貨幣交易所 Coinbase、設計工具 Canva 以及人工智能搜尋工具 Perplexity。英國多家銀行如 Lloyds Bank、Barclays 及 Bank of Scotland 客戶無法登入帳戶,英國政府稅務機關 HMRC 網站亦無法連接。Amazon 自身的購物網站、Prime Video 及 Alexa 智能裝置亦出現服務降級。

 

修復過程暴露雲端架構深層問題

AWS 解決 DynamoDB 域名系統問題後服務開始恢復,但小部分內部子系統持續受損。負責啟動 EC2 實例的內部子系統依賴 DynamoDB 因而出現障礙,Amazon 無法啟動新的虛擬伺服器實例。網絡負載平衡器健康檢查系統隨後亦受影響,Lambda、DynamoDB 及 CloudWatch 等多項服務出現網絡連接問題。

AWS 於上午 9 時 38 分恢復網絡負載平衡器健康檢查,但為協助修復工作暫時限制部分操作,包括 EC2 實例啟動、通過 Lambda 事件源映射處理 SQS 佇列以及異步 Lambda 調用。事故高峰期間超過 75 項服務受影響,包括 Amazon SageMaker、Redshift、Bedrock、Elastic Load Balancing、EventBridge 及 VPC Transit Gateway。AWS 於下午 3 時 01 分令所有服務恢復正常運作,問題在解決 DynamoDB 故障後仍持續超過 12 小時。

 

企業依賴單一雲端供應商風險顯現

部分 AWS 功能如全球帳戶管理、身份及存取管理、某些控制應用程式介面甚至複製端點均由 US-EAST-1 提供服務,即使企業在歐洲運行工作負載,當這些服務故障或速度極慢時,歐洲的工作負載亦可能受影響。多名 Reddit 用戶抱怨 AWS 核心架構過度依賴 US-EAST-1,許多客戶亦依賴該數據中心。

2024 年調查顯示,76% 全球受訪者在 AWS 上運行應用程式,48% 開發人員使用其服務。市場研究機構 Gartner 數據顯示,AWS 於 2024 年佔全球雲端市場 30% 市場佔有率,Microsoft 及 Google 分別佔 20% 及 13%。雲端安全專家表示類似故障通常源於配置更新錯誤,或未能妥善監控配置、憑證等的到期時間。

專家警告雖然公眾傾向關注購物、娛樂或通訊服務中斷,但隱藏威脅在於薪資處理等關鍵功能。大部分薪資系統現時採用雲端架構,依賴第三方基礎設施處理時間追蹤、數據處理及款項分發。當 AWS 等平台故障時薪金可能無法正確計算、準時處理或完全無法發放。是次事故屬全球性而非單一國家,意味全球員工可能面臨薪金延誤、遺失或錯誤的問題。

 

商業應對策略與多雲架構部署

AWS 服務信用額很少涵蓋實際停機成本,企業應建立自身彈性機制而非完全依賴供應商保證。雖然 AWS 表示服務已恢復,但事故證明僅將應用程式分散到 AWS 內不同可用區域或地區並不足夠。企業需要更強大的災難恢復策略,例如溫備用系統或採用多個雲端供應商。

網絡安全專家建議企業採用多雲架構分散風險。多雲災難恢復策略透過在不同雲端供應商提供的多個雲端環境中複製業務系統,確保數據及應用程式可用性,降低依賴單一雲端供應商的技術基礎架構風險。透過在多個雲端平台分散資源企業可減輕單點故障風險。當一個雲端出現故障時流程可自動故障轉移到另一雲端環境,確保服務持續可用並將停機時間降至最低。

多雲災難恢復策略允許企業自訂單一雲端供應商無法提供的方案。多個公共雲端供應商(AWS、Google、Azure)同時故障的可能性極低。透過為跨多個雲端的工作負載設計災難恢復計劃,企業能消除單點故障風險,固有地降低數據遺失及停機風險。擁有全球業務的企業需確保能遵守當地數據及私隱法律,包括歐盟一般數據保障規例。多雲方法提供靈活性,讓企業在一個地區選擇一家公共雲端供應商,並為限制較嚴格的地區如德國選擇另一家。

雲端災難恢復利用雲端平台的冗餘架構提供高可用性及可靠性。數據通常跨多個地理區域複製,確保當一個位置出現故障時可從另一位置存取數據副本。這種地理多樣性可防範電力中斷、洪水或地震等局部災難。選擇可靠且安全的雲端供應商,提供災難恢復所需的基礎架構及服務。考慮數據冗餘、可擴展性、合規認證及地理多樣性等因素,確保彈性及可用性。

 

歷史教訓與未來趨勢

US-EAST-1 並非首次發生重大故障。2017 年一次 US-EAST-1 故障令大部分互聯網癱瘓,2021 年事故仍被引述為 AWS 歷史上最大規模中斷,2023 年錯誤亦令多項服務離線。2024 年 7 月網絡安全公司 CrowdStrike 的錯誤軟件更新影響 Microsoft Windows 系統,暴露全球科技基礎設施的脆弱性。

網絡安全公司 NymVPN 的 Chief Digital Officer 表示,互聯網最初設計為去中心化及具彈性,但今天大量網絡生態系統集中在少數雲端區域。當其中一個區域出現故障時影響立即且廣泛。作為超過 90% 財富 100 強公司雲端服務的關鍵推動者,AWS 在企業資訊科技營運中扮演核心角色。

開放雲端聯盟高級顧問表示,是次大規模 AWS 故障是過度依賴兩個主要雲端供應商風險的生動提醒,大部分人或多或少都感受到這次故障的影響。除非有重大規模要求或監管複雜性,否則客戶應考慮選擇並承諾只使用一個雲端供應商,並利用他們提供的所有服務來提高業務價值。雲端技術不斷變化,使用多個雲端進行災難恢復正成為各種規模企業更常見且重要的策略。

企業需要審視現有雲端策略的假設。審核所有依賴 US-EAST-1 的系統並將實際恢復時間與預期進行比較。將彈性建立在數據平面上,例如使用全球分散式域名系統如 Amazon Route 53 自動將流量重新路由到健康區域。避免依賴控制平面操作的故障轉移機制,因為它們可能在故障期間失效。災難恢復即服務提供雲端託管的故障轉移,確保能快速從勒索軟件、故障或天災中恢復。將停機時間從數天縮短至數分鐘,防止數據遺失並消除昂貴的次要數據中心需求。

 

來源:NBC