AWS US-EAST-1 大規模障害(2025年10月)に学ぶ — コントロールプレーン依存を断つ信頼性設計

システムが動いているうちは、どの依存が致命的かはなかなか見えません。2025年10月にAWSのUS-EAST-1（バージニア北部リージョン）で発生した大規模障害は、その依存関係をまとめて可視化する出来事でした。本記事は、何が起きたかの解説は簡潔にとどめ、「自分の本番環境をどう設計していれば影響を局所化できたか」という設計判断に重心を置きます。題材にする事実はすべてAWS公式のPES（Post-Event Summary、障害の事後サマリー）に基づきます。AWSへの批判ではなく、設計の学びとして読んでいただける内容です。

何が起きたか（公式PESに基づく事実）

以下の時刻は太平洋夏時間（PDT）です。日本時間はPDTに16時間を加えた時刻になります。障害は2025年10月19日23時48分PDTに始まり、10月20日14時20分PDTに終了しました。対象はUS-EAST-1です。

根本原因は、DynamoDBのDNS管理システムにあった競合状態（複数の処理が同時に走ったときのタイミング上の欠陥）でした。複数のアベイラビリティゾーンで動く2つの「DNS Enactor」がタイミング衝突し、一方の更新処理の途中でクリーンアップが古い計画を削除した結果、dynamodb.us-east-1.amazonaws.com のIPアドレス情報が即時に空へ上書きされました。鮮度を確認する安全チェックは遅延によって機能せず、以後この不整合な状態から自動では回復できなくなりました。重要なのは、DynamoDB自体が停止したのではなく、エンドポイントのDNS解決ができなくなったという点です。

この起点から連鎖が広がりました。DynamoDBに依存するEC2の内部コンポーネント（DropletWorkflow Manager、DWFM）がcongestive collapse（過負荷による機能停止）に陥り、新規インスタンスの起動が250万件超失敗しました。一方で、すでに稼働中のインスタンスは動き続けました。さらにNetwork Load Balancer、Lambda、ECS/EKS/Fargate、Amazon Connect、STS、グローバルなIAMコンソール認証、Redshift、AWS Supportコンソールへと波及しました。復旧は段階的に進み、02時40分PDTに顧客側のDNS解決が回復、13時50分PDTにEC2が完全回復、14時09分PDTにNLBの自動フェイルオーバーが再有効化されました。

AWSは再発防止として、DynamoDBのDNS自動化を全世界で一旦無効化し、競合状態の修正と追加の保護を実装する方針、NLBに単一機器が除去できる容量を制限するvelocity controlの追加、EC2のDWFM回復ワークフローのテスト強化などを公表しています。

なお、次の項目は公式PESに記載がありません。本記事でも推測しません。影響を受けた顧客数、金銭的な影響額、競合状態の潜伏期間、無効化した自動化の再有効化時期、そして当該設計に至った理由です。

ここからは設計の話：障害の事実と一般原則を分けて読む

ここから先は、公式PESが「こう設計せよ」と述べているわけではありません。障害の事実（前章）と、AWS Builders’ LibraryやWell-Architectedが示す設計の一般原則を切り分けたうえで、後者を「教訓として接続」します。優先順位は、①コントロールプレーン依存の切り離し、②単一リージョン依存からの脱却、③連鎖を増幅させないクライアント設計、の順です。

① コントロールプレーン依存とデータプレーン依存を分ける

今回の本質は「新規起動はできないが、既存インスタンスは動き続けた」という事実に集約されます。これは、起動・プロビジョニング・設定変更を担うコントロールプレーン（CP）が障害を受けても、稼働中の処理を担うデータプレーン（DP）は生き残った典型例です。

操作の種類	例	障害時の生死	依存を外す手立て
コントロールプレーン	インスタンス新規起動・キャパシティ取得・設定変更	影響を受けやすい	事前プロビジョン・ウォームプール・キャパシティ予約
データプレーン	稼働中インスタンスの処理・既存接続の継続	比較的生き残る	定常運用をCP操作に依存させない

設計の方向は、定常運用をできるだけCP操作に依存させないことです。障害の最中に新しいリソースを取りに行かなくて済むよう、あらかじめ確保しておく発想が中心になります。具体的には、ピーク時に必要な台数を事前にプロビジョニングしておく、起動済みの予備を保持するウォームプールを用意する、重要なワークロードにはキャパシティ予約を確保する、といった手立てです。いずれも「障害中に新規取得しない」状態を平時から作っておく点で共通します。依存をどう隔離して過負荷を封じ込めるかは、AWS Builders’ Libraryの「Using dependency isolation to contain concurrency overload」が体系的に扱っています。

DynamoDBに限れば、フェイルオーバー時に新規キャパシティの取得で詰まらないよう、容量モードはon-demandが推奨されています。プロビジョンドモードは需要の急増にAuto Scalingが分単位でしか追従できず、スロットリング（要求の絞り込み）を招きやすいためです。逆に言えば、CP操作に頼らずに需要変動を吸収できる構成へ寄せておくことが、障害時に効いてきます。設計の出発点は、まず自分の重要パスを棚卸しし、定常運用のどこがコントロールプレーンに依存しているかを把握することです。

② 単一リージョン依存からの脱却（RTO/RPO×コスト）

US-EAST-1への集中は便利さの裏返しでもあります。ただしマルチリージョン化は無条件の正解ではなく、どこまで投資するかという意思決定として捉えるのが現実的です。DynamoDBのGlobal Tablesは、各リージョンのレプリカが読み書き可能な、テーブルレベルで常時アクティブな構成を取れます。整合性にはマルチリージョン結果整合（MREC）とマルチリージョン強整合（MRSC）の2モードがあります。

方式	切替の速さ（RTO）	コスト	向くケース
active-active	速い（常時両系稼働）	高い（書込競合の解決が必要）	停止許容が小さい中核サービス
active-passive	切替に時間（待機系を昇格）	中（待機コスト）	RTOに余裕があり費用を抑えたい

フェイルオーバーの実装には、Route 53のDNSフェイルオーバー、より信頼性の高いトラフィック再配分を担うRoute 53 Application Recovery Controller（ARC）、アプリ層のサーキットブレーカといった選択肢があります。どこまで投じるかは、許容できる復旧時間（RTO）とデータ損失（RPO）を費用と天秤にかけて決めます。判断の枠組みはWell-Architectedの信頼性の柱が参考になります。

③ 連鎖を増幅させないクライアント設計

congestive collapseは、呼び出す側の設計でも増幅します。自分が過負荷の発生源にならず、上流の不調を受け流す実装が要点です。基本は指数バックオフにjitter（リトライ時刻のばらつき）を加えることです。jitterがないと、復旧の瞬間に全クライアントが一斉に再試行してリトライストームを起こしますが、時刻を分散させればこれを避けられます。あわせて、リトライ回数の上限（Well-ArchitectedのREL05-BP03）とクライアントタイムアウト（REL05-BP05）を設定します。多くのAWS SDKは、standardまたはadaptiveのリトライモードでバックオフとjitterを内蔵しているため、自前実装は必須ではありません。

④ グレースフルデグラデーション、ただしフォールバックは慎重に

STSやIAMコンソール、Connectのような依存が断たれたとき、主機能だけは生かす切り離しが有効です。ただし、安易なフォールバック経路はそれ自体が新たな障害源になり得ます。Builders’ Libraryの「Avoiding fallback in distributed systems」が指摘するとおり、「フォールバックを足す」より「依存を減らす・隔離する」を上位に置くのが堅実です。

依存サービス	断たれたときの主機能への影響	切り離しの方針
STS / IAMコンソール認証	新規の認証・権限取得が困難	既存トークンの寿命設計・認証経路の冗長化
Amazon Connect	問い合わせ導線の停止	代替導線への切替手順を用意

⑤ 明日できる備え（持ち帰りチェックリスト）

最後に、規模を問わず明日から着手できる備えをまとめます。

備え	具体策
マルチAZ前提の再点検	単一AZ依存になっている箇所を洗い出す
リージョン避難の手順書	誰が・何を・どの順で切り替えるかを文書化
障害検知の自動通知	AWS Health DashboardとEventBridgeを連携しアラート化
重要パスの依存棚卸し	定常運用がCP依存になっていないかを確認

まとめ

障害は、平時には見えない設計の前提を映す鏡です。今回の事実から引き出せる教訓は、①コントロールプレーンとデータプレーンの依存を分ける、②単一リージョン依存からの脱却をRTO/RPOとコストで判断する、③連鎖を増幅させないクライアント設計を備える、という優先順位でした。いずれも「絶対に障害を防ぐ」ための魔法ではなく、影響を局所化するための投資判断です。本記事で触れた可観測性やSLOの設計は、平時から信頼性を測り続けるうえで対になるテーマであり、別記事で扱います。各サービスの仕様・料金は改定されうるため、設計の適用前に公式の最新情報をあわせてご確認ください。