2026 年 3 月 1 日凌晨，伊朗對杜拜的無人機攻擊讓 AWS ME-CENTRAL-1（UAE）區域的兩座資料中心同時受創，引發了大規模的服務中斷。EC2、S3 、DynamoDB 、Lambda 、RDS、Kinesis等關鍵服務停擺，整個 Region 的基礎設施幾乎崩潰。
比事件本身更值得深究的是， AWS 的官方更新報告在字裡行間所洩露的訊息：那些平時被反覆引用的雲端架構承諾，在這次事件面前一個接一個地開始鬆動。
以下問題點，全部來自 AWS 親口說出的原文。
可用區域「貌離神合」
AWS 官方反覆強調每個可用區域（Availability Zone）是獨立的實體機房，有獨立的電力供應、網路連線和冷卻系統，彼此之間的故障不會相互影響。理論上，只要你把服務跑在正常的 AZ，就應該沒事。
"The third Availability Zone (mec1-az1) continues to operate normally, though some services have experienced indirect impact due to dependencies on the affected zones."
mec1-az1 實體上沒有受損，電力正常、機器還在跑，但因為服務層面的跨 AZ 依賴，它也跟著出問題了。AZ 的物理隔離確實存在，但「服務隔離」顯然是另一回事，而 AWS 在宣傳時常常讓這兩個概念混用。
“Amazon EC2 instance launches remain throttled in the ME-CENTRAL-1 Region and will be relaxed as foundational service recovery and capacity allow.”
假設一個企業服務在 ME-CENTRAL-1 使用 Multi-AZ Auto Scaling 部署，機器分散在 az1、az2、az3。目前 az2 和 az3 已經嚴重受損，導致這兩個 AZ 機器不可用，因此流量很可能會集中到仍然正常運作的 az1。
但 AWS 目前對 az1 新增機器的動作進行限制，Auto Scaling 很可能無法啟動新的機器來補充容量，因此剩餘的機器也無法承受原本的流量負載。
壞一個沒問題，那壞兩個呢？
AWS 在報告中表示 S3 的設計只保護你抵抗單一 AZ 全損。ME-CENTRAL-1 只有三個 AZ，一次失去兩個，S3 的冗餘設計直接失效。
"Amazon S3 is a regional service and designed to withstand the total loss of a single Availability Zone while maintaining S3's durability and availability… As the second AZ became impaired, S3 error rates increased. With two Availability Zones significantly impacted, customers are seeing high failure rates for data ingest and egress."
另外AWS S3 的招牌賣點是 99.999999999% 的資料耐久性。這個數字出現在無數銷售簡報、架構討論和客戶提案之中，暗示你的資料幾乎不可能丟失。
"Full recovery of GET operations for pre-existing data remains dependent on restoring the affected infrastructure."
你金庫裡有錢，但櫃員跟你說現在不能領。耐久性（Durability）描述資料不會遺失，可用性（Availability）描述你能不能存取它，這兩個概念在客戶心中模糊化，讓人誤以為「資料不會丟」等於「隨時讀得到」。
有福同享，有難同當
雲端服務的模組化設計是重要賣點之一，每個服務獨立部署、獨立擴展、獨立容錯。客戶可以「只用 Lambda」或「只用 RDS」，服務之間理應有清楚的邊界。
"AWS Lambda, Amazon Kinesis, Amazon CloudWatch, Amazon RDS, and a number of other AWS services that were impacted by this event remain degraded. The availability of these services is dependent on the recovery of our foundational services — primarily Amazon S3 and Amazon DynamoDB — and we expect to see improvement across these services as that recovery progresses."
Lambda、Kinesis、CloudWatch、RDS⋯⋯這些在 AWS 服務目錄上看起來各自獨立的產品，骨子裡全都依賴同一批基礎服務（S3 和 DynamoDB）。
一旦基礎服務倒下，這些「獨立服務」就像牌樓一樣跟著倒。雲端服務的模組化在功能層面是真的，在故障隔離層面卻遠不如宣傳的那樣完善。
當最需要你的時候，你卻不在了
災難發生時，維運人員的第一直覺是登入 Console 或執行 CLI 來啟動備援計畫、修改 DNS 路由或是開始進行跨區域備份（如果平常沒設定）。由於兩個 AZ 的失效，導致 Console 與 CLI 工具同樣受到影響。
"We can confirm that the AWS Management Console and command line interface (CLI) are disrupted by the failure of two Availability Zones."
當你 Console 登不進去、CLI 也無法執行的時候，如果企業沒有事先準備完全自動化的容錯移轉（例如設定 Route53 failover, Terraform deploy）、或資料跨區雙向同步，手動撤離幾乎是不可能的任務。
雖然在 Well-Architeure 中的可用性支柱有提到控制平面可能會無法使用：
Consider scenarios where the primary site and its control plane are inaccessible. Verify that recovery actions can be performed independently without reliance on the primary site.
但實務上有多少企業或開發者會想的到呢？
誰叫你平常不買保險，出事不能怪我
這是整個事件報告中最微妙、也最值得深思的一點。從第一份重大更新開始，AWS 就持續在報告末尾附上同樣的段落：
"We strongly recommend that customers with workloads running in the Middle East take action now to migrate those workloads to alternate AWS Regions. Customers should enact their disaster recovery plans, recover from remote backups stored in other Regions, and update their applications to direct traffic away from the affected Regions."
這段話的弦外之音是：如果你沒有 DR 計畫，尤其是跨 Region 的 DR，那就是你的問題。而跨 Region 的備援架構代表著高昂的額外成本，在成本壓力之下，可以理解許多中小企業或開發者並未採用。
雲端就是別人的電腦
面對無人機直接攻擊資料中心這種前所未有的事件，不管是 AWS、GCP、Azure 還是任何一個雲端供應商恐怕都難以全身而退。工程師在極端惡劣的條件下持續更新狀態、嘗試軟體層面的補救方案，這份努力值得肯定。
但作為使用者，我們需要從這次事件中了解到：雲端服務的「高可用性」宣傳，有其明確的邊界條件，而這些邊界條件不會出現在銷售簡報上，往往被隱藏在技術文件的細節裡。
在中東戰爭局勢升溫的今天，任何在該區域有業務的企業，都應該重新審視自己的雲端架構。不是因為 AWS 不好，而是因為真正的韌性從來不依賴單一供應商的承諾。
留言
張貼留言