大當機！PayPay、Niconico全停擺，為什麼災情這麼慘？企業該如何防範？

AWS CloudFront 全球故障波及 PayPay 等日方服務 專家示警：安全防護反淪「單點故障」

雲端服務龍頭亞馬遜網路服務（AWS）於昨（16）日傍晚發生全球性大規模故障，導致日本國內多項主流網路服務陷入癱瘓。受影響的服務包括行動支付 PayPay、社群平台 note、影音串流網站「NicoNico生放送」以及 Hatena 部落格等，許多用戶在相同時間段內面臨無法連線或系統不穩定的狀況。

根據 AWS 官方說明，此次異常起因於內容傳遞網路（CDN）服務「Amazon CloudFront」中，用以連接私有系統的「VPC Origins」功能發生故障。官方指出，若將系統架構調整為不使用該功能，即可避開錯誤。這顯示本次事件並非東京區域的伺服器集體硬體毀損，而是連結使用者與應用程式的「主要入口」部分失效。

資深雲端架構專家指出，本次出問題的「VPC Origins」本是為了提升資安而設計的防護機制。企業通常會將應用程式負載平衡器（ALB）或虛擬主機（EC2）等核心系統部署於網際網路無法直接存取的私有網路中，並將 CloudFront 作為唯一的通信入口。此舉能有效隱蔽源站伺服器，降低遭遇惡意攻擊或設定錯誤的風險。

然而，這種為了安全而封鎖所有直接連線的作法，也帶來了新的風險。一旦作為唯一入口的 CloudFront 專屬功能發生故障，企業也將同時失去所有備用路徑。這種為了提高安全性而收緊入口的策略，諷刺地讓該防護點成為系統邏輯上的「單點故障（Single Point of Failure）」。

專家強調，企業不應因此放棄安全防禦，關鍵在於是否在事前規劃了應急通道，例如備用 CDN、不同的源站連接機制，或是在服務中斷時能自動切換的靜態緊急網頁。

值得注意的是，這類避難通道無法在故障發生後「即興發揮」。因為臨時切換路徑涉及網域名稱系統（DNS）、電子憑證、防火牆、身分驗證及監控系統等多重設定的變更，倉促修改極易引發二次人為故障。因此，災備路徑必須日常就建置完成，並透過定期的切換測試來確保其可用性。

針對「導入多雲（Multi-cloud）架構是否就能免於此類斷線危機」的疑問，業界專家認為答案並非想像中簡單。微軟 Azure 與 Google Cloud 雖都提供多可用區（Availability Zones）及跨區域備援等機制，但兩大雲端巨頭也在合約中明示，評估並設計符合業務需求的防災架構是用戶自身的責任。

此外，雲端平台提供的特有功能（如資料庫、身分驗證、監控及生成 AI 等託管服務）越便利，企業與該平台的綁定就越深。這意味著一旦要移轉至其他雲端平台，由於服務規格的差異，企業必須重新改寫程式並重組維運流程。

真正的「多雲策略」絕非僅是簽署兩家雲端合約，而是必須確實執行資料即時同步、備用環境即時啟動、用戶流量自動切換，且維運團隊具備雙平台的操作經驗。然而，若一味追求百分之百的跨平台可移植性，將大幅犧牲開發速度與建置成本。專家建議，企業應評估各項業務中斷所帶來的衝擊程度，在「便於遷移」與「享用特定雲端功能」之間，尋求最符合商業效益的平衡點。

Author : 伴書僮

Share this

相關文章