お客様が離れられるが常に逃れられるわけではない地域：AWS US-East-1 とレジリエンスの代償

概要

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

地域製品と非地域的な脱出問題

クラウドのセールスプロポジションは、選択可能な障害ドメインを中心に構築されています。顧客はリージョン内のアベイラビリティーゾーン全体にアプリケーションを分散し、データを別のリージョンに複製し、そこにウォームまたはアクティブなコピーの料金を支払うことができます。理論的には、これによりレジリエンスが購入可能な特性になります。実際には、購入が現実になるのは、顧客がプライマリ環境が損なわれている間にそれを行使できる場合のみです。

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

AWS 自身のグローバルサービスに関するフォールトアイソレーション境界ガイダンスは、これについて異常に明確です。標準の商用パーティションでは、IAM、AWS Organizations、Account Management、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 起動および接続障害、ネットワークロードバランサー接続エラー。これは、イベントに1つの開始と1つの終了を割り当てるよりも正確です。異なるサービス、制御経路、顧客バックログは異なる時計で復旧しました。

外部測定は、プロバイダーアカウントの境界をテストするのに役立ちます。Cisco ThousandEyes の障害分析は、アッシュバーン近くの AWS エッジでの早期のパケット損失を観測し、その後、障害が復旧フェーズを移動するにつれて、アプリケーションのタイムアウトと503応答が後続したと報告しています。これらの観測はプロプライエタリな内部を明らかにすることはできませんが、ネットワークの到達可能性とアプリケーションの準備が異なる時間に復旧したという結論を支持しています。

AWS の公開イベント履歴は、同時代のコミュニケーション記録として依然として有用です。それは完全なフォレンジックレポートとして扱われるべきではありません。ステータス履歴は、プロバイダーが特定の時点で知っていて公開することを選択したものを報告します。イベント後のレポートはメカニズムと後日の調整を追加します。

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

トリガーは DNS でしたが、根幹は状態に対する共有された権限でした

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

1つの Enactor が異常に遅くなり、いくつかのエンドポイントにわたって更新を再試行しました。それが進行している間に、Planner はより新しいプランを生成し、別の Enactor がそのうちの1つを迅速に適用しました。その後、新しい方の Enactor は古いプランのクリーンアップを開始しました。その時点で、遅延していた Enactor が主要な DynamoDB リージョナルエンドポイントに到達し、古いプランを適用しました。その新鮮さチェックはずっと前に実行されており、今では古くなっていました。クリーンアップは、つい先ほどアクティブになったばかりの古いプランを削除しました。すべてのエンドポイント IP アドレスが消失し、自動化の状態はそれ以降のプランを適用できないほど不整合になりました。

「DNS エラー」は顧客に見えるトリガーを説明します。コントロールの失敗を説明するものではありません。より深い条件は次のとおりでした：

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

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

AWS の是正措置の約束はその診断に従っています。同社は、変更が行われるまで世界中で Planner と Enactor の自動化を無効にし、競合状態を修正し、誤ったプランが適用されるのを防ぐことを約束し、NLB がアベイラビリティーゾーンフェイルオーバー中に削除できる容量に速度制限を提案し、EC2 復旧テストを追加し、ネットワーク状態伝搬のキュー認識型レート制限を約束しました。これらは単に容量を拡大するよりも強力な措置であり、権限と復旧速度を制約するためです。

これらは依然としてプロバイダー作成レポート内の約束です。ここでレビューされた公開記録には、すべてのアクションの展開日、テスト範囲、失敗したテストケース、残っている例外、および持続的なパフォーマンスを示す、独立して監査されたクロージャレジストリは含まれていません。因果関係の説明に対する信頼は高くても、現在の是正措置の有効性に対する信頼は低いままです。

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

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

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

これは実際の形式の静的安定性です。サービスは変更する必要がないため存続します。弱点は、需要が増加したとき、ホストが故障したとき、デプロイメントが容量を交換したとき、証明書やシークレットの更新が必要なとき、コンテナが終了したとき、またはオペレーターがフェイルオーバーを試みたときに現れます。そのとき、安定しているとされていたサービスが最も許容されない瞬間にコントロールプレーンを呼び出します。

Buildkite の顧客ポストインシデントレビューは、遅延した障害を例示しています。その顧客体験は当初安定していました。米国のビジネストラフィックが増加するにつれて、EC2 起動の失敗がオートスケーリングを妨げ、シャードはそれぞれのキャパシティマージンを使い果たし、AWS インシデントの開始から数時間後にレイテンシとエラーが上昇しました。Buildkite はデプロイメントを一時停止して容量を維持し、その後負荷を別の未使用のシャードに移しました。決定的なレジリエンスの資産は、予備の、すでに実行中のコンピュートであり、オートスケーリングポリシーの存在ではありませんでした。

Postman は別の形の結合を文書化しました。その障害レビューによると、重要なフローが損なわれ、AWS ホストのステータスページがコミュニケーションを遅らせ、内部インシデントチャネルの自動作成が影響を受けたインフラに依存していました。Postman は自身の責任の一部を受け入れ、グレースフルデグラデーション、マルチリージョン能力、冗長通信、そして最終的にはリージョンとプロバイダー間でのアクティブ-アクティブ運用に取り組んでいると説明しました。これは適切な割り当てです。AWS は上流の障害を所有し、Postman は顧客とのコミュニケーションと調整をそれに継承させる決定を所有します。

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

1. 実行中だが変更依存。既存のサービスは、スケーリング、交換、デプロイ、または認証情報の更新に制御アクティビティが必要になるまで継続する。
2. マルチゾーンだがリージョン制御依存。物理ゾーン障害はカバーされるが、共有リージョナルエンドポイント、コントロールプレーン、復旧システムは共通のまま。
3. マルチリージョンだがアクティベーション依存。データとテンプレートは他の場所に存在するが、フェイルオーバーにはプロビジョニング、IAM 変更、Route 53変更、または利用不可のオペレーターが必要。
4. 静的に安定したマルチリージョン。容量、データパス、アイデンティティ、ヘルスチェック、ルーティング制御がすでに利用可能で、フェイルオーバーは事前配置されたデータプレーン機構を使用する。
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 サポートセンターは別のリージョンにフェイルオーバーしました。しかし、アカウントメタデータサブシステムが正当なユーザーがケースを表示または更新するのをブロックする応答を返しました。AWS は失敗した応答に対するバイパスを設計していましたが、依存関係が無効な応答を返したのです。午後11時48分から午前2時40分まで、顧客はコンソールまたは API を通じてサポートケースを作成、表示、更新できませんでした。

これは古典的なセマンティック障害問題です。依存関係は、利用不可、低速、誤り、古い、または自信を持って誤っている可能性があります。タイムアウトのみを処理するフェイルオーバーロジックは、誤った権限を返すシステムから独立していません。サポート継続性は、アカウント状態の意味を検証し、限定された最終既知正常パスを保持し、深刻なプロバイダイベントのために別途認証されたルートを提供する必要があります。

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

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

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

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

10月の障害は、単純な停止合計を誤解させる方法で公共システムに達しました。最も良い証拠はサービス固有です。

米国海洋大気庁（NOAA）は、その国立環境情報センターのクラウド施設が UTC 06:57頃に低取り込みアラームを受け取り始めたと報告しました。NOAA/NESDIS の運用メッセージは、事実上すべての NESDIS 製品が影響を受け、データは喪失ではなく遅延したように見えると述べました。これは恒久的なデータ破壊とは質的に異なる結果です。依然として深刻であり得ます。環境製品は時間に敏感であり、6時間の遅延は、観測を予報、計画、または下流の分析で使用するために利用可能な時間を圧縮する可能性があります。

米国特許商標庁（USPTO）は、Patent Center が断続的な中断を経験し、提出ができないユーザーに代替提出方法を指示したと述べました。その通知は成熟した継続性の原則を示しています。法的または管理的機能は提出であり、単一のウェブアプリケーションの可用性ではありません。代替経路は、プライマリインターフェースが劣化している場合でも機能を保存します。記録は、代替を呼び出したユーザーの数、すべての提出が期限に間に合ったかどうか、インシデントが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年のサポートセンターにはリージョナルフェイルオーバーがあり、2021年のアーキテクチャはケース作成を保護していませんでした。DynamoDB は3つの独立した DNS Enactor を使用しました。EC2 は既存のインスタンスを維持しました。Global Tables レプリカは他の場所でアドレス指定可能なままでした。AWS は異常に詳細な因果関係レポートを公開しました。残された問題は、これらの制御がクリーンな停止ではなく、遅い、古い、または無効な状態を受け取ったときに安全に失敗するかどうかです。

実際に購入できるレジリエンスとは

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

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

AWS の災害復旧オプションは、バックアップと復元、パイロットライト、ウォームスタンバイ、アクティブ-アクティブモデルを説明しています。また、最大のレジリエンスのためにデータプレーン操作のみを使用するようアドバイスしています。その含意はビジネスケースに書き込まれるべきです。より低いコストは一般に、障害の瞬間により多くのコントロールプレーン作業を購入します。ワークロード所有者はそのトレードオフが許容可能かどうかを決定しなければならず、経営陣は承認した影響許容度に一致する答えに資金を提供しなければなりません。

マルチリージョンは自動的な答えではありません。2025年のイベント中、US-East-1 外の DynamoDB Global Tables レプリカは利用可能でしたが、アプリケーションは依然としてそれらへのテスト済みルート、許容可能な一貫性動作、適切な容量、および復旧したレプリカを調整する方法を必要としていました。アイデンティティポリシー、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 サポートを通じて提出された請求に従うサービス・クレジットです。

そのメカニズムは測定可能なサービスコミットメントを強制することができます。遅延した環境製品、失われた開発者作業、失敗した顧客コール、失われた下流トランザクション、または手動処理に振り向けられた公共スタッフの全費用を償還するものではありません。また、SLA は特定の顧客が責任を持って設計したかどうかを判断するものでもありません。契約条件は異なり、この分析は AWS が支配的な契約を超えて顧客に損害賠償責任を負うという認定を行うものではありません。

2025年のイベントは、法的欠陥を証明することなく、手続き上の皮肉を露呈します。標準的なクレジットプロセスはサポートセンターを使用しますが、サポートケース機能は初期の DynamoDB フェーズ中に利用できませんでした。顧客には後の請求期間があったため、一時的なブロックは必ずしも請求を妨げませんでした。しかし、それはクレジットに必要な証拠が影響を受けた監視スタックの外部で収集されるべき理由を示しています。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つのサポート依存関係が、多くの冗長システムを同様に動作させる可能性があります。説明責任は、次のインシデントの前にその権限を名指しし、それが間違っている場合に別の経路がまだ存在することを証明することから始まります。