3月1日の朝、世界中のエンジニアが見たのは、AWSのステータスページが赤く染まる光景だった。
ME-CENTRAL-1——AWSのUAE（ドバイ）リージョン。通常は湾岸諸国のビジネスを支える静かなインフラが、その日は「objects struck the facility（物体が施設に衝突した）」という不穏なステータスメッセージを出力し続けていた。
物体。施設への衝突。火災。電源全遮断。
これはサーバー障害でも、自然災害でもなかった。戦争だった。
何が起きたのか——3月1日、ドバイの夜
日本時間2026年3月1日20時30分（PST 4時30分）、AWSのUAEデータセンターに「複数の物体」が衝突した。建物内で火災が発生し、消防当局は延焼防止のために施設全体の電源を完全に遮断する判断を下した。
AWSは公式声明でこう述べるにとどめた。「施設への物体衝突を確認しました。消防当局の指示により電源を全遮断しています。現在、安全確認を優先しています」。
軍事攻撃との関連については「否定も肯定もしない」という姿勢を貫いた。
しかし現実は明白だった。同日、UAEの空にはイランから発射された165発のミサイルと540機以上のドローンが飛来していた。
AWSのme-central-1は3つのアベイラビリティゾーン（AZ）で構成されているが、このうちmec1-az2とmec1-az3の2つが完全停止した。残るmec1-az1は稼働を維持したが、2/3のキャパシティが失われた状態では多くのサービスが正常動作できなかった。
背景——なぜUAEがミサイルの標的になったのか
この被弾を理解するには、その前日に何があったかを知る必要がある。
Operation Epic Fury（2月28日）
2月28日、アメリカとイスラエルはイランの核関連施設と軍事拠点に対する大規模な軍事作戦「Operation Epic Fury」を発動した。この作戦ではイランの9都市が攻撃対象となり、最高指導者アリー・ハーメネイー師が暗殺された。
イランにとってこれは「存亡の瞬間」に等しい事態だった。
Operation True Promise 4（3月1日）
ハーメネイー師暗殺の翌日、イランは「Operation True Promise 4」と名付けた報復作戦を発動した。
標的には中東地域のアメリカの同盟国・友好国が含まれた。UAEはその代表格だ。アブダビとドバイにはアメリカ軍の基地があり、イランにとって「アメリカの前線拠点」と映る。
165発のミサイルと540機以上のドローンという規模は、2024年4月のイスラエルへの攻撃（第一次True Promise作戦）を大幅に上回る。その報復の嵐の中に、たまたまではなく、あるいは意図的に、AWSのデータセンターが飲み込まれた。
AWSのドバイ施設の正確な所在地は公開情報だ。データセンターの場所は業界内では知られており、衛星画像でも確認できる。ミサイルやドローンが「たまたま」そこに落下したとは考えにくい面もある。
停止したサービスの全容——60以上のサービスに影響
電源遮断による影響は、ME-CENTRAL-1を利用していた全システムに波及した。AWSのサービスステータスページは、かつてないほど多くの赤いアイコンで埋め尽くされた。
完全停止したサービス
- EC2（仮想サーバー）——新規インスタンスの起動が不可能に
- S3（オブジェクトストレージ）——データの読み書きが完全停止
- AWS Lambda（サーバーレス実行環境）——関数の実行不可
- AWS Management Console——Web管理画面へのアクセス不能
- AWS CLI——コマンドラインからの操作が機能しない
重大劣化したサービス
- RDS（リレーショナルデータベース）——DBインスタンスへの接続不可
- DynamoDB（NoSQLデータベース）——読み書きレイテンシが急増、一部完全停止
- EKS（マネージドKubernetes）——クラスターのコントロールプレーンが応答不能
- EBS（ブロックストレージ）——EC2にアタッチされたボリュームへのアクセス不能
- ELB（ロードバランサー）——トラフィック分散が機能停止
- VPC（仮想プライベートクラウド）——ネットワーク設定の変更不可
- NAT Gateway——プライベートサブネットからのインターネット接続断
- Redshift（データウェアハウス）——クエリ実行不能
- CloudWatch（モニタリング）——ログとメトリクスの収集停止
この他、Elastic Beanstalk、SageMaker、Glue、Step Functions、API Gatewayなど合計60以上のサービスで障害が報告された。
飛び火したME-SOUTH-1（バーレーン）
さらに、隣接するバーレーンリージョン（ME-SOUTH-1）でも障害が波及した。ドバイとバーレーンのリージョン間トラフィックが増大し、フェイルオーバーが集中したことによる過負荷と見られている。「バックアップリージョンに逃げたら、そっちも一緒に遅くなった」という最悪のシナリオが現実になった。
なぜこれが「歴史的事件」なのか
エンジニアコミュニティで静かに（しかし確実に）共有されている認識がある。この事件は、クラウドコンピューティングの歴史における転換点だ、という認識だ。
史上初——「戦争によるクラウドインフラ破壊」
2006年のAWSサービス開始以来、主要クラウドプロバイダーのデータセンターが軍事行動によって停止した事例はなかった。台風による停電、火災、通信ケーブルの切断——様々な障害があったが、ミサイルが落ちてくることは想定外だった。
正確には「想定されていなかった」のではなく、「想定するのが不適切とされていた」。データセンターのリスク評価において、軍事攻撃は通常「発生確率が極めて低いシナリオ」として除外される。今後はそうはいかない。
「湾岸諸国はAIインフラの安全な投資先」神話の終焉
過去数年、テクノロジー企業にとってUAEとサウジアラビアは夢のような投資先だった。政治的に安定しており、豊富な資金があり、インフラ整備に積極的で、欧米とも中東とも関係が良好だった。
AmazonのPaxSilicaプロジェクト（湾岸諸国への数十億ドル規模のデータセンター投資）、MicrosoftのUAEへの15億ドル投資、Googleのサウジアラビアへのクラウドリージョン設置——これらはすべて「湾岸諸国の地政学的安定性」を前提にしていた。
その前提が、一夜にして揺らいだ。
ドバイは「中立的なビジネスハブ」というブランドを慎重に構築してきたが、米国-イラン緊張の高まりの中で、それが幻想に変わりつつある。
海底ケーブルも狙われていた——物理インフラへの攻撃という新潮流
このデータセンター被弾は、孤立した事件ではない。より大きなトレンドの一部だ。
紅海の海底ケーブル切断（2025年9月）
2025年9月、紅海に敷設された主要海底ケーブル2本が切断された。SMW4（South-East Asia–Middle East–Western Europe 4）とIMEWE（India Middle East Western Europe）——どちらもヨーロッパとアジアを結ぶ幹線ケーブルだ。フーシ派の関与が疑われたが、確証はなかった。
世界のインターネットトラフィックの約17%が紅海経由の海底ケーブルを通過している。この切断は、アジア-ヨーロッパ間の通信速度と信頼性に数ヶ月にわたる影響を与えた。
バルト海のC-Lion1切断（2026年2月）
2026年2月、フィンランドとドイツを結ぶ海底ケーブル「C-Lion1」が切断された。フィンランド当局は、ロシア関与の疑いがあるタンカー「Eagle S号」が90kmにわたってケーブルを引きずった可能性を指摘している。
偶然の事故か、意図的な妨害工作か——いずれにせよ、海底ケーブルが地政学的緊張の「武器」として機能し始めていることは否定できない。
物理インフラへの攻撃という共通パターン
データセンターへの直撃弾。海底ケーブルの切断。
これらに共通するのは、「見えないインフラを標的にする」という戦略だ。現代の経済・社会インフラがどれほどデジタルに依存しているかを逆手に取っている。電力網や通信インフラへの攻撃は昔からあったが、クラウドコンピューティングの台頭でその破壊力が格段に上がった。
データは消えたのか——最も重要な問いへの答え
被害を聞いて多くのエンジニアが最初に考えたのは「データは大丈夫か」という問いだろう。
結論から言う。ME-CENTRAL-1内のデータは、基本的に消失していない。
AWSのストレージサービス（S3、EBS、RDS等）は内部で複数のAZにデータを冗長化している。火災と電源遮断によって一部の物理ハードウェアが破損した可能性はあるが、設計上の冗長性によってデータ自体は保護されている。
ただし「アクセスできる」ことと「使える」ことは別問題だ。データが存在していても、インフラが停止していれば読み出せない。2つのAZが停止した状態では、多くのシステムが機能を失った。「データは無事だが、使えない」という状態が数時間続いた。
マルチリージョン構成で東京リージョンや米国リージョンにもデータを複製していたシステムは、フェイルオーバーして継続稼働できた。ME-CENTRAL-1のみに依存していたシステムは、復旧まで完全に機能停止した。
IT企業・エンジニアが今すぐ学ぶべき教訓
この事件が「他人事」で済む日本のエンジニアはほとんどいない。AWS東京リージョン（ap-northeast-1）や大阪リージョン（ap-northeast-3）を使っていても、アーキテクチャの考え方は根本から見直す必要がある。
教訓1：マルチリージョン設計はもはや「推奨」ではなく「必須」
かつてマルチリージョン構成は「大規模企業のための贅沢なDR（災害復旧）設計」という扱いだった。コストが2倍になり、レイテンシが増加し、設定が複雑になる。中小企業には過剰投資とされてきた。
今後この認識を改める必要がある。地震も台風もサイバー攻撃も戦争も、単一リージョンを破壊するには十分なリスクだ。
具体的には：
- S3のクロスリージョンレプリケーションを有効化する
- RDSのリードレプリカを別リージョンに配置する
- Route 53のフェイルオーバールーティングでリージョン切り替えを自動化する
- DynamoDBのグローバルテーブルでマルチリージョン書き込みを実現する
教訓2：地政学リスクをDR計画に組み込む
従来のDR計画は自然災害（地震・洪水・台風）とシステム障害（ハードウェア故障・ソフトウェアバグ）を主な想定としてきた。
今後は「地政学リスク」を明示的に組み込む必要がある。自社のシステムが依存するリージョンが、どの地政学的緊張地帯の近くにあるかを把握しておくことが求められる。
UAEリージョンを選んだ企業の多くは、「中東ユーザーへのレイテンシ削減」という正当な理由があった。しかしそのリージョンが軍事的な標的になりうることは、DRレビューに入っていなかっただろう。
教訓3：「クラウドは物理的な建物の中にある」という再認識
クラウドという言葉は、インフラの物理的な実体を見えにくくする。しかし現実には、AWSのサービスはどこかの都市にある巨大な建物の中に、大量のサーバーが並んでいる。その建物はミサイルが当たれば燃える。電源が切れれば止まる。
この当たり前の事実を、サービス設計の前提に組み込んでいないシステムは、今回のような事態に無防備だ。
教訓4：バックアップの地理的分散——「遠ければ遠いほどいい」場合がある
「バックアップは別のAZに」から「バックアップは別のリージョンに」、さらに「バックアップは地政学的に異なる地域に」という思想の進化が必要だ。
例えば、中東リージョンをメインとして使うシステムであれば、バックアップは欧州か東アジアに置く。同じ軍事的緊張の影響圏に両方のリージョンが入らないような配置を意識する。
教訓5：クラウドプロバイダー自身のリスク開示を読み直す
AWSのサービス規約（AWS Service Terms）とSLAは、「Acts of God（天災）」「war（戦争）」「acts of terrorism（テロ）」などを免責事項として列挙している。つまりAWSは戦争による障害に対して補償義務を負わない。
これは法的に正当な条項だ。しかし多くの企業はこの条項を実際に読んでいない。クラウドのSLAは99.99%の可用性を謳うが、それが適用されない条件をきちんと把握しておく必要がある。
中東AIインフラ投資——再評価の時
この事件は、テクノロジー業界全体の中東戦略を根本から問い直す契機になっている。
過去2年間、AIデータセンターの建設ラッシュが湾岸諸国で起きていた。UAEのG42社とMicrosoftの提携、サウジアラビアのPROJECT NDAとNVIDIAの関係、クウェートやカタールへのAWSの拡張——これらはすべて「中東の潤沢なオイルマネーとAIの融合」という大きな絵の一部だった。
しかし今回の事件は、その絵に大きなヒビを入れた。
湾岸諸国の政府や投資家がどう反応するかはまだ不透明だ。「UAEは今回の標的になったが、今後は防衛が強化されるから安全だ」という見方もあるだろう。「一度標的になった場所は、また標的になりうる」という見方もある。
一つ確かなのは、これまで「当然の前提」とされていた湾岸諸国の安定性が、少なくとも一部の企業にとっては「再検討が必要なリスク要因」になったということだ。
日本企業への示唆——東京・大阪リージョンの「価値」が上がった日
日本のエンジニアにとってこの事件が持つ意味は、リモートな他人事ではない。
東京リージョン（ap-northeast-1）と大阪リージョン（ap-northeast-3）の価値が相対的に上がった。
日本は地政学的に、現在進行中の中東紛争から距離を置いている。東京と大阪のリージョンが軍事攻撃を受けるシナリオは、現状では中東よりも大幅に低い。地震リスクはあるが、それはDRで対応可能な既知のリスクだ。
日本企業が東京・大阪の2リージョン構成を「基本のDR設計」として採用することは、コストと安全性のバランスとして合理的だ。
また逆説的だが、今回の事件は「クラウドのマルチリージョン冗長化ソリューション」を提供するサービスにとっての追い風になるかもしれない。日本のMSP（マネージドサービスプロバイダー）やコンサルタントが「地政学対応DR設計」を新しいサービスとして提供する余地が生まれている。
わさびからの特集まとめ
「クラウドは雲の上にある」という比喩が、どれだけ危険な思い込みを生み出してきたかを、この事件は教えてくれた。
データは物理的なハードウェアの中に存在する。そのハードウェアは物理的な建物の中にある。その建物は物理的な地面の上に立っている。そしてその地面は、地政学的なリスクを持つ現実の世界の中にある。
AWSのme-central-1が被弾した瞬間、「クラウドは場所に依存しない」という幻想が、文字通り炎に包まれた。
エンジニアが学べることは明確だ。マルチリージョン設計。地政学リスクを含むDR計画。バックアップの地理的分散。SLAの免責事項の把握。
これらは今後のシステム設計において、「あればいい」から「なければならない」の領域に移った。
AWSのステータスページが赤く染まるのを眺めながら、多くのエンジニアが同じことを思っただろう。
——「自分のシステムはどこにあるのか、ちゃんと知っているか？」
関連記事
その他のClaude/AI記事は あかはらVラボ で公開中です。
この記事は あかはらVラボ からの転載です。最新のClaude/AI情報を日本語で発信中。