Amazon Web Services（AWS）は2026年9月15日、戦争で損傷した中東の設備について、バーレーンリージョンとアラブ首長国連邦（UAE）の一部にだけ保存されていたデータへのアクセスを復旧できないと発表した。3月のドローン攻撃から続く障害は、一部の顧客にとって、設備が直るまで待てば済む問題ではなくなった。AWSは他地域での業務再開を支援しているが、その成否を左右するのは、被害を受けた場所の外に何を残していたかである。別リージョンへのコピーから実際に業務を立ち上げるまでには、データの複製範囲や暗号鍵を含む、いくつかの条件がある。

AD

復旧不能になった範囲と、まだ復旧中の範囲

AWSが9月15日の更新で示した対象は、バーレーンとUAEで異なる。バーレーンではリージョン全体、UAEでは「mec1-az2」というアベイラビリティゾーン（AZ）だけに保存されていたデータとリソースが、アクセスを復旧できない対象になった。リージョンはAWSがサービスを提供する地理的な地域で、その中には電源や冷却、ネットワークを分離した複数のAZがある。

対象 AWSがアクセスを復旧できないとした範囲 継続している対応・次回更新
バーレーン（me-south-1） 同リージョンだけに保存されていたデータとリソース 他リージョンでの業務再開を支援。次の報告は2027年初頭
UAE（me-central-1）のmec1-az2 このAZだけに保存されていたデータとリソース 損傷したインフラの交換を進め、今後数カ月以内にサービス復旧について更新
UAEのmec1-az1・mec1-az3とリージョン共通のリソース 上記の復旧不能判断とは分けて説明 引き続き復旧作業中

出典：AWS Healthの2026年9月15日付バーレーン・UAEの発表。更新予定はサービスの再開日を約束したものではない。

両地域の発表に共通する限定は、そこだけに保存されていたという点だ。別の場所に残っていたバックアップまで失われたという意味ではない。AWSは、UAEの多くの顧客がバックアップの復元や、アクセス可能だったデータのコピーによって、ほかのリージョンで業務を再開したと説明している。

バーレーンには、被害が拡大するまでの時間差もあった。最初のAZが3月に損傷した段階でAWSは移行を勧め、多くの顧客が、4月に別のAZの障害でリージョン全体が利用不能になる前に移行したという。その後、AWSは移されずに残ったデータとリソースの回復手段を尽くしたが、アクセスを戻せないと判断した。

したがって、2027年初頭という時期を「バーレーンのデータが戻る予定」と読むことはできない。設備を再建することと、失われたアクセスを取り戻すことは別の作業だ。また、UAEのほかのAZについても復旧作業は続いており、複数AZに分散していれば被害を免れた、と一律には言えない。

マルチAZが守る範囲を、今回の経緯から読む

UAEで最初のAZが停止した際、Amazon S3は動き続けていた。AWSは3月2日の障害説明で、S3は単一AZを完全に失っても耐久性と可用性を維持する設計であり、3月1日のmec1-az2の電源停止後も通常どおり動作したと記している。エラーが増えたのは、2つ目のAZも障害に陥ってからだった。

物理的な被害も一種類ではない。3月2日時点でAWSは、UAEの2施設への直接のドローン攻撃と、バーレーンの1施設近傍への攻撃を報告した。構造物の損傷や電力供給の中断に加え、消火活動による水害も一部で起きたという。AZはサービスを分離する区画であり、ここで報告された施設数とAZ数を同一視することもできない。

この経緯は、マルチAZの有効性を丸ごと否定するものではない。最初の故障を吸収できても、同じ地域で被害が重なると、その設計で耐えられる範囲を超える。バーレーンの9月の発表では、AWS自身が、被害は複数AZに及び、リージョン内やマルチAZで動くサービスの設計想定を超えたと認めている。

AWSの災害復旧指針も、同一リージョンの複数AZで火災や洪水、大規模停電に備えることと、リージョン内で業務を動かせなくなる事象への備えを分けている。後者まで守る必要があれば、複数リージョンを使う復旧戦略になる。AZを増やすことと、地域の外へ復旧先を持つことは、代替関係にはない。

AD

別リージョンのコピーを「復旧できる状態」にする条件

S3には、複製設定を追加しても、それ以前のデータは自動では複製されないという条件がある。公式ガイドによれば、通常のライブレプリケーションが対象とするのは設定後に書き込まれた新規・更新オブジェクトだ。既存分を移すには、S3 Batch Replicationを使う。別リージョンへの複製を有効にしたという記録だけでは、過去から蓄積したデータがそこにそろっているかは分からない。

別リージョンで復旧するには、必要なデータのコピーに加え、復号の権限、アプリを動かす構成、移行先の条件を確かめる必要がある。

AWSの設計資料を、復旧時に確かめる対象ごとに分類すると、次のようになる。

確認する対象 AWS文書にある条件 復旧試験で確かめること
データの範囲（S3） ライブレプリケーションは設定以前の既存オブジェクトを遡って複製しない 以前から必要だったデータも復旧先に存在し、読めるか。S3ガイド
復号（AWS KMS） マルチリージョンキーの複製は自動ではなく、各地域で鍵ポリシーなどを管理する 復旧先で使う鍵を、実際の運用権限で利用できるか。KMSガイド
実行環境 バックアップからの復旧にはインフラ作成・コード配置・データ復元が必要。稼働済みの待機環境でも容量確保が要る アプリが起動し、必要な処理量を受け持てるか。復旧戦略
移行先 利用するサービスの提供状況、遅延、データの保管場所に関する要件を確認する 業務とデータの条件を満たす場所で、復旧手順を実行できるか。復旧先の選定

2026年9月19日に確認したAWSの各文書から、データ、復号、実行環境、移行先の条件を分類した。被災した顧客の構成や、データを回復できなかった個別の原因を示す表ではない。S3やKMSに固有の条件は、該当するサービスで確認する必要がある。

暗号化したコピーは、復旧先で復号できて初めて業務に使える。AWS KMSのマルチリージョンキーは、異なる地域で同じ鍵素材を使える仕組みだが、利用者が複製する地域を選び、それぞれの鍵ポリシーや権限を管理する。AWSが必要な場所へ自動で鍵を配るわけではない。

ただし、すべての復旧設計にマルチリージョンキーを導入すべきだ、という話でもない。S3のクロスリージョンレプリケーションは、複製先のKMS鍵でデータキーを再暗号化する。これは両側に関連するマルチリージョンキーを使っていても同じだ。確認すべきなのは鍵の名称ではなく、利用中のサービスがどの鍵を使い、復旧先の権限でデータを読めるかである。

さらに、データの複製は、過去の正常な時点に戻せるバックアップとも役割が違う。AWSは、継続的な複製だけではデータの破損や破壊に対応できない場合があり、世代を残す仕組みや時点復元も備えるよう勧めている。地理的に離す対策と、時間を遡って戻す対策は、別々に確かめる必要がある。

復旧試験で確かめるべきは、元の地域に戻らず業務を再開できるか

バックアップから環境を作り直す方式では、復旧時にインフラを用意してコードを配置し、データを戻す作業が発生する。一方、別リージョンで小規模なシステムを常時動かしておく待機方式なら、既に動いている環境を拡大して引き継げる。AWSはこうした方式を、許容できる停止時間やデータ損失と、費用・運用の複雑さとの兼ね合いで選ぶよう求めている。

日本の利用企業にとっても、点検の単位は「バックアップあり」という設定項目より具体的にできる。過去から必要なデータを復旧先に戻し、現地の鍵と運用権限で読み、アプリが業務を処理できるまでを試す。その間に元のリージョンでリソースを作成したり設定を変更したりする手順が残っていれば、その依存が復旧を妨げないかも確認する。

AWSの復旧先選定の指針は、復旧経路の依存関係を記録し、演習で目標を検証するよう求めている。目標には、復旧までに許容する時間を表すRTOと、どの時点までのデータを回復するかを表すRPOがある。遠くにコピーがあっても、その場所で必要なサービスを使えず、保管要件も満たせなければ、業務の復旧先としては使えない。

AWSが今後示すUAEの進捗や2027年初頭のバーレーンの報告は、現地設備の行方を判断する材料になる。それを待つ間にも、利用企業は元の地域が戻らない条件で復旧試験を行える。必要なデータを復号し、決めた時間内に業務を再開できることまで確かめれば、別リージョンのコピーを事業継続の備えとして評価できる。