AWSリージョンが戦争被害で復旧できず　「マルチAZ」だけでは足りない理由

インターネット , , , , , , ,

Amazon Web Services（AWS）は2026年9月15日、戦争で被害を受けた中東の設備について、最新の状況を明らかにしました。

バーレーンリージョンは、現在も利用できない状態が続いています。UAEリージョンでも、1つのアベイラビリティーゾーン（AZ）に保存されていた一部のデータへアクセスできません。

今回の事例から分かるのは、複数のAZを使う「マルチAZ」だけでは、リージョン規模の災害に対応できないことです。

重要なシステムでは、別リージョンで復旧できる仕組みも必要です。ただし、すべてを常時二重化すればよいわけではありません。

この記事では、被害の経緯とマルチAZの限界を整理します。過去の火災や他社クラウドとも比較しながら、現実的な対策を考えます。

AWSのバーレーンリージョンは復旧できない状態が続く

AWSは、バーレーンで移行されなかったデータとリソースについて、復元するための手段をすべて試したと説明しました。

Reutersの9月15日付報道によると、被害は複数のAZに広がりました。AWSがリージョンやマルチAZのサービスで想定していた範囲を超える被害だったとしています。

多くの顧客は、4月にリージョン全体が使えなくなる前に別リージョンへ移りました。移行できなかった顧客に対しては、遠隔地のバックアップなどを使った再構築を支援しています。

UAEでは、3つのAZのうち「mec1-az2」にだけ保存されていたデータへアクセスできません。ほかのAZを含めた復旧作業は続いています。

地域2026年9月15日時点の状況次の更新予定
バーレーン
ME-SOUTH-1		リージョンが利用できない状態。未移行データは復元手段を使い切った2027年初め
UAE
ME-CENTRAL-1		mec1-az2だけにあったデータとリソースへアクセスできない今後数カ月以内

「すべての顧客データが失われた」という発表ではありません。別リージョンへ移行した顧客や、遠隔地にバックアップを持つ顧客は復旧できています。

2026年3月、1つのAZ障害が複数AZの被害へ広がった

UAEでは最初の1AZが止まった段階では耐えられましたが、2つ目のAZが停止するとリージョンサービスにも障害が広がりました。

3月1日、UAEのmec1-az2に物体が衝突し、火災が発生しました。当初、AWSはマルチAZで稼働する顧客への影響はないと案内していました。

ところが、その後mec1-az3も停止しました。3つあるAZのうち、2つが同時に大きな被害を受けたことになります。

AWSの公式障害情報によると、S3は最初のAZが停止した後も正常に動いていました。2つ目が止まると、データの読み書きで高い失敗率が発生したと説明しています。

時期主な出来事障害範囲
3月1日UAEのmec1-az2で火災と停電1AZ
3月1日夜mec1-az3にも障害が発生3AZ中2AZ
3月2日AWSがドローン攻撃による物理被害を確認UAEとバーレーン
4月バーレーンの別AZも停止リージョン全体
9月15日復元できないデータやリソースがあると判明発生から約198日

3月時点でAWSは、UAEの2施設が直接攻撃を受けたと説明しました。バーレーンでは、近隣への攻撃によって設備に物理的な被害が出ました。

建物だけでなく、電源設備への被害や消火活動による水害も発生しています。ソフトウェアを再起動するだけでは復旧できない障害でした。

マルチAZは「1つのAZが止まる事故」に備える仕組み

マルチAZは高可用性を高める仕組みですが、リージョン全体を失った場合の災害復旧とは役割が違います。

AWSのリージョンは、独立した複数のAZで構成されています。AZは、1つ以上のデータセンターをまとめた単位です。

AWSの公式文書でも、複数AZへの配置は「単一拠点の障害」への対策と説明されています。リージョン同士は分離されており、データも自動では複製されません。

AWSは世界39リージョン、124AZを運用しています。各リージョンは原則として3つ以上のAZを持ちます。

マルチAZの強みは、低遅延で連携できることです。ただし、同じ地域に集まっているため、戦争や広域災害では複数AZが同時に被害を受ける可能性があります。

構成主に耐える障害耐えにくい障害
単一AZサーバーや一部機器の故障AZ全体の停電・火災
マルチAZ1AZの停止複数AZ・リージョン全体の停止
マルチリージョンリージョン全体の停止全リージョンへ広がる設定ミスや攻撃
別環境の変更不能バックアップデータ破壊やランサムウェア復旧手順の未整備、バックアップ自体の破損

独自分析1：3つのコピーがあっても「独立した障害範囲」は1つ

コピーの数よりも、同じ原因で一緒に壊れない場所へ分けているかが重要です。

本記事では、この考え方を「独立障害範囲数」として扱います。AWSの正式な指標ではなく、構成の違いを分かりやすく比べるための独自指標です。

