us‑east‑1 がくしゃみをしたとき：2025年10月19–20日 AWS 障害フィールドガイド

Name

Akira Sakamoto

Updated on 2025/10/22

発生日時: 2025年10月19–20日（太平洋時間）
主なトリガー: DynamoDB のリージョンエンドポイントに対する DNS 自動化の欠陥（レース条件）
影響範囲: DynamoDB → EC2 の起動 → Network Manager → NLB → （Lambda、STS、IAM サインイン、Redshift、ECS/EKS/Fargate、Connect） が us‑east‑1 で波及

要点まとめ（忙しい方向け）

• 何がきっかけか（10月19日 11:48PM）: DynamoDB の自動 DNS 管理における レース条件 により、リージョンエンドポイント dynamodb.us-east-1.amazonaws.com のレコードが 空 に切り替わった。us‑east‑1 で新しい接続を開始しようとするものは DNS 解決に失敗した。
• DynamoDB の主要な復旧（10月20日 2:25–2:40AM）: AWS が正しい DNS を復元し、キャッシュの有効期限切れに伴って顧客側が回復した。
• なぜそこで終わらなかったか: EC2 の内部コントロールプレーンはホスト（“droplet”）のリースに DynamoDB を依存 している。DNS 障害の間にリースが期限切れになり、Droplet Workflow Manager（DWFM）が 渋滞崩壊（congestive collapse） を起こして Network Manager に滞留が発生。新規 EC2 インスタンスの起動がエラーになったり、ネットワーク状態なしで起動したインスタンスが発生した。
• ロードバランサーの乱高下（5:30AM–2:09PM）: Network Load Balancer（NLB）のヘルスチェックがネットワーク伝播遅延でフラッピングし、容量が断続的に削られ接続エラーが発生。
• 完全な安定復帰: 多くのサービスは 10月20日午後までに安定。Redshift の一部は（EC2 置換に伴う）遅れがあり 10月21日 4:05AM に完了。

起こったことを図解的に（PDT）

コア概念の簡単解説（初心者向け）

DNS（Domain Name System）
DNS はインターネットの電話帳のようなもの。名前を問い合わせると、どこに接続すればよいか（IP アドレス等）を返す。大規模な環境ではレコードやヘルスチェックを使い、巨大なフリートや AZ 間でトラフィックを振り分ける。高速で広く使われているが、トランザクショナルなデータベースではないため、一貫性や変更順序の管理は厄介で、設計上で回避する工夫が必要。

DynamoDB
AWS のフルマネージドなキー・バリュー/NoSQL データベース。低レイテンシで弾力性があり、AWS 自体のコントロールプレーンやメタデータにも広く使われている。Global Tables はリージョン間で複製する。アプリや AWS サブシステムが制御状態の読み書きをできずに DynamoDB に到達できないと、問題が積み重なる。

EC2 とコントロールプレーン
EC2 はインスタンスを物理ホスト（“droplets”）上で動かす。内部サービスがリースを管理し、ルートやセキュリティグループ等のネットワーク状態を伝播する。新しいインスタンスの起動は簡単だが、内部調整が健全でないかバックログがあると失敗する。

NLB（Network Load Balancer）
レイヤー4 のロードバランサ。ヘルスチェックを行い AZ 間でルーティングできる。ヘルスチェックがフラップしたり、DNS ベースのフォールオーバが過剰に働くと、必要なときに容量が過度に削られることがある。

実際に壊れたもの：DynamoDB の DNS 自動化

AWS は DynamoDB の DNS 管理を二つの役割に分けている：

• DNS Planner: 各エンドポイント（リージョン、FIPS、IPv6、アカウント固有など）について、どのロードバランサをどの重みで使うかといった望ましいレコードセットを計算する。
• DNS Enactor: 異なる AZ に配置された 3 つの冗長なワーカーがそのプランを Route 53 に適用する。各ワーカーはトランザクショナルな更新を行う。

異常な競合の下で、ある Enactor が 遅く進行 し、別の Enactor が新しいプランへ先行し、古い世代を ガベージコレクト した。遅い Enactor の 古い“older”プラン が、速い Enactor のクリーンアップが削除する直前に上書きされ、エンドポイントの 全ての IP を一度に削除 してしまい、以降の自動更新を ブロックする 状態になってしまった。人手で修復が行われた。

なぜ重要だったか：リージョンエンドポイントが消えたため、新しく DynamoDB を解決しようとする全てが即座に失敗した。既存の接続は一般に動作を続けた。

なぜ波及したか：密結合と時間の流れ

1. コントロールプレーンの結合（EC2 ⇄ DynamoDB）。
   EC2 の Droplet Workflow Manager（DWFM）は物理ホストのリースを保持している。そのチェックは DynamoDB に依存している。DNS 障害中にリースが タイムアウト し、droplet は新規配置の対象外になった。DynamoDB 復旧後、DWFM は巨大なフリートでリースを再確立しなければならず、キュータイムアウトに達し、輻輳 を引き起こした。

2. ネットワーク伝播の遅延。
   インスタンスが再び起動し始めても、Network Manager がネットワーク状態の伝播を遅延させていたため、伝播が追いつくまでインスタンスは完全な接続性を持たずに稼働していた（〜10:36AM）。

3. ヘルスチェックのフィードバックループ（NLB）。
   完全なネットワーク状態を持たない新規容量は 不健康 に見え、NLB がノードや AZ を取り下げてしまい、一時的に容量が縮小して接続エラーが悪化した。オペレータは振動（オシレーション）を止めるため自動ヘルスフェイルオーバを一時停止し、EC2 が安定した後に再有効化した。

4. 下流サービスへの反響。
   Lambda は同期呼び出し経路を保護するために特定パスをスロットルし、STS/IAM サインインは障害の影響を受け、コンテナ制御プレーン（ECS/EKS/Fargate）や Connect も EC2/NLB の複合影響を受けた。Redshift は追加で IAM を使ったクエリ認可が一時的にグローバルで失敗し、いくつかのクラスターは EC2 ホスト置換を待ったため Oct 21 まで引きずった。

「スイスチーズモデル」を思い浮かべているなら正解 — 多くの薄い防御層が偶然に一致した。

複雑系の視点（「根本原因」だけでは足りない理由）

HN の何人かは Richard Cook の How Complex Systems Fail や Perrow の Normal Accidents を持ち出したが、このフレームワークは非常によく当てはまる：

• 単一の原因はない。 DNS レースが引き金になったが、長引いた影響は EC2 の 準安定（metastable） な復旧モードと NLB の ヘルスチェック振動 に由来する—各々は局所的には合理的な設計だが、ストレス下で相互作用すると悪化する。
• システムは通常、劣化した状態で動く。 Planner/Enactor のリトライ、リース切れ、バックログといった「通常の摩擦」が不幸に重なった。
• 人が安全を作る。 自動化が停滞した際にオペレータが即興で修復（手動 DNS 復旧、DWFM のスロットリング/再起動、NLB 自動フェイルオーバの無効化など）を行い、システムをつなぎ直した。

まとめ：バグを直すことは必要だが、同時に小さな故障が雪だるま式に拡大する「準安定な回復トラップ」と「フィードバックループ」を探す必要がある。

AWS が発表している変更点

• DynamoDB の DNS 自動化： 問題修正完了までグローバルで無効化；誤ったプランの適用や削除を防ぐ保護を追加。
• NLB： ヘルスチェックのフェイルオーバ速度を制御する velocity control を追加し、一度に過度な容量が削られないようにする。
• EC2： DWFM に対する新しい 復旧テストスイート；データ伝播システム全体での キュー認識型スロットリング の改善。

これらは正しい対策のクラス：不正な書き込みを防ぎ、自己回復の速度を調整し、負荷下で復旧経路を試験する。

あなたができること（朝イチのチェックリスト）

AWS を変えられなくても、自分のスタックで影響を和らげることはできる。

1. リージョナルエンドポイントを優先し、隠れた us‑east‑1 依存を排除する。
   STS のようにリージョン化された制御プレーンがある場合は それを使う。デフォルトで認証やメタデータを us‑east‑1 に集中させない。

2. 重要な制御状態についてはマルチリージョン設計を。
   DynamoDB Global Tables を使えば読み書きを別リージョンへフェイルオーバできる。コードはレプリケーション遅延を許容し、後で整合する設計にすること。

3. ヘルスチェック振動に対しては「閉じる（fail‑closed）」設計を。
   自動フェイルオーバをダンピング（連続失敗回数、ヒステリシス、1分あたりの容量削減上限）でガードする。フラッピングを止めるための手動オーバーライド（回路遮断）を検討する。

4. 依存グラフを明確にする。
   起動/スケールに「必須」のサービス（認証、キュー、設定ストア等）を文書化し、「X が 2 時間遅い/利用不可ならどうするか」を訓練する。

5. 準安定復旧を練習する。
   データプレーンだけでなくコントロールプレーンのカオスデイを実施する：

   • フリートの一部でリース切れをシミュレートする。
   • ネットワーク構成伝播をフラッディングする。
   • バックプレッシャーと「スロットル解除」の順序をリハーサルする。

6. 意図を持ってキャッシュする。
   DNS キャッシュは復旧ラグを隠すことがある。新しい接続を積極的に開く SDK では、接続プーリング や 指数バックオフ＋ジッタ を使ってリトライの同時集中を避ける。

7. “セーフモード” の運用手順を作る。

   • エラー急増時に同時実行数やレートを下げる手順。
   • オートスケーラを再度有効化する前にバックログを排出する。
   • 高負荷なバックグラウンドジョブを制御するための feature flags。

8. 自分の「planner/enactor」パターンを守る。
   望ましい状態を生成して適用する仕組みがあるなら、次を追加する：

   • バージョン付きプラン と compare‑and‑swap（差分適用）セマンティクス。
   • 最後に既知の正常プランを削除できないクリーンアップ。
   • エンドポイントごとの シングルライタリース または小さな シーケンサ（ベクタクロック／単調カウンタ）。

これは「DNS の誤用」だったか？

厳密には違う。大規模環境では多くのクライアント、ライブラリ、VPC リゾルバが DNS を話すため、DNS はサービスディスカバリやトラフィックスティアリングのツールになっている。ここでの問題は DNS を使ったことではなく、同時書き込みを許し、ジャニタ（掃除役）が順序保証なしに作用し、さらにネットワーク伝播のバックログ中にヘルスチェック駆動の DNS が あまりに速く容量を削った 点にある。これらは設計上修正可能な点だ。

用語集（60秒リフレッシュ）

• Route 53: AWS の DNS とヘルスチェックサービス。重み付き/レイテンシ/ヘルスベースのルーティングとトランザクショナルなレコード変更をサポート。
• TTL (time to live): レゾルバが DNS 応答をキャッシュできる期間。短い TTL はフェイルオーバを早めるがクエリレートを増やす。
• DWFM (Droplet Workflow Manager): EC2 の物理ホストへのリースを管理するサブシステム。
• Network Manager: VPC/ネットワーク構成をインスタンスやネットワーク機器に伝播するコンポーネント。
• Global Tables (DynamoDB): テーブルのマルチリージョン複製機能。最終的整合性と競合解決を伴う。

最後に

この障害は「単なる DNS」ではなかった。DNS + コントロールプレーンの回復 + ヘルスチェックダイナミクス + 人による介入 の複合であり、可用性は「コンポーネントの特徴」ではなく「システム特性」であることを思い出させる。救いは、対策が具体的であることだ：プラン適用の直列化、容量削減速度の調整、負荷下での復旧経路のプレッシャーテスト。これらのパターンを自分のスタックに取り入れれば、次に us‑east‑1 がくしゃみをしてもティッシュの必要は減るだろう。