顧客はリージョンを離れられるが、必ずしも逃れられるわけではない：AWS US-East-1 と回復力の代償

概要

• 説明責任のパラドックスは、AWS が複数のリージョンを提供しているかどうかではない。実際に提供している。問題は、顧客がプロバイダーのインシデント発生中に、障害が起きているコントロールプレーン、ID パス、DNS 管理 API、監視システム、サポートチャネルを先に呼び出すことなく、その多様性を利用できるかどうかである。存在していてもプロビジョニングされておらず、認証されておらず、監視できず、稼働中の設定変更なしには到達できない第 2 のリージョンは、在庫であって運用上の回復力ではない。
• 2025 年 10 月 19 日～20 日、DynamoDB の自動 DNS 管理システムにおける潜在的な競合状態により、US-East-1 のパブリックリージョナルエンドポイントがすべての IP アドレスを失った。3 つのアベイラビリティーゾーンで独立して稼働する 3 つの DNS Enactor は、1 つのリージョナルプランシーケンスと 1 つのクリーンアップロジックを共有していたため、障害を封じ込められなかった。自動化は不整合な状態に陥り、手動修復が必要になった。
• 約 3 時間後に DynamoDB エンドポイントの解決が復旧したからといって、リージョンが復旧したわけではない。EC2 のホスト管理システムはリースを失い、輻輳崩壊に陥った。ネットワーク状態の伝播にバックログが蓄積した。Network Load Balancer のヘルスチェックは、設定がまだ届いていない正常なキャパシティを削除した。依存サービスはさらに多くの時間にわたってスロットリング、障害、キュー枯渇を起こした。AWS は顧客影響の主な 3 つの期間を説明し、一部の Redshift の復旧は 10 月 21 日まで続いた。
• このイベントは、US-East-1 の全マシンが故障したわけではない。既存の EC2 インスタンスは正常なままだったし、一部の静的にプロビジョニングされたデータプレーンはサービスを継続した。障害が生じたのは、DynamoDB を見つける機能、新しいキャパシティを起動したりネットワーク接続する機能、イベントを処理する機能、一部のリクエストを認証する機能、異常なコンポーネントを交換する機能、そしてサポートやコンタクトセンター機能を運用する機能だった。この区別が、一部の顧客が生き残った理由と、従来のオートスケーリング設計が後の日中の負荷で失敗した理由の両方を説明している。
• 公共部門の記録は、普遍的な政府の停止を主張することなく、継続性の結果を具体的に示している。NOAA は、ほぼすべての NESDIS プロダクトが影響を受け、損失ではなく遅延となったと報告した。USPTO は、特許センターが断続的な中断に見舞われたと報告し、出願できないユーザーに代替出願方法を案内した。NASA の科学プラットフォームである Fornax は、計算リソースが割り当てられている間、ノートブックサーバーの起動がタイムアウトする可能性があると警告した。これらのケースはそれぞれ、時間依存のプロダクトの保護、法的提出経路の維持、代替計算機能へのアクセス維持という異なる継続性要件を示している。
• AWS は、マネージドサービスの内部構造、グローバルサービスのアーキテクチャ、復旧アルゴリズム、ステータス公開、修復の証拠をコントロールしている。顧客と下流のソフトウェアプロバイダーは、ワークロードの配置、事前プロビジョニング、依存関係のマッピング、縮退モード、独立した監視、継続性手順をコントロールしている。公的機関はまた、ミッションの分類、調達要件、非デジタルのフォールバックをコントロールしている。責任共有とは責任の平等ではない。それは、障害発生前に誰が失敗した機能を変更できたのかに従う。

リージョナルなプロダクトと非リージョナルな脱出問題

クラウドのセールスプロポジションは、選択可能な障害ドメインに基づいて構築されている。顧客は、リージョン内のアベイラビリティーゾーンにアプリケーションを分散し、別のリージョンにデータをレプリケートし、別の場所にウォームまたはアクティブなコピーを準備するためにお金を払うことができる。理論上は、それによって回復力は購入可能なプロパティになる。実際には、その購入が現実のものとなるのは、プライマリ環境が障害に陥っているときに、顧客がそれを行使できる場合のみである。

ここでコントロールプレーンのパラドックスが始まる。すでに稼働しているサーバーは、それを記述したり置き換えたりするための API が利用できなくても、処理を継続できる。DNS レコードは、それを変更する API がダウンしていても、回答を継続できる。別のリージョンのレプリカが正常でも、アプリケーションが依然として障害が起きたリージョナルエンドポイントにすべてのリクエストを送信しているかもしれない。サポートサービスは別のリージョンにフェイルオーバーしても、アカウントメタデータの依存関係が権威のあるように見えるが無効な回答を返すためにユーザーを拒否するかもしれない。

AWS 自身のグローバルサービスに関するフォールトアイソレーション境界のガイダンスは、この点について異常なほど明示的だ。標準商用パーティションでは、IAM、AWS Organizations、アカウント管理、Route 53 Public DNS、CloudFront、そしていくつかの関連コントロールプレーンが単一のリージョン（多くの場合 US-East-1）でホストされている。これらのデータプレーンはグローバルに分散されている可能性があり、その分離によって確立されたサービスが維持されることもある。しかし、このガイダンスは、復旧中にこれらのコントロールプレーンに依存しないよう顧客に伝え、それ以外はリージョナルなサービスにおけるオペレーションで、依然として Route 53 や他の単一リージョンの制御機能に依存するものを列挙している。

したがって、正しい説明責任の問いは「顧客は第 2 のリージョンを購入したか」ではない。問うべきは：顧客は、すでに稼働していて、障害が起きた権限を必要としない経路を用いて、第 2 のリージョンにエントリーし、観測し、認証し、ルーティングし、操作することができたか？

このテストはアーキテクチャ図よりも厳格だ。キャパシティが事前にプロビジョニングされていたか、データが十分に最新だったか、クレデンシャルとトラストポリシーが機能していたか、フェイルオーバー制御がデータプレーンアクションだったか、スタッフが独立した通信手段を持っていたか、ステータス証拠がプロバイダー外部から得られたか、システムの背後にある公共サービスが移行を許容できたか、といったことを問う。さらに、AWS が自らの復旧システムと顧客情報システムを、説明しようとしている障害の外部に保持していたかも問われる。

2025 年 10 月は、詳細な答えを提供した。一部は、静的安定性の理論が予測するとおりに機能した。既存の EC2 インスタンスは利用可能なままだった。他のリージョンの DynamoDB Global Tables レプリカは直接アドレス可能だった。他の部分は、隠れた制御依存関係の代償を露呈させた。リージョナルデータベースエンドポイントが消失し、ホストリースが期限切れになり、キャパシティを起動できず、新しいインスタンスにネットワーク状態がなく、ヘルスチェックが使用可能なロードバランサーキャパシティを撤回し、リージョナルフェイルオーバーにもかかわらずサポートアクセスがブロックされた。

2025 年 10 月の時計は 3 つの停止を内包していた

AWS の事後サマリーは、このイベントを太平洋時間 10 月 19 日午後 11 時 48 分から 10 月 20 日午後 2 時 20 分までとし、3 つの期間に分けている。DynamoDB API エラー、EC2 起動および接続障害、NLB 接続エラーである。この分け方は、イベントに 1 つの開始と 1 つの終了を割り当てるよりも正確だ。異なるサービス、制御パス、顧客のバックログが異なる時計で復旧した。

外部測定は、プロバイダーの説明の境界を検証するのに役立つ。Cisco ThousandEyes の停止分析は、Ashburn 近郊の AWS エッジでの初期パケット損失と、その後の復旧フェーズを経る中でのアプリケーションタイムアウトおよび 503 レスポンスを観測した。これらの観測はプロプライエタリな内部を明らかにすることはできないが、ネットワーク到達性とアプリケーションの準備が異なる時点で復旧したという結論を支持する。

AWS の公開イベント履歴は、当時のコミュニケーション記録として引き続き有用である。しかし、完全なフォレンジックレポートとして扱うべきではない。ステータス履歴は、プロバイダーが特定の時点で把握し公開することを選択した内容を報告するものであり、事後レポートはメカニズムとその後の調整を追加する。

このタイムラインは「DNS が修正された」が不十分な復旧声明である理由も示している。DNS 修復は DynamoDB への経路を復元したが、期限切れになったリース、キューイングされたネットワーク更新、作成されなかったインスタンス、スロットリングされたイベント配信、失敗したコンタクトセンターセッション、タイムアウトした顧客プロセスを復元したわけではない。復旧期間は、最初の欠陥の期間ではなく、依存する状態遷移の合計であった。

トリガーは DNS、根本原因は状態に対する共有権限だった

開始メカニズムは明確だった。DynamoDB は、大規模なリージョナルロードバランサーフリートのために数十万の DNS レコードを維持している。DNS Planner がエンドポイント、ロードバランサー、重みを記述するプランを作成する。3 つのアベイラビリティーゾーンで独立して稼働する DNS Enactor が、これらのプランを Route 53 を通じて適用する。適用前に、Enactor は自身のプランがすでに適用されたものより新しいことを確認する。

1 つの Enactor が異常に遅くなり、複数のエンドポイントにわたって更新を再試行した。それが進行している間に、Planner がより新しいプランを生成し、別の Enactor がそのうちの 1 つを迅速に適用した。次に、この新しい Enactor が古いプランのクリーンアップを開始した。その瞬間、遅延していた Enactor がメインの DynamoDB リージョナルエンドポイントに到達し、古いプランを適用した。その新しさのチェックはかなり前に行われており、今や期限切れだった。クリーンアップは、アクティブになったばかりの古いプランを削除した。すべてのエンドポイント IP アドレスが消え、自動化の状態は不整合になり、後続のプランを適用できなくなった。

「DNS エラー」という言葉は、顧客に見えるトリガーを説明している。これは制御の失敗を説明していない。より深い条件は以下の通り：

• 新しさのチェックが、各決定的な書き込み時にアトミックに行われるのではなく、複数エンドポイント操作の開始時に一度だけ行われた；
• 長時間の遅延の後、古いプランが新しい世代を上書きできた；
• クリーンアップが、プランがもはやアクティブでないことを証明せずにプランを削除できた；
• 別々のゾーンの独立したワーカーが、同じ順序付けと削除の前提を共有していた；
• 1 つのリージョナルプランが複数のエンドポイントタイプの管理を簡素化し、プランに付随する権限を増大させた；
• 無効な状態は自動化の自己修復エンベロープの外にあり、人間による復元が必要だった。

この区別が重要なのは、4 つ目の Enactor を追加しても、すべての Enactor が共有するプロトコルの欠陥を必ずしも解決しないからだ。アベイラビリティーゾーンはプロセスとインフラを分離したが、独立した正当性を生み出さなかった。冗長性は、同じ安全でない遷移を実行するアクターを増やしただけだった。

AWS の修復コミットメントは、その診断に従っている。同社は変更が行われるまで、世界中で Planner と Enactor の自動化を無効化し、競合状態を修正して不正なプランが適用されるのを防ぎ、1 つの NLB がアベイラビリティーゾーンのフェイルオーバー中に削除できるキャパシティの量に速度制限を設けることを提案し、EC2 復旧テストを追加し、ネットワーク状態伝播のためのキューを意識したレート制限を約束した。これらはキャパシティを単に拡大するよりも強力な対策である。なぜなら、権限と復旧速度を制約するからだ。

それでも、これらはプロバイダーが作成したレポートの中のコミットメントである。ここでレビューされた公開記録には、各アクションの展開日、テストカバレッジ、失敗したテストケース、残存例外、持続的パフォーマンスを示す独立監査されたクロージャーレジスターは含まれていない。因果関係の説明に対する信頼性は高いが、現在の修復の有効性に対する信頼性は依然として低い。

正常なサーバーは復旧可能なサービスではなかった

AWS は、イベント前に起動された EC2 インスタンスが正常なままだったことを正しく強調した。この事実は、US-East-1 が物理的にオフラインになったという不正確な主張に陥ることを防ぐ。また、顧客が購入していた正確なリスクを浮き彫りにする。

AWS は、コントロールプレーンをリソースの作成、記述、更新、削除、一覧を行うシステムと定義し、データプレーンはサービスの主要な作業を実行する。そのコントロールプレーンとデータプレーンのガイダンスは、EC2 の起動がホスト、ネットワークインターフェイス、ストレージ、クレデンシャル、セキュリティ設定を含む複雑なオーケストレーションである理由を説明している。実行中のインスタンスはよりシンプルだ。そのオーケストレーションが新しいものを作れない期間を生き延びることができる。

これは実用的な形の静的安定性である。サービスは変更を必要としないために生き残る。弱点が現れるのは、需要が上昇したとき、ホストが故障したとき、デプロイメントがキャパシティを置き換えたとき、証明書や秘密が更新を必要としたとき、コンテナが終了したとき、あるいはオペレーターがフェイルオーバーを試みたときである。そのとき、安定しているはずのサービスが、最も許容しがたいタイミングでコントロールプレーンを呼び出す。

Buildkite の顧客事後インシデントレビューは、遅延する障害を示している。同社の顧客体験は当初安定していた。米国のビジネストラフィックが増加するにつれて、EC2 の起動障害がオートスケーリングを妨げ、シャードがそれぞれの異なるキャパシティ余裕を使い果たし、AWS インシデント開始から数時間後にレイテンシーとエラーが上昇した。Buildkite は、デプロイメントを一時停止してキャパシティを温存し、その後、負荷を普段は使用していないシャードに移動した。決定的な回復力資産は、オートスケーリングポリシーの存在ではなく、すでに稼働している予備のコンピュートだった。

Postman は第 2 の結合形態を示した。同社の停止レビューによれば、重要なフローが損なわれ、AWS でホストされたステータスページがコミュニケーションを遅延させ、内部インシデントチャネルの自動作成が影響を受けたインフラに依存していた。Postman は自らの責任分担を認め、グレースフルデグラデーション、マルチリージョン機能、冗長化されたコミュニケーション、そして最終的にはリージョンとプロバイダーをまたいだアクティブ-アクティブ運用に取り組んでいることを説明した。これは正しい割り当てである。AWS が上流の障害を所有し、Postman が顧客コミュニケーションと調整をそれに継承させる決定を所有する。

したがって、10 月のイベントは、顧客アーキテクチャを「シングルリージョン」と「マルチリージョン」という区分よりも有用なカテゴリに分ける。

1. 稼働中だが変更依存。既存のサービスは、スケーリング、置き換え、デプロイメント、クレデンシャル更新が制御アクティビティを必要とするまで継続する。
2. マルチゾーンだがリージョン制御依存。物理的なゾーン障害はカバーされるが、共有されたリージョナルエンドポイント、コントロールプレーン、復旧システムは依然として共通のままである。
3. マルチリージョンだがアクティベーション依存。データとテンプレートは他の場所に存在するが、フェイルオーバーにはプロビジョニング、IAM 変更、Route 53 変更、または利用できないオペレーターが必要となる。
4. 静的に安定したマルチリージョン。キャパシティ、データパス、ID、ヘルスチェック、ルーティング制御がすでに利用可能であり、フェイルオーバーは事前配置されたデータプレーンメカニズムを使用する。
5. プロバイダー多様化または手動連続。重要なサブセットが AWS の外部で実行できるか、またはクラウド運用が経済的でない場合に、公共機能が制限された非デジタルプロセスを通じて継続される。

第 4 および第 5 のカテゴリだけが、コントロールプレーンのパラドックスに直接答えている。他のカテゴリも、影響の少ないワークロードにとっては合理的な選択であり得るが、それらを同等の回復力として提示すべきではない。

復旧自動化が第 2 のインシデントになった

DynamoDB DNS が復旧すると、EC2 の DropletWorkflow Manager は管理対象の物理ホストとのリースを再確立しようとした。エンドポイント停止中に、それらのリースはタイムアウトしていた。アクティブなリースを持たないホストは、新しいインスタンスを安全に受け入れることができなかった。フリートの試行には長い時間がかかり、作業は期限切れとなり再キューイングされた。AWS は、システムが輻輳崩壊を起こし、その復旧状態のための確立された手順がなかったと述べている。

これは重要な告白である。元々の競合状態は稀な順序障害だった。長期化した EC2 の機能障害は、予見可能な部類の復旧負荷に起因した：多くの期限切れオブジェクトが一斉に最新になろうとしたのだ。正確な規模は例外的だったかもしれないが、キュー、タイムアウト、リトライ、リースはごく普通の分散システムのメカニズムである。復旧設計は、定常状態のパフォーマンスや段階的なホスト喪失だけでなく、復元が期待されるフリートサイズでテストされなければならない。

次のフェーズでは、依存性が実行中のトラフィックに可視化された。Network Manager が、新しいまたは変更されたインスタンスの設定バックログを伝播しなければならなかった。一部の新しいインスタンスは、ネットワーク状態が完了する前に存在していた。NLB ヘルスチェックは障害を検出し、正常と異常の間で揺れ動き、ノードとターゲットを DNS から削除した。チェックシステム自体も負荷がかかり、自動アベイラビリティーゾーンフェイルオーバーはマルチゾーンロードバランサーからキャパシティを削除した。AWS は、誤解を招く証拠に基づいて動作するのを止めるために、午前 9 時 36 分に自動保護を無効化した。

単独で見れば、どのコンポーネントも不合理に動作したわけではない。リース管理は、所有されていないホストを拒否した。Network Manager は設定をキューイングした。ヘルスチェックは到達不能なターゲットを削除した。アベイラビリティーゾーンフェイルオーバーは、機能不全のキャパシティを引き揚げた。カスケードが発生したのは、各メカニズムが部分的な復旧を通常の局所的な障害と解釈したからである。説明責任はシステム横断設計にある。復旧状態は、ある安全制御が一時的に不完全であることを理由に別のシステムを罰しない程度に適切に表現されなければならない。

下流の影響はサービス固有だった。Lambda は同期呼び出しを保護するために非同期およびキュー駆動の作業をスロットリングした。ECS、EKS、Fargate は起動とスケーリングの障害を経験した。Amazon Connect は、着信および発信の障害、ビジートーン、無音、音声メッセージと通話ルーティングの障害、コンタクトセンタースタッフのサインイン問題、遅延レポートを経験した。STS は 2 度のエラー率上昇を経験した。Redshift は、リージョナル依存性と、全リージョンから US-East-1 に IAM グループ解決リクエストを送る欠陥の両方を抱えていた。ローカルデータベースユーザーは、その特定のクロスリージョン障害の影響を受けなかった。

この Redshift の詳細は特に示唆的だ。リソースは物理的に US-East-1 の外部に位置していても、実装上の選択のためにそこのエンドポイントを呼び出すことがある。地理的デプロイメントと依存関係の地理は同一ではない。顧客は後者のマップを必要とするが、プロバイダーだけがすべての内部サービス間依存関係を権威的に開示できる。

ステータスとサポートは安全システムの一部である

クラウドインシデントの間、顧客は自分の欠陥なのか、アカウント固有の制限なのか、リージョナルイベントなのか、グローバルな依存関係なのかを見極める必要がある。フェイルオーバーするか、デプロイメントを凍結するか、負荷を削減するか、キューを保持するか、手動の継続性を呼び出すかを決定する必要がある。したがって、ステータス情報は事後の広報ではなく、運用管理の一部である。

2025 年 10 月、AWS Support Center は別のリージョンにフェイルオーバーした。しかし、アカウントメタデータサブシステムが応答を返し、合法的なユーザーがケースを閲覧または更新するのをブロックした。AWS は障害応答のためのバイパスを設計していたが、依存関係が代わりに無効な応答を返した。午後 11 時 48 分から午前 2 時 40 分まで、顧客はコンソールや API を通じてサポートケースを作成、閲覧、更新できなかった。

これは古典的な意味的障害の問題である。依存関係は、利用不可、遅延、誤り、古い、または確信を持って間違っている可能性がある。タイムアウトのみを処理するフェイルオーバーロジックは、誤った権限を返すシステムから独立していない。サポート継続性は、アカウント状態の意味を検証し、境界付けられた最後の既知の良好なパスを保持し、深刻なプロバイダーイベントのために別途認証された経路を提供しなければならない。

記録は改善と再発を同時に示している。2021 年 12 月 7 日のAWS サービスイベントでは、AWS の内部ネットワークとメインネットワーク間の輻輳が、監視、デプロイメントツール、コントロールプレーン、サポートコンタクトセンター、サービスヘルスダッシュボードの予備リージョンへのフェイルオーバーを損なった。AWS は複数リージョンでアクティブな新しいサポートアーキテクチャを約束した。2025 年に Support Center は設計どおりにリージョンを移動したが、これはアーキテクチャの進歩の証拠である。しかし、そのメタデータ依存性が依然としてサービスが目的を果たすのを妨げた。

顧客はまた、AWS の公開ステータスを個人化された証拠と区別する必要がある。現在のAWS Health Dashboard のドキュメントには、署名のない公開ページは公開サービスイベントを表示し、サインインしたビューはアカウント固有のイベントとリソースを提供すると記載されている。AWS は EventBridge を通じたプログラムによる監視を推奨している。その公開イベントとアカウント固有のヘルスイベントに関するガイダンスは、イベントを代替リージョンに配信できるようにバックアップルールを推奨している。AWS のリージョナルイベントルールガイダンスは、IAM 通知などのグローバル Health イベントには US-East-1 のルールが必要であると述べており、これは独立性を仮定するのではなくテストするもう一つの理由である。

どの組織も 1 つのチャネルに依存すべきではない。防御的な体制は、プロバイダーの公開ヘルス、複数リージョンで配信されるアカウント固有のイベント、別のプロバイダーまたはオンプレミスネットワークからの合成プローブ、アプリケーションレベルのビジネスメトリクス、そして独立したホスティングと ID を持つインシデントページを組み合わせる。連絡先リスト、ブリッジ詳細、意思決定のしきい値は、通常のクラウドアカウントなしで取得できるべきである。

公共サービスへの影響は継続性の問題であってウェブサイトの数ではない

10 月の障害は、単純な停止総数を誤解を招く方法で公共システムに到達した。最良の証拠はサービス固有のものである。

NOAA は、National Centers for Environmental Information のクラウド施設が UTC 06:57 頃に低取り込みアラームを受信し始めたと報告した。NOAA/NESDIS の運用メッセージは、ほぼすべての NESDIS プロダクトが影響を受け、データは損失ではなく遅延したように見えると述べた。これは永続的なデータ破壊とは物質的に異なる結果である。それでも深刻であり得る。環境プロダクトは時間依存であり、6 時間の遅延は観測を予報、計画、下流の分析に使用する時間を圧縮する可能性がある。

USPTO は、その特許センターが断続的な中断を経験し、出願を提出できないユーザーに代替出願方法を案内したと発表した。この通知は成熟した継続性の原則を示している。法的または管理上の機能は出願であり、1 つの Web アプリケーションの可用性ではない。代替経路は、主要インターフェースが劣化しても機能を保持する。記録は、何人のユーザーが代替手段を利用したか、すべての出願が期限を守れたか、なぜインシデントが 10 月 23 日まで解決とマークされなかったのかを確立していない。これらの疑問は未解決のままであるべきである。

NASA の Fornax 科学プラットフォームは、ノートブックサーバーの起動がタイムアウトする可能性があると警告し、その間に計算リソースが割り当てられていた。これは EC2 コントロールプレーンの障害に直接対応している。研究が停止するために、既存の科学データやノートブックが消える必要はない。作業環境を割り当てられないことで十分だからだ。

これらの記録は、AWS を使用するすべての政府サービスが影響を受けたこと、このイベントによって緊急通報が失敗したこと、あるいは何らかの公共安全上の結果が生じたことを証明するものではない。これらは、調達がデータの保管場所だけを見てはならない理由を示している。公共サービスは、プロダクト生成、出願、分析、コミュニケーション、またはデータを調査するための計算のためにクラウド制御に依存し得る。

CISA の 2024 年 8 月の公共安全通信依存関係に関するペーパーは、非機関インフラが相関する継続性リスクをもたらす可能性があると警告し、明示的な冗長性、ダウンタイム手順、バックアップ、人員配置、サポート要件を推奨している。CISA のより広範なインフラ依存関係入門は、冗長プロバイダーが他のシステムでも共有されているかどうか、および回避策がどれだけ持続できるかを問うている。これらの問いはクラウドアーキテクチャにぴったり当てはまる。

公的機関は継続性をミッションレベルで分類すべきである。

• クラウド制御が 3 時間、15 時間、48 時間利用できなくても、それでも生み出されなければならない成果は何か？
• すでに稼働中のキャパシティで継続できる作業は何か、そしてどの程度の需要余裕が存在するか？
• どの記録が遅延する可能性があり、どの法的または安全上の期限が代替経路を必要とするか？
• スタッフは、影響を受けたプロバイダーなしで認証し、コミュニケーションし、公共の助言を公開できるか？
• 第 2 のリージョンは実際にアクティブか、それとも組織は障害が起きたコントロールプレーンを通じてプロビジョニングしなければならないか？
• 手動プロセスが作業を受け入れ、タイムスタンプ付きの受領証を作成し、整合性を失わずに後で調整できるか？
• 契約は、イベント後のクレジットだけでなく、技術的証拠とサポート経路を提供しているか？

NIST のコンティンジェンシー計画ガイダンスは、ビジネス影響、復旧優先順位、代替処理、テストされた計画を中心にしているため、依然として適切である。技術は変わったが、公共機能を保持する義務は変わっていない。

US-East-1 には 1 つの再発するバグではなく、記録がある

北バージニアでのすべてのイベントを同じコントロールプレーンの欠陥として説明するのは誤解を招く。メカニズムは異なる。この記録の価値は、異なるトリガーが、範囲、内部依存性、復旧速度、顧客の可視性に関する共通の疑問を繰り返し露呈させたことにある。

2012 年のサービスサマリーは、パラドックスの初期の声明である。停止中は顧客がリソースを作成または移動しようとするため、コントロールプレーンが特に重要である。2017 年の S3 レポートは、意図された以上の権限を持つ運用コマンドと、リージョンの新しい規模では経験されたことのない再起動時間を示した。2020 年の Kinesis レポートは、トリガーと根本原因を明示的に分離し、その後、何時間にも及ぶ制御されたフリート再起動とステータスツールの依存関係を説明した。2021 年のレポートは、プロバイダー自身の可視性低下とデプロイメント障害を露呈させた。

繰り返されるパターンは、特定のオペレーターの過失でもなく、AWS が学んでいない証拠でもない。それは、規模が安全な操作の意味を変えること、冗長コンポーネントが 1 つの論理的障害を共有できること、復旧需要が定常状態の需要よりも大きくなり得ること、インシデントツールが本番環境と運命を共にし得ることである。したがって、各事後アクションは、単に前回とまったく同じトリガーに対してではなく、次のメカニズムに対してテストされるべきである。

学習の証拠はある。2025 年の Support Center は、2021 年のアーキテクチャではケース作成を保護していなかったリージョナルフェイルオーバーを備えていた。DynamoDB は 3 つの独立した DNS Enactor を使用した。EC2 は既存のインスタンスを保存した。Global Tables レプリカは他の場所でアドレス可能なままだった。AWS は異常に詳細な因果レポートを公開した。残された問題は、これらの制御が、クリーンな停止ではなく、遅延、古い、または無効な状態を受け取ったときに安全に失敗するかどうかである。

実際に購入できる回復力とは

AWS の現在の信頼性の柱は、顧客に復旧目標を定義し、災害復旧をテストし、ゲームデイを実施し、静的安定性を利用し、復旧中はデータプレーンに依存するよう指示している。具体的なREL11-BP04 ガイダンスは、インシデント中に DNS レコードを変更すること、フェイルオーバーリソースが十分にプロビジョニングされていないためにコントロールプレーンのキャパシティをスケーリングすること、または管理 API の連鎖に依存することを、一般的なアンチパターンとして挙げている。

このガイダンスは技術的に健全である。また、請求書を定義する。静的安定性とは、必要になる前にリソースに支払い、予備キャパシティを削除するようなデプロイメントを制約し、別のリージョンで ID とデータを準備し、データプレーンがすでに分散されたルーティング制御を運用することを意味する。バックアップにしか支払っていない顧客は、データ保護を購入したに過ぎず、即時のサービス継続性を購入していない。パイロットライトを持つ顧客は、より高速な再構築を購入したのであり、コントロールプレーン障害からの免疫ではない。ウォームスタンバイを持つ顧客は、プロビジョニングされたままの状態で約束された負荷を処理できない限り、スケーリング依存性のあるキャパシティを購入したことになる。

AWS の災害復旧オプションは、バックアップ・リストア、パイロットライト、ウォームスタンバイ、アクティブ-アクティブモデルを説明している。また、最大の回復力のためにはデータプレーン操作のみを使用するようアドバイスしている。この含意はビジネスケースに書き込まれるべきである。つまり、低コストでは一般に、障害発生時により多くのコントロールプレーン作業が必要となる。ワークロード所有者は、そのトレードオフが受容可能かを判断し、経営陣は承認した影響耐性に合致する回答に資金を提供しなければならない。

マルチリージョンは自動的な判定ではない。2025 年のイベント中、US-East-1 外の DynamoDB Global Tables レプリカは利用可能だったが、アプリケーションはそれらへのテストされた経路、許容可能な整合性動作、十分なキャパシティ、復旧したレプリカを調整する方法を依然として必要とした。ID ポリシー、KMS キー、シークレット、証明書、コンテナイメージ、キュー、可観測性、サードパーティ API すべてが同じレビューを必要とする。2 つのデータベースアイコンを示す図は、完全なビジネストランザクションが両方の場所で完了できることを証明しない。

マルチクラウドも自動的な判定ではない。すべてのマネージドサービスを第 2 のプロバイダーに対して再構築すると、データの不整合、運用エラー、より高いコスト、緊急時のみ訓練されるプラットフォームをもたらす可能性がある。最新の連邦クラウド調達に関する GAO レビューは、複数のベンダーを利用する機関が相互運用性、人員、ツール、管理の課題にも直面していることを発見した。このレポートは、国防総省が提供したより有用な定式化を記録している。すなわち、プロバイダー固有のキャパビリティすべてを本質的に間違っていると扱うのではなく、集中リスクを管理し、アーキテクチャ認識を維持し、ミッションクリティカルなワークロードのための出口戦略を持つことである。

現実的な答えは、選択的な独立性である。最も時間依存の高いパスをリージョン間で静的に安定させる。完全なサービスが高すぎる場合は、小規模な読み取り専用または受付モードを保持する。別のプロバイダーが必要になる可能性のある機能には、オープンデータ形式とテスト済みエクスポートを使用する。法的および公共の義務が許す場合、手動またはオフラインプロセスを維持する。公的情報ページ、給付金支払い指示、内部分析ジョブ、安全派遣機能に同等の回復力予算を費やしてはならない。それらの結果は異なるからだ。

責任は、結果を変え得た能力に従う

「責任共有」は、すべての失敗を均等に分割するために使用されると、霧になり得る。AWS 自身の回復力モデルは、クラウドインフラストラクチャとマネージドサービスの回復力を AWS に割り当て、顧客は構成、配置、レプリケーション、バックアップ、ワークロードアーキテクチャを選択する。この分割は、具体的な制御能力に変換されて初めて有用である。

この割り当ては 2 つの誤りを回避する。顧客は DynamoDB の DNS Enactor にパッチを当てたり、AWS 内部で EC2 復旧手順を作成したりすることはできない。AWS は、市の提出ポータルがアクティブ-アクティブ運用を正当化するか、または公共機関が許容可能な手動受付プロセスを持つかを決定できない。下流の SaaS 企業は、自身のステータスページを同じ障害ドメインにホストしたことを AWS のせいにできないが、アーキテクチャ訓練だけで開示されていないプロバイダー内部を発見することもできない。

責任は、サービスの抽象度によっても変わる。EC2 を管理する顧客はより多くの選択肢とより多くの作業を持つ。DynamoDB を購入する顧客は、より多くのプラットフォーム運用を委任し、AWS がサービスの内部 DNS と復旧を正しく管理することを期待すべきである。顧客は依然としてレプリケーションとアプリケーションフェイルオーバーを制御する。マネージドサービスは顧客の継続性義務を排除せず、顧客が制御できる内部を狭め、プロバイダーが使用可能な障害境界を開示する義務を増大させる。

クレジットはサービス指標に価格をつけるが、公共の結果にはつかない

商業的アカウンタビリティには、狭い契約層とより広い運用層がある。現在のDynamoDB SLAは、月次リージョナルアップタイムレベルを約束し、適格な Global Tables の使用にはより高い目標を設定している。明記された救済策は、一般に、適格性、計算、除外、ログ、および AWS Support を通じて提出された請求を条件とするサービスークレジットである。

このメカニズムは測定可能なサービスコミットメントを強制できる。しかし、遅延した環境プロダクト、失われた開発者作業、失敗した顧客通話、失われた下流トランザクション、手動処理に転用された公共スタッフの全コストを償還するものではない。また、SLA は特定の顧客が責任を持って設計したかどうかを決定するものでもない。契約条件は様々であり、本分析は AWS がいかなる顧客に対しても準拠法上の合意を超える損害賠償を負うとの認定を行うものではない。

2025 年のイベントは、法的欠陥を証明することなく手続き上の皮肉を露呈させる。標準的なクレジットプロセスは Support Center を使用するが、初期の DynamoDB フェーズでは Support ケース機能が利用不能だった。顧客は後日請求期間があったため、一時的なブロックが必ずしも請求を妨げたわけではない。しかし、クレジットに必要な証拠が影響を受けた監視スタックの外部で収集されるべき理由を示している。CloudWatch、アプリケーションログ、合成プローブ、プロバイダーイベント、顧客トランザクション記録、手動インシデントノートは独立して保持されるべきである。

プロバイダーの規模はガバナンスへの期待を高める。Amazon の 2025 年Form 10-Kは、AWS の純売上高を 1,287 億 2,500 万ドル（20％増）と報告し、システム中断と不完全な冗長性によるリスクを別途認識している。収益は過失の証拠ではない。それはキャパシティ、リーチ、そして信頼性管理、透明な事後報告、修復保証が慈善的な追加物ではなく中核的な製品義務である経済関係の証拠である。

結論を変える可能性のある証拠

現在の結論は、AWS が実質的な物理的およびデータプレーンの回復力を提供したが、2025 年 10 月のイベントは、リージョナル DNS 自動化における予防可能な共通前提と、不十分に準備された復旧パスを露呈させた、というものである。顧客は意味のある回復力を購入できたが、それはサービスを事前配置し、AWS 自身が文書化しているコントロールプレーン依存関係を回避することによってのみ可能だった。一部のクロスリージョン依存関係とサポート依存関係は、地理だけから顧客が合理的に推測できるよりも独立性が低かった。

以下の種類の証拠があれば、その判断はより好ましいものになるだろう。

• DNS 競合状態修正、エンドポイントごとの新しさの強制、アクティブプランの削除保護、不整合なプラン状態からの自動復旧に関する日付入りの公開クロージャー記録。
• 遅延した Enactor、古い世代、同時クリーンアップ、部分的な Route 53 書き込み、失敗した復旧がリージョナルエンドポイントを削除できないことを示すフォールトインジェクション結果。
• 現実的な US-East-1 規模での EC2 テストが、輻輳崩壊なしに制限時間内に完全なリース再構築が完了することを示すもの。
• Network Manager のキュー深度とアドミッション制御の証拠で、10 月のものより大きなリージョナルバックログ下での挙動を含む。
• 速度制御が、偽のヘルス遷移がマルチゾーンキャパシティを過度に削除するのを防ぐことを証明する NLB テスト。
• US-East-1 外のワークロードに影響を与える可能性のあるグローバルまたは単一リージョンの制御操作を特定し、経時的な変更を追跡したサービス依存関係の目録。
• ID、アカウントメタデータ、コンソール、EventBridge 配信、1 つのリージョンがそれぞれ独立して障害を起こすサポートおよび AWS Health の演習の実証。
• エンドポイント修復、コントロールプレーン修復、データプレーンの安定性、バックログクリアランス、リソース調整を分離した顧客向け復旧メトリクス。
• 深刻なインシデントの是正措置の完了と持続性をサンプリングする独立した保証。

証拠が結論をより不利にすることもあり得る。自動化が再有効化された後に同じ競合状態が繰り返される、確立された手順なしの別のフリート復旧、文書化されていない US-East-1 へのクロスリージョン呼び出し、または同じメタデータパスを通じたステータスとサポートの障害は、修復が症状を扱ったに過ぎず、権限境界を扱わなかったことを示す。停止時間が短いだけでは問題は解決しない。幸運なワークロードパターンが安全でない制御を隠すことがあるからだ。

顧客の証拠も重要である。完全なリージョナルゲームデイ、独立した通信、セカンダリリージョンの最新データ、事前プロビジョニングされたキャパシティ、境界付けられた手動サービス、成功した期限調整を示すことができる公共機関は、クラウドの多様性を継続性に変換したことになる。バックアップやテンプレートを「マルチリージョン」とラベル付けしながら、時間を計測した演習を行っていない顧客は、そうではない。

AWS は、重要なコントロールプレーン障害やインフラ影響を含む広範なイベントについて、いつ公開事後サマリーを発行するかについて有用な基準を公開している。このアーカイブは価値がある。より強力な保証は、各深刻なレポートを永続的なアクション・レジスターに結びつけ、顧客や公共購入者が発表された修正と、テストされ、完了し、持続されている制御を区別できるようにすることである。

アカウンタビリティの結論

2025 年 10 月の停止は、時間について意見が一致しない 2 つの自動化から始まった。1 つは古いプランをゆっくりと適用し、別のものは新しいプランを適用して古いものを削除し、一緒になってリージョナルデータベースサービスのアドレスを消し去った。長いインシデントは、そのアドレスを信頼していたすべてのものと、それが不在の間に劣化した状態に起因した。

AWS はクラウド内部のその連鎖を所有している。同社はプランプロトコル、クリーンアップ権限、ホストリース、復旧キュー、ヘルスチェック、サービス依存関係、サポートパスを設計した。事後レポートは技術的に具体的であり、即時の修復措置は開示されたメカニズムに合致しており、既存の EC2 インスタンスの保存はコントロールプレーン分離の価値を証明している。未解決のアカウンタビリティ問題は、修正がリージョナルスケールで機能すること、そして隠れたクロスリージョン依存関係が顧客が行動できるほど十分に可視化されていることの証明である。

顧客は異なる連鎖を所有している。ピーク需要が稼働中のキャパシティで処理できるか、レプリカが新たな制御アクションなしで到達できるか、ステータスとインシデント調整が独立しているか、ビジネスまたは公共機能が安全に縮退できるかを決定する。Buildkite の枯渇したシャードと Postman の損なわれたステータス経路は、AWS の障害の原因ではなく、インパクトの顧客制御の増幅要因だった。NOAA の遅延したプロダクト、USPTO の代替出願パス、NASA の割り当て警告は、乗数がサーバー数ではなく運用上の用語で評価されなければならない理由を示している。

中心的なテストに今答えることができる。顧客は AWS 上でリージョナルな回復力を購入できるが、第 2 のリージョンは購入の十分な証拠ではない。使用可能なプロダクトは完全な復旧パスである。すでにプロビジョニングされ、すでに認証され、すでに可観測であり、すでにルーティング可能であり、プライマリコントロールプレーンなしでリハーサルされたものだ。グローバルな制御やプロバイダー内部が依然として US-East-1 に収束する場合、AWS は依存関係を取り除くか、安全なデータプレーンの代替を明確にするか、制限を率直に述べなければならない。

クラウドの集中はしばしば市場シェアとして議論される。より直接的な集中は実行可能な権限である。1 つのプラン、1 つのエンドポイント、1 つのメタデータ回答、1 つのヘルスの解釈、または 1 つのサポート依存関係が、多くの冗長システムを同じように振る舞わせ得る。説明責任は、次のインシデントの前にその権限を名指しし、それが誤っているときに別のパスが依然として存在することを証明することから始まる。