3つのAZにデータを置けば、物理的なコピーは3つになります。しかし、1つの事故がリージョン全体に及ぶ場合、独立障害範囲数は1のままです。

データの置き方物理コピーの例リージョン災害に対する独立障害範囲数
1AZだけ11
同一リージョンの3AZ31
2リージョンの各3AZ62
2リージョン＋別管理のバックアップ7以上3

最後の構成では、バックアップの権限も分ける必要があります。同じ管理者アカウントから削除できる状態では、設定ミスや不正操作に対する独立性が下がります。

地理的な場所に加えて、電源、通信、権限、ソフトウェアも分ける必要があります。複数の経路で復旧できるようにしておくことが大切です。

独自分析2：約198日の停止は99.99％の年間停止枠の約5,425倍

今回の物理被害は、通常の数時間規模のクラウド障害とは桁が違います。

3月1日から9月15日までは約198日です。時間に直すと4,752時間、分では28万5,120分になります。

稼働率99.99％で許容される年間停止時間は約52.6分です。28万5,120分は、その約5,425倍に相当します。

これは停止規模を比べるための独自計算です。AWSのSLA違反や補償額を判定するものではありません。顧客ごとに構成が異なり、実際の停止期間にも差があります。

この規模になると、施設の復旧を待ち続ける設計は現実的ではありません。被害が数カ月に及ぶ場合は、別の場所でサービスを再構築する必要があります。

独自分析3：100TBの退避には1Gbpsでも理論上9.3日かかる

攻撃を受けてから大容量データを退避しようとしても、回線速度が間に合わない場合があります。

AWSはバーレーンの最初のAZが被害を受けた後、別リージョンへの移行を勧めました。多くの顧客は、4月に別AZが止まる前に移行しています。

ただし、100TBを1Gbpsで送るには、通信だけでも理論上約9.3日かかります。実効速度を70％とすると約13.2日です。

データ量1Gbps・理論値1Gbps・実効70％10Gbps・実効70％
10TB約22.2時間約31.7時間約3.2時間
100TB約9.3日約13.2日約31.7時間
1PB約92.6日約132.3日約13.2日

計算式は「データ量×8÷回線速度」で、通信の往復遅延やAPI制限は含んでいません。実際には、暗号化や再送、読み出し性能などの影響でさらに遅くなります。

重要なデータは、平時から別リージョンへ複製しておく必要があります。災害が起きてからの退避は、最後の手段と考えた方がよいでしょう。

過去事例：2021年のOVHcloud火災でも同じ場所のバックアップが失われた

「本番とバックアップを同じ場所に置く」という弱点は、戦争に限らず火災でも表面化しています。

2021年3月、フランス・ストラスブールのOVHcloud施設で火災が発生しました。SBG2は全焼し、同じ構内にあるほかの施設も停止しました。

OVHcloudの公式情報によると、火災は3月10日午前0時47分に発生しました。復旧までの期間は施設によって異なりました。

本番データとバックアップを同じデータセンターに置いていた顧客では、両方を失った事例も報告されています。

今回のAWS障害では、さらに広い範囲の複数AZに被害が及びました。施設内で二重化するだけでなく、地理的に離しておく必要性も分かります。

AWS・Azure・Google Cloudを比べても「設定なしで安全」なサービスはない

クラウド会社を替えるだけでは解決しません。どの会社を使う場合でも、必要に応じて複数リージョンを使う設計が求められます。

Azureには「リージョンペア」があります。一部のサービスでは、ペアになったリージョンへデータを自動で複製できます。

ただし、Microsoftの公式文書では、配置しただけで高可用性や自動フェイルオーバーが実現するわけではないと明記しています。

Google Cloudも、ゾーンとリージョンを分けています。Googleの公式文書では、重要なシステムを複数ゾーンや複数リージョンに配置するよう勧めています。

クラウド同一リージョン内の対策リージョン障害への考え方注意点
AWS複数AZ別リージョンへ複製・復旧リージョン間は自動複製されない
Microsoft Azure可用性ゾーンリージョンペアや任意の別リージョンペアだけでは自動復旧にならない
Google Cloud複数ゾーン複数リージョンへ配置サービスごとに複製範囲が違う

3社とも、ゾーンは主に単一ゾーンの障害に備えるための仕組みです。リージョン全体が使えなくなる事故では、利用者側の設計も大きく影響します。

反証：戦争は例外的だから、日本ではマルチAZだけでもよいのか

一般的なシステムならマルチAZで十分な場合もありますが、停止が許されないシステムでは別リージョンも必要です。

戦争によって複数AZが物理的に破壊される事態は、極めてまれです。すべてのブログや社内ツールを、常に2つのリージョンで動かす必要はありません。

マルチリージョンにすると、費用だけでなくシステムの複雑さも増します。データの整合性や通信遅延への対応が必要になり、運用担当者の負担も大きくなります。

ただし、日本にも地震や広域停電、通信網の障害があります。決済、医療、行政、予約、物流などのシステムは、数日止まるだけでも大きな影響が出ます。

判断するときは「戦争が起きる確率」だけを見るべきではありません。「停止した場合の損失」と「復旧までに必要な時間」を基準に考える必要があります。

独自試算：月100万円のAWS環境なら、どこまで二重化するべきか

すべてのシステムを同じレベルで二重化せず、停止による損失に合わせて復旧方法を変えれば、費用を抑えられます。

以下は、現在のマルチAZ環境を月100万円とした独自モデルです。AWSの見積価格や保証値ではありません。

遠隔バックアップは10％、最小構成は25％、待機環境は50％、常時二重稼働は100％の追加費用がかかると仮定しました。

復旧方式想定する状態月額モデル復旧時間の目安向くシステム
別リージョンのバックアップ障害後に再構築110万円数時間～数日ブログ、社内資料
パイロットライトDBなど最小部分だけ常時稼働125万円数十分～数時間業務システム
ウォームスタンバイ縮小版を別地域で稼働150万円数分～数十分EC、予約、SaaS
アクティブ・アクティブ2地域で常時処理200万円数秒～数分決済、重要インフラ

たとえば、停止による損失が1時間100万円なら、月50万円を追加する待機環境は、月30分の停止を防げれば元が取れる計算です。

反対に、停止しても翌日まで待てるサイトなら、遠隔バックアップの方が合理的です。まずは、どの程度の時間まで停止を許容できるのかを決める必要があります。

AWS Well-Architected Frameworkでも、RTOとRPOを業務要件から決めるよう勧めています。

RTOは「何時間まで止められるか」を表します。RPOは「何分前までのデータ消失を許容できるか」を示す指標です。

利用者が今すぐ確認したい7項目

バックアップを用意するだけでは十分ではありません。別リージョンから実際に復元できるか、事前に試しておく必要があります。

  1. 重要サービスごとにRTOとRPOを決める
  2. データの保存先が1つのリージョンに偏っていないか調べる
  3. 別リージョンへバックアップや複製を作る
  4. 復旧先のCPU、GPU、IPアドレスなどの上限を確認する
  5. DNS、証明書、秘密鍵、監視も復旧できるようにする
  6. 管理者アカウントとバックアップ削除権限を分ける
  7. 半年または1年ごとに復旧訓練を行う

特に見落としやすいのが、復旧先の空き容量です。災害時には多くの企業が同時に移行するため、必要なサーバーを起動できない可能性があります。

復旧手順も、担当者の記憶だけに頼るのは危険です。手順をコード化し、別リージョンから読める場所に保管しておく必要があります。

読者への影響：日本のAWS利用者も「東京リージョン内だけ」を見直す時期

中東の障害が日本の利用者へ直接影響しなくても、同じ設計上の弱点は東京リージョンにもあります。

東京リージョン内の複数AZに分けていれば、一般的な機器故障やAZ障害には強くなります。ただし、広域災害が起きたときの逃げ先にはなりません。

重要なシステムでは、大阪リージョンなど別地域での復旧も検討できます。海外リージョンを使う場合は、通信遅延やデータ保管に関する規則も確認が必要です。

一般利用者にも無関係ではありません。銀行、EC、予約アプリなどが止まった場合、原因がアプリ会社ではなく、その先にあるクラウド設備の可能性もあります。

サービス提供者は、障害時の告知手段も分けておく必要があります。公式サイトと障害告知を同じリージョンに置いていると、障害の説明までできなくなる可能性があります。

まとめ：マルチAZは必要だが、災害復旧の完成形ではない

AWSの戦争被害から分かるのは、「高可用性」と「災害復旧」を分けて考える必要があることです。

マルチAZは、1つのAZが停止する障害には有効です。実際、UAEでは最初の1AZが止まった段階では、多くのマルチAZ構成が動き続けました。

しかし、2つのAZやリージョン全体が被害を受けると、マルチAZだけでは対応できません。別リージョンに保存したデータと、実際に実行できる復旧手順が必要です。

すべてを常時二重化する必要はありません。停止による損失、RTO、RPOを決めたうえで、バックアップ、待機環境、常時二重稼働を使い分けるのが現実的です。

今回の出来事から、クラウドも物理的な設備の上で動いていることが改めて分かります。施設の復旧を待たず、別の場所でサービスを再開できる設計が必要です。

主な情報源

障害状況はAWSの公式情報を中心に、2026年9月15日時点で確認しました。

タグ

Related Posts

コメントを送信

You May Have Missed