静的安定性とリトライ設計で耐える — US-EAST-1大規模障害(2021)に学ぶ
2021年12月のUS-EAST-1大規模障害（公式PES準拠）を題材に、内部ネットワークの輻輳で何が止まり何が生き残ったか＝コントロールプレーン障害／データプレーン生存の型を読みます。静的安定性・指数バックオフ＋jitter・out-of-band監視で備える判断軸を、AWS批判ではなく信頼性設計の学びとして整理します。
- #AWS障害
- #US-EAST-1
- #静的安定性
- #コントロールプレーン
- #データプレーン
- #リトライ
- #指数バックオフ
- #SRE
- #信頼性設計
システムが動いているうちは、どの依存が致命的かはなかなか見えません。2021年12月にAWSのUS-EAST-1（バージニア北部リージョン）で発生した大規模障害は、「壊れたのは主にコントロールプレーン（操作・管理・認証・監視のAPI）で、稼働中のデータプレーンは生き残った」という障害の型を、はっきりと映し出しました。「2021年にAWSが落ちた」で止めず、この型を読み解けば、自分の本番環境を設計でどこまで耐えさせられるかが見えてきます。本記事は事象の解説を簡潔にとどめ、設計判断に重心を置きます。題材にする事実はすべてAWS公式のPES（Post-Event Summary、障害の事後サマリー）に基づき、AWSへの批判ではなく設計の学びとして読んでいただける内容です。
何が起きたか（公式PESに基づく事実）
以下の時刻は太平洋標準時（PST）です。日本時間はPSTに17時間を加えた時刻になります。2021年12月7日（米国時間）、US-EAST-1で内部ネットワークの輻輳（ふくそう、トラフィックの混雑による処理の遅延・失敗）を起点に、多数のサービスのAPIが長時間にわたり不調になりました。性質としては、データ層のDNS障害だった2025年10月の事例とも、単一アベイラビリティゾーン（AZ）に閉じた東京リージョンの事例とも異なり、内部ネットワークの輻輳に起因するコントロールプレーンの広域障害でした。主要な時刻は次のとおりです。
| 時刻（PST） | 公式記載の出来事 |
|---|---|
| 7:30 | 内部ネットワークの輻輳が始まる |
| 7:33 | EC2 APIのエラーが増加 |
| 9:28 | DNS解決のエラーが完全に回復 |
| 13:15 | EC2 APIが改善し始める |
| 13:34 | 輻輳が大幅に改善 |
| 14:22 | 全ネットワーク機器が回復・マネジメントコンソールが復旧 |
| 14:40 | 新規EC2インスタンスの起動が完全に回復 |
| 16:28 | STS（一時認証情報の発行）が完全に回復 |
| 16:37 | API Gatewayが概ね回復 |
根本原因：内部ネットワークの輻輳とリトライの殺到
公式PESによれば、主ネットワーク上で動くあるAWSサービスの容量を自動スケールする活動が、内部ネットワーク内の多数のクライアントから予期しない挙動（接続の殺到）を誘発しました。これが内部ネットワークと主ネットワークの間にある機器を圧迫し、遅延とエラーが連鎖したというのが公式の説明です。ここで見落とせないのが、クライアント側の挙動が事態を増幅した点です。公式は再発防止策として「クライアントのバックオフ（再試行の間隔を空ける）挙動の修正を約2週間以内に展開する」と明記しており、リトライ・再接続の殺到（リトライストーム）が輻輳を悪化させた構図が読み取れます。なお、これ以上の機微な技術詳細（具体的な機器の種別や内部サービス名など）は公式に記載がなく、本記事でも推測しません。
何が壊れ、何が生き残ったか（影響範囲）
この障害を「AWSが全部止まった」と捉えると、設計の教訓を取り逃します。重要なのは、壊れたものと生き残ったものの境界です。
公式が影響ありと挙げたのは、主にAPI・認証・監視といったコントロールプレーン側です。EC2 API（新規インスタンスの起動を含む）、Route 53 API、ELB、マネジメントコンソールのログイン、STS、CloudWatch、API Gateway、EventBridge、コンテナ系（Fargate・ECS・EKS）、Amazon Connect、EC2に依存するRDS・EMR・WorkSpaces・Redshift、そしてS3・DynamoDBのVPCエンドポイントが該当します。一方、影響を受けなかったとされるのは、稼働中のEC2インスタンス、S3・DynamoDBへの直接アクセス、Lambdaの呼び出しです。
ここで線を引くべきは「稼働中」と「新規起動」の違いです。すでに動いているEC2インスタンスは落ちていません。しかし新しく起動する操作はEC2 API（コントロールプレーン）に当たるため、回復した14時40分まで長時間できない状態が続きました。グローバルな機能であるコンソールやSTSがUS-EAST-1に集中していたことも、影響が広域に見えた一因です。これら以外の細かな可否は公式に記載がありません。
ここからは設計の話：事実と一般原則を分けて読む
ここから先は、公式PESが「こう設計せよ」と述べているわけではありません。障害の事実（前章まで）と、AWS Builders’ LibraryやWell-Architectedが示す設計の一般原則を切り分けたうえで、後者を教訓として接続します。優先順位は、①コントロールプレーンとデータプレーンを分け静的安定性で耐える、②リトライストームを増幅させない、③監視を壊れた対象に依存させない、の順です。
① CP/DP分離と静的安定性で耐える
今回の本質は「新規起動はできないが、既存インスタンスは動き続けた」という事実に集約されます。起動・スケール・デプロイ・設定変更といった操作を担うコントロールプレーン（CP）が障害を受けても、稼働中の処理を担うデータプレーン（DP）は生き残りやすい、という典型例です。
| 操作の種類 | 例 | 障害時の生死 | 依存を外す手立て |
|---|---|---|---|
| コントロールプレーン | 新規起動・スケールアウト・設定変更 | 影響を受けやすい | 事前プロビジョン・ウォームプール・キャパシティ予約 |
| データプレーン | 稼働中インスタンスの処理・既存接続の継続 | 比較的生き残る | 定常運用をCP操作に依存させない |
設計の核は、定常運用と復旧をできるだけCP操作に依存させないことです。これを静的安定性（static stability）と呼びます。障害の最中に新しいリソースを取りに行かなくて済むよう、平時から余剰キャパシティを確保しておく考え方です。今回、稼働中EC2・S3/DynamoDBへの直接アクセス・Lambda呼び出しが最初から最後まで生き残ったことは、静的安定性の生きた実例といえます。逆に、スケールアウトや再起動を前提にした復旧計画は、コントロールプレーン障害時に機能しない恐れがあります。まず自分の重要パスを棚卸しし、定常運用と復旧手順のどこがCPに依存しているかを把握することが出発点です。考え方の体系はBuilders’ Libraryの静的安定性に関する解説と、Well-Architectedの信頼性の柱が参考になります。コントロールプレーン依存を断つ設計そのものは、2025年10月のUS-EAST-1障害の記事でより掘り下げています。
② リトライストームを増幅させないクライアント設計
本障害ではクライアントの再接続の殺到が輻輳を増幅しました。呼び出す側が過負荷の発生源にならず、上流の不調を受け流す実装が要点です。基本は指数バックオフ（再試行のたびに待ち時間を倍々に広げる）に、jitter（待ち時間にばらつきを加える）を組み合わせることです。jitterがないと、復旧の瞬間に全クライアントが一斉に再試行してリトライストームを起こしますが、時刻を分散させればこれを避けられます。あわせて、リトライ回数の上限、クライアントタイムアウト、サーキットブレーカー（連続失敗時に呼び出しを一時遮断する仕組み）を既定とします。多くのAWS SDKは、standardまたはadaptiveのリトライモードでバックオフとjitterを内蔵しているため、自前実装は必須ではありません。考え方の典拠はBuilders’ Libraryのバックオフとjitterの解説、Well-ArchitectedのREL05、各SDKのリトライ仕様です。リトライや可観測性を本番運用へ落とし込む設計は、本番運用の記事も参考になります。
③ 監視を壊れた対象に依存させない（out-of-band監視）
今回はCloudWatch自身も影響を受けました。監視対象と同じ基盤・同じリージョンに監視を集約していると、障害時に「壊れていること」が見えなくなります。別系統・別リージョンの監視や、外形監視（合成監視・canary）を持つことで、自分の目を確保します。平時から信頼性を測り続ける枠組みは、SLOとエラーバジェットの記事で扱っています。典拠はWell-Architectedと可観測性に関する公式ドキュメントです。
④ グローバル機能のUS-EAST-1集中と依存連鎖
STS、マネジメントコンソール、Route 53の管理といったグローバルな運用機能がUS-EAST-1経由だと、当該リージョンの障害が認証や運用全体へ波及します。重要操作の代替経路、別リージョンからの運用手段、事前に発行したクレデンシャルの保持などを検討します。あわせて、EC2 APIの不調がRDS・EMR・WorkSpaces・Redshiftへ連鎖したように、自分のサービスが「どのコントロールプレーンに依存して復旧するか」を依存グラフで可視化しておくと、フェイルオーバーが同じ依存に巻き込まれる事態を避けられます。
障害の型で備えを変える（3類型の地図）
障害は一様ではなく、壊れる層も効く備えも型によって異なります。データ層のDNS障害、単一AZの障害、そして今回の内部ネットワーク輻輳によるコントロールプレーン広域障害を並べると、備えの違いが整理できます。
型ごとに効く備えが違うからこそ、単一の対策ではなく優先順位づけが要ります。単一AZに閉じた障害の読み解きは東京リージョンAZ障害の記事に、データ層のDNS障害は2025年10月の記事に整理しています。なお、平時からマルチリージョンでDR（災害復旧）をどう設計するかは、本記事の「障害を読む」視点とは別の「あらかじめ備える」視点になるため、別記事で扱います。
明日できる備え（持ち帰りチェックリスト）
規模を問わず明日から着手できる備えをまとめます。
| 備え | 具体策 |
|---|---|
| リトライの棚卸し | 指数バックオフとjitterが入っているか、SDKの既定と上限を確認 |
| 復旧手順の点検 | 起動・スケールなどCP操作に過度依存していないか、余剰キャパシティを検討 |
| 監視の別系統化 | 監視対象と同じ基盤・同じリージョンに監視を集約しない |
| グローバル機能の点検 | STS・コンソール・Route 53管理のUS-EAST-1集中と代替経路を確認 |
ここで挙げたのは「自分の環境の備え」です。これとは別に、AWS自身が公式PESで公表した事後対応があります。問題となったスケーリング活動の無効化、クライアントのバックオフ挙動の修正を約2週間以内に展開、保護的なネットワーク構成の追加、Service Health Dashboardの刷新、顧客連絡システムのマルチリージョン化です。これらはAWS側の対応であり、自環境の備えとは切り分けて読むのが正確です。
まとめ
障害は、平時には見えない設計の前提を映す鏡です。2021年12月のUS-EAST-1障害から引き出せる教訓は、①コントロールプレーンとデータプレーンを分け静的安定性で耐える、②リトライストームを増幅させないクライアント設計を備える、③監視を壊れた対象に依存させない、という優先順位でした。いずれも「絶対に障害を防ぐ」魔法ではなく、影響を局所化するための投資判断です。障害の型ごとに効く備えは異なります。まず自分の重要パスがどの型に弱いかを見極めることが、設計の第一歩になります。各サービスの仕様は改定されうるため、適用前に公式の最新情報をあわせてご確認ください。