アベイラビリティゾーンは戦争を想定していなかった — AWS中東リージョンのデータ喪失と障害ドメインの再定義

リージョンが物理的に失われたとき、それはクラウドの失敗なのか、それとも最初から顧客の責任範囲だった設計の空白なのか。

導入

2026年9月15日(太平洋時間)、AWSはサービスステータスページに2つの告知を掲載した。1つは中東(バーレーン)リージョンme-south-1に関するもの、もう1つは中東(UAE)リージョンme-central-1に関するものである。バーレーンの告知の核心はこうだ。インフラの損傷は複数のアベイラビリティゾーン(Availability Zone、AZ)に及び、リージョナルサービスとマルチAZサービスが耐えるよう設計された水準を超えた。徹底的な評価の結果、このリージョンにのみホストされていたリソースとデータへのアクセスは復旧できないと判断した、という内容である。UAEの告知は範囲が狭い。mec1-az2にのみ存在したリソースとデータへのアクセスを復旧できないとしている。

このニュースはWall Street Journalの「AWS says it can’t restore some data from mideast facilities struck by Iran」という記事としてHacker Newsのトップページに上がり、530ポイントを集めた。WSJの本文はペイウォールのため、本稿の執筆時点では確認できていない。そこで本稿は、AWSステータスページのRSSフィードに残る告知の原文と、それを報じたTechzineおよびDeveloping Telecomsの記事を一次的な根拠とする。攻撃の主体について、AWS自身は「中東で進行中の紛争」と「ドローン攻撃」としか書いておらず、イランという国名はWSJの見出しと一部の報道に由来することを先に断っておく。

この事件は、クラウドエンジニアにとって見慣れた言葉、すなわちアベイラビリティゾーン、イレブンナイン(11 9s)の耐久性、責任共有モデルを、まったく異なる文脈で読み直させる。本稿ではまず告知の原文で確認できる事実を整理し、次にマルチAZ設計が実際に何を約束していたのか、そして顧客がいま何を変えるべきなのかを検討する。

現象分析 — 告知原文で書き直す6か月

AWSステータスページのme-south-1とme-central-1のRSSフィードを時系列で読むと、事件の輪郭がかなり鮮明になる。

始まりは3月1日である。UAEの告知によれば、mec1-az2は太平洋時間3月1日午前4時頃に電源が落ち、その時点ではS3は正常に動作していた。続いて2つ目のゾーンであるmec1-az3が損傷すると、S3のエラー率が上昇した。同日夜(太平洋時間)にはバーレーンのmes1-az2でAPIエラーの増加が報告され、初期の告知はこれを「局所的な電源問題」と呼んでいた。

原因が公表されたのは3月2日午後の告知である。AWSは、両リージョンともドローン攻撃によってインフラに物理的な影響を受けたと明らかにした。UAEでは施設2か所が直撃を受け、バーレーンでは施設1か所の近くへのドローン攻撃がインフラに物理的な影響を及ぼした。その結果、構造的な損傷、電力供給の途絶、そして一部のケースでは消火活動による追加の浸水被害が生じたという。同じ告知は、EC2、S3、DynamoDB、Lambda、Kinesis、CloudWatch、RDS、マネジメントコンソールとCLIでエラー率の上昇と可用性の低下が起きていると列挙している。

この時点の勧告文を見ると、AWSはかなり早い段階からリージョン外への退避を勧めていた。3月2日の告知は、中東にワークロードを置く顧客に対し、今すぐデータをバックアップし別リージョンへの移行を検討するよう求め、代替リージョンとして米国、欧州、アジアパシフィックをレイテンシーとデータレジデンシー要件に応じて選ぶよう案内している。バーレーンリージョンについては、S3データと重要データを別リージョンへレプリケートせよという勧告が3月2日から3日にかけて繰り返し出ている。RDSのマルチAZデータベースについても、データ保全のため予防的にエクスポートを作成するよう勧めていた。

4月30日の告知は局面の転換点である。バーレーンリージョンは中東の紛争により損傷を受け現在利用できず、顧客は別リージョンでリモートバックアップからリソースを復旧すべきだとした。UAEリージョンは顧客アプリケーションを安定してサポートできない状態にあるとした。両リージョンとも関連する課金処理を停止し、復旧には数か月かかる見込みだと述べている。

そして9月15日の告知が出た。バーレーンの告知によれば、3月に最初のAZが損傷した時点からAWSは他リージョンへの移行を推奨しており、大半の顧客は4月に2つ目のAZが停止してリージョンが利用不能になる前に移行を終えていた。残った顧客には、可能な場合はバックアップを使い、あるいはアクセスできないデータの影響を緩和する代替策を講じて、別リージョンで運用を再開できるよう支援してきたという。影響を受けたすべてのインフラを評価し、移行されなかったデータとリソースを復旧するためのあらゆる選択肢を尽くした、という一文がその後に続く。次回の更新は2027年初頭と予告された。

UAEの告知は少し異なる。mec1-az2専用のデータは復旧不能だが、リージョナルリソースと、他の被災ゾーン(mec1-az1とmec1-az3)のゾーンリソースについては復旧を続けているとした。大半の顧客はバックアップの復元や、アクセス可能なまま残ったデータのコピーによって、別リージョンで運用を再開したと書いている。

ここで確認できていないことも明確にしておく必要がある。何人の顧客が、どのサービスの、どれだけのデータを失ったのかは公表されていない。2つの告知原文のどこにも、顧客数やデータ量に関する数字はない。Techzineは、Bloombergが9月15日に、AmazonはバーレーンのデータセンターとUAEのネットワークの一部に保存されたデータにアクセスできないと報じたことを伝えつつ、この表現はバーレーンがリージョン全体でUAEは1ゾーンのみという区別をぼかしていると指摘した。Hacker Newsでも同じ問いが出ている。記事はどのプロダクトが影響を受けたかを書いておらず、EBSや単一AZのS3ならAmazonの立場では設計どおりであり、マルチAZのS3なら意味が大きく変わる、という指摘である(@advisedwang、直接の引用ではなく、コメントの要旨の要約)。

深層分析 — マルチAZは何を約束していたのか

この事件をめぐる議論の中心には「イレブンナイン」がある。Hacker Newsの最初の質問も、S3を3つのアベイラビリティゾーンに置いていてもデータが消えたということか、というものだった(@markive、直接の引用ではなく、コメントの要旨の要約)。これに対して複数の利用者が訂正を入れた。イレブンナインは保証ではなく「設計目標」であり、S3のSLAは耐久性ではなく可用性を扱っていること(@advisedwang、@ciberado)、そしてSLAには不可抗力の免責条項があること(@beejiu、@stackskipton、直接の引用ではなく、コメントの要旨の要約)である。ある利用者はAWSカスタマーアグリーメントの不可抗力条項をそのまま貼り付けたが、そこにはテロ行為と戦争が明記されている(@gilbetron、直接の引用ではなく、コメントの要旨の要約)。

より興味深いのは、AWSが今回の告知で選んだ言葉である。「損傷は複数のアベイラビリティゾーンに及び、リージョナルサービスとマルチAZサービスが耐えるよう設計された水準を超えた」。この一文は、マルチAZ設計の障害モデルを自ら明かしている。3月2日のUAEの告知はこれをさらに明示的に書いていた。S3はリージョナルサービスであり、単一のアベイラビリティゾーンの完全な喪失に耐えつつ耐久性と可用性を維持するよう設計されている、というものだ。実際、mec1-az2の電源が落ちたときS3は正常に動作し、2つ目のゾーンが損傷するとエラー率が上がった。

つまりマルチAZの約束とは「同時に1つのゾーンが失われること」に耐えることである。ゾーン同士は物理的に離れ、電源とネットワークが分離されているため、火災や停電、洪水といった事故はたいてい1つのゾーンにとどまる。これはランダムな障害に対しては極めて合理的な前提だ。しかし、意図を持った攻撃はランダムな障害ではない。相関がある。同じ国、同じ都市圏にある複数の施設が、同じ紛争の同じ標的リストに載りうる。障害の独立性という前提が崩れれば、「3つのうち2つが同時に壊れる確率」は掛け算では計算できない。

Hacker Newsには、これを工学の用語で整理したコメントがあった。FMECA(故障モード・影響・致命度解析)を行うエンジニアは、意図的に除外した故障モードを最初に明示すべきであり、データセンターは通常、戦争や帝国の崩壊に耐えるようには設計されていない。ただしバーレーンのように国家自体が恒久的な防空施設を築くほど戦争を懸念している場所であれば、戦争の可能性を可用性の計算に含めるのが合理的だ、と付け加えている(@dhx、直接の引用ではなく、コメントの要旨の要約)。

元AWS社員を名乗る利用者は、サービス構造の違いを説明した。AWSには単一ゾーンのプロダクトがあり、それが被災ゾーンにあればデータは失われる。S3やEFSのようなマルチAZプロダクトは、1つのゾーンを長期間失うとデータプレーンがシャードを移し、再び耐久性目標に戻る、という説明である(@harshaw、直接の引用ではなく、コメントの要旨の要約)。この説明を告知の原文と重ねると、バーレーンでマルチAZサービスまで手の施しようがなかった理由が推測できる。再レプリケーションが終わる前に2つ目のゾーンが失われれば、複製元と複製先が同時に減る。ただしこれは推論であり、AWSが技術的なポストモーテムを公開したわけではない。Hacker Newsでも実際の技術レポートを読みたいという声が出ていた(@purpleidea、直接の引用ではなく、コメントの要旨の要約)。

では責任はどこにあるのか。AWSの責任共有モデルは大まかにこう要約される。AWSはクラウド「そのもの」のセキュリティと運用に責任を持ち、顧客はクラウド「の中の」もの、すなわちデータ、構成、そしてどのリージョンとどの耐久性オプションを選ぶかに責任を持つ。リージョン間レプリケーションはデフォルトではなく、顧客が有効化して費用を払う機能である。ある利用者は、S3のクロスリージョンレプリケーションや他サービスのクロスリージョンDRを有効にして費用を払っていた慎重な顧客は無事だったはずだと書いた(@gregw2、直接の引用ではなく、コメントの要旨の要約)。別の利用者は、これはまさに設計どおりであり、DR用のバックアップを別の場所に置くのは顧客の責任だとした(@ernsheong、直接の引用ではなく、コメントの要旨の要約)。一方、批判的な側は、AWSの幹部が過去のCBSのインタビューで、データセンターが1つ爆破されても顧客は気づかないだろうと答えた場面を持ち出した(@cmiles8、直接の引用ではなく、コメントの要旨の要約)。マーケティングの語調と契約書の文言との距離が、今回の事件で露わになったという指摘である。

ここにもう一層ある。データレジデンシー規制だ。ある利用者は、UAEの医療分野の顧客と仕事をしており、政府の要件によりデータをUAE国内にのみ保存しなければならなかったと書いている(@rishikeshs、直接の引用ではなく、コメントの要旨の要約)。別の利用者は、データレジデンシー要求の裏面がまさにこれだと述べた(@carefree-bob、直接の引用ではなく、コメントの要旨の要約)。反論もあった。EUの場合、EDPBは鍵がEU域内にとどまり安全な移転手段があれば、暗号化したバックアップを域外に置くことを明示的に認めている、というものだ(@Barrin92、直接の引用ではなく、コメントの要旨の要約)。1つの国にリージョンが1つしかなく、その国の法律がデータの持ち出しを禁じているなら、顧客がリージョン間レプリケーションを有効にしたくてもできない。この場合「顧客の責任」という言葉は、技術的には正しくても実務的には空虚になる。

展望と示唆 — 障害ドメインを地図の上に描き直す

今回の事件が実務者に残す教訓は新しいものではない。ただし、その教訓の単位が変わった。

第一に、障害ドメインの単位を「ゾーン」から「地政学的な圏域」へ広げる必要がある。これまで多くのチームのDR設計はAZ障害とリージョン障害を区別し、リージョン障害はソフトウェアのバグやコントロールプレーンの問題による一時的な事象として想定してきた。今回、リージョンは数か月単位で失われ、AWSが代替リージョンとして勧めたのは隣のリージョンではなく、米国、欧州、アジアパシフィックだった。同じ紛争圏にある2つのリージョンを互いのバックアップとする設計は、今回のように2つのリージョンが同じ日に被害を受ければ意味を失う。

第二に、「レプリケーションはバックアップではない」という古い格言を改めて書き留めておく価値がある。Hacker Newsのあるコメントも、レプリケーションは検証済みのバックアップではないと念を押していた(@burnt-resistor、直接の引用ではなく、コメントの要旨の要約)。別のコメントは、バックアップがすべてAWSにあるならバックアップがないのと同じだとまで言った(@KingOfCoders、直接の引用ではなく、コメントの要旨の要約)。極端な表現だが、問い自体は有効である。バックアップが元データと同じアカウント、同じプロバイダー、同じ法域にあるなら、そのバックアップはどの故障モードを防ぐのか。

第三に、警告に反応するまでの時間が結果を分けたという点である。AWSの告知によれば、3月初めからリージョン移行を推奨し、大半の顧客は4月の2つ目のゾーン停止前に移行を終えていた。つまりデータを失ったのは、事前に別リージョンのバックアップを持たず、約2か月の猶予期間にもデータを移せなかった、あるいは移さなかった顧客である。その理由が規制だったのか、コストだったのか、単なる惰性だったのかは、公開資料からはわからない。ただ、「大規模障害の告知が出たら数時間以内に何をするか」をランブックに前もって書いておく価値は明らかだ。

実務的にまとめるとこうなる。重要データについてリージョン間レプリケーションか別リージョンへの定期バックアップを有効にし、可能であれば別アカウントや別プロバイダーにコピーを置き、リストアを実際に訓練する。データレジデンシー要件がある場合は、規制当局が暗号化された域外バックアップをどこまで認めるかを事前に確認しておく。そしてどのリージョンを使うかを決める際、レイテンシーと単価に加えて、そのリージョンが置かれた地政学的な位置をリスク評価の項目として書き込む。ある利用者は、ニューヨーク地域のDR計画でリージョン全体が麻痺する事象を「ハリケーン・サンディ2」と呼んできたが、今後は「AWSバーレーン2」を例に加えるかもしれないと書いた(@alexpotato、直接の引用ではなく、コメントの要旨の要約)。サイバー保険の側でも、こうした大規模データ喪失のシナリオは検証されたことがないだろうという懸念が出ていた(@DeepYogurt、直接の引用ではなく、コメントの要旨の要約)。

結論

AWSの9月15日の告知は誠実な文書である。損傷がマルチAZサービスの設計上の耐性を超えたことを自ら認め、3月から移行を推奨していたという記録もステータスページにそのまま残っている。契約上は不可抗力条項があり、責任共有モデル上はリージョン間のバックアップは顧客の担当だ。その意味で今回の事件は、クラウドの失敗というより、設計前提の境界が露わになった事件である。

ただし、その境界がどこにあるかを顧客が事前に知りえたかは別の問題だ。アベイラビリティゾーンは互いに独立して故障するという前提の上に立っており、意図を持った攻撃はその独立性を壊す。データを国内に置けという規制は、リージョンが1つしかない国では、リージョン間バックアップという顧客の選択肢を消してしまう。

自分のサービスが使っているリージョンの一覧を地図の上に打ってみてほしい。それらの点が同じ紛争、同じ電力網、同じ法域にまとめて縛られているなら、いまのDR設計はいったい何を防ぐために作られているのか。

出典: