- 2025年10月19〜20日、AWS N. Virginia リージョン（us-east-1） で Amazon DynamoDB をはじめ複数の中核サービスが長時間の障害に見舞われた
- 障害は、DynamoDB の自動 DNS 管理システム内の潜在的な競合状態（race condition） により、誤って空の DNS レコードが生成されたことから始まった
- これにより、EC2 インスタンス作成失敗、Network Load Balancer（NLB）の接続エラー、Lambda・ECS・Redshift など多数のサービスの API 遅延および失敗が連鎖的に発生した
- AWS は問題の原因を DynamoDB DNS Enactor 間の異常な同時更新の衝突と特定し、手動復旧により 10 月 20 日午後 2 時 20 分ごろに完全復旧した
- 今回の事案は、AWS 内部の自動化システム間の相互依存性の複雑さを浮き彫りにし、今後は DNS・EC2・NLB の耐障害性強化に向けた構造的改善が予告されている
事案の概要
- 障害は 2025 年 10 月 19 日午後 11 時 48 分（PDT）に始まり、10 月 20 日午後 2 時 20 分（PDT）に終了
- 主な影響区間は 3 回あった:
- 10 月 19 日 11:48PM〜10 月 20 日 2:40AM: DynamoDB API エラー率が急増
- 10 月 20 日 5:30AM〜2:09PM: NLB 接続エラーが増加
- 10 月 20 日 2:25AM〜10:36AM: EC2 の新規インスタンス作成失敗およびネットワーク接続問題
- 障害は DynamoDB DNS 管理システムの欠陥から始まり、EC2、NLB、Lambda、Redshift など多数のサービスへ拡大した
DynamoDB 障害の原因と影響
- DynamoDB の自動 DNS 管理システム 内の潜在的欠陥がトリガーされ、
dynamodb.us-east-1.amazonaws.com の DNS レコードが空の状態に誤って更新された
- システムは 2 つの構成要素に分かれている:
- DNS Planner: ロードバランサーの状態を監視し、新しい DNS プランを生成
- DNS Enactor: Route53 に変更を適用する役割
- 3 つのアベイラビリティゾーン（AZ）に独立配置された DNS Enactor 間で 競合状態（race condition） が発生
- 1 つ目の Enactor が遅延した状態で古いプランを適用
- 2 つ目の Enactor が最新プランを適用した後、古いプランを削除したことで、すべての IP アドレスが除去され、システムが不整合状態に移行
- 自動復旧に失敗したため、手動介入（manual intervention） が必要になった
- 11:48PM の障害発生直後、DynamoDB に依存するすべてのサービスと顧客トラフィックで接続失敗が発生
- グローバルテーブルを使用している顧客は他リージョンのレプリカにリクエストできたが、レプリケーション遅延（replication lag） が発生した
- 12:38AM に AWS エンジニアが DNS 状態を問題の原因として確認
- 1:15AM の暫定復旧措置で一部の内部サービス接続を回復
- 2:25AM に DNS 情報を完全復元し、2:40AM にすべての接続が正常化
Amazon EC2 への影響と復旧過程
- 10 月 19 日 11:48PM〜10 月 20 日 1:50PM の間、EC2 API エラー率の上昇、インスタンス作成失敗、遅延増加が発生
- EC2 インスタンス管理には DropletWorkflow Manager（DWFM） と Network Manager という 2 つのサブシステムが使用される
- DWFM は物理サーバー（「droplet」）の状態を管理し、定期的に状態確認を実施
- Network Manager はインスタンスのネットワーク設定を伝播する
- DynamoDB 障害により DWFM の状態確認が失敗し、droplet のリースが期限切れになった
- 2:25AM に DynamoDB 復旧後、DWFM が再接続を試みたが、大量の droplet 数により 輻輳崩壊（congestive collapse） が発生
- 4:14AM にエンジニアが DWFM ホストを選択的に再起動してキューを整理し、復旧を進めた
- 5:28AM にすべての droplet リースが復元され、新規インスタンス作成が再開
- その後、Network Manager が遅延したネットワーク状態伝播のバックログを処理する過程で、ネットワーク接続遅延が発生
- 10:36AM にネットワーク伝播時間が正常化
- 11:23AM にリクエスト制限（throttling）の緩和を開始し、1:50PM に EC2 が完全復旧
Network Load Balancer（NLB）への影響
- 10 月 20 日 5:30AM〜2:09PM の間、一部の顧客が NLB 接続エラーの増加を経験
- NLB はマルチテナント構造で、バックエンドの EC2 インスタンスにトラフィックをルーティングする
- 障害原因は ネットワーク状態伝播遅延によるヘルスチェック失敗
- 新たに追加された EC2 インスタンスのネットワーク設定が完了しておらず、ヘルスチェックに失敗
- ヘルスチェック結果が不安定に繰り返され、NLB ノードが DNS から削除されたり復帰したりする現象が発生
- 6:52AM に監視システムが問題を検知し、エンジニアが対応を開始
- ヘルスチェックサブシステムの負荷増加により自動 AZ DNS フェイルオーバーが発生
- 9:36AM に自動フェイルオーバーを無効化し、すべての正常ノードが復帰
- 2:09PM に EC2 復旧後、自動フェイルオーバーを再有効化
その他の AWS サービスへの影響
- AWS Lambda:
- 10 月 19 日 11:51PM〜10 月 20 日 2:15PM の間、API エラーおよび遅延
- DynamoDB 障害により関数の作成・更新に失敗し、SQS/Kinesis イベント処理が遅延
- 7:04AM に NLB ヘルスチェック失敗で内部システムが縮退し、非同期呼び出しが制限
- 2:15PM にすべてのバックログ処理が完了し正常化
- ECS、EKS、Fargate:
- 10 月 19 日 11:45PM〜10 月 20 日 2:20PM の間、コンテナ起動失敗およびクラスター拡張遅延
- Amazon Connect:
- 10 月 19 日 11:56PM〜10 月 20 日 1:20PM の間、通話・チャット・ケース処理エラー
- DynamoDB 復旧後に大半の機能は正常化したが、7:04AM 以降は NLB および Lambda の影響で再びエラーが発生
- 1:20PM に完全復旧
- AWS STS:
- 10 月 19 日 11:51PM〜10 月 20 日 9:59AM の間、認証 API エラーおよび遅延
- DynamoDB 復旧後に一時正常化したが、NLB 問題により再度エラーが発生
- IAM ログインおよび Identity Center:
- 10 月 19 日 11:51PM〜10 月 20 日 1:25AM の間、認証失敗が増加
- DynamoDB 復旧後に正常化
- Amazon Redshift:
- 10 月 19 日 11:47PM〜10 月 20 日 2:21AM の間、クエリおよびクラスター変更に失敗
- DynamoDB 復旧後も一部クラスターは EC2 障害の影響で依然として不安定
- 10 月 21 日 4:05AM に完全復旧
- IAM API 依存性によりグローバルリージョンでも一時的なクエリ失敗が発生
- その他のサービス:
- Managed Workflows for Apache Airflow、Outposts、AWS Support Center なども影響を受けた
事後対応と改善計画
- DynamoDB DNS Planner および Enactor の自動化を全面停止し、再有効化前に競合状態の修正と保護機構の追加を予定
- NLB: ヘルスチェック失敗時に単一 NLB が削除できる容量を制限する レート制御メカニズム を導入
- EC2:
- DWFM 復旧ワークフローを含む新たな テストスイート を構築
- データ伝播システムの スマートスロットリング改善により、待機キューサイズに応じたリクエスト制限機能を追加
- AWS はサービス全体の相互依存性分析を通じて、復旧時間短縮および類似事故防止策を追加検討中
結論と謝罪
- AWS は今回の事案が顧客に与えた影響について公式に謝罪
- 自社サービスの高い可用性を維持してきたものの、今回の障害が 顧客ビジネスに重大な影響を与えたことを認めた
- 本件を教訓として、自動化システムの耐障害性および障害対応手順の強化を約束した
2件のコメント
シニア人材を切った反動だと言われていますが……本当ですか？
Hacker Newsの意見
この話題についてはいつも同じことを言っている。まだ Richard Cookの文章 を読んでいないなら、まずこのポストモーテムを読むのをやめて、先に How Complex Systems Fail を読むことを勧める。複雑なシステム障害を扱った技術文章として最高クラスの一つだ。Cookは「ルート原因(root cause)」という概念そのものを退けており、今回の件でも彼が正しいと思う
インターネットはますます 集中化された単一ネットワーク(mononet) へと変わっている。冷戦時代に分散ネットワークとして生まれたインターネットが、今では一度のデプロイミスで世界中の銀行・買い物・旅行が止まりうる構造になった。クラウドというメタファーはすでに限界を超えている。
スタートアップやR&Dには依然として有用だが、成長段階の企業や政府は 自前サーバー・自前クラウド・自前の基幹サービス を持つべきだ。技術も人材も十分にある
AWSのポストモーテムでは 正確なタイムラインの可視化 が印象的だった。GDCの伝説的講演 "I Shot You First" のように、時間の流れを傾いた矢印で表現し、「遅延はどこで発生したのか」を問う手法が有用だった。
しかしもっと驚いたのは、EC2ノードのリース管理サービスに 復旧手順(runbook) がなかったことだ。AWSの中核サービスなら、ほとんどすべての例外状況に備えがあると思っていた
今回の件の核心は、DNSシステムにおける キャッシュ無効化(cache invalidation) 問題の変種のように見える。2つのDNS Enactorが異なるタイミングでプラン(plan)を適用したことで レースコンディション が発生し、古いプランが新しいプランを上書きしてしまった
Enactorは新しい値を適用する前に、現在のレコードのバージョン比較(CAS) をすべきだった。効率は落ちても基本的な安全装置だ。DynamoDB自体で処理できたはずだ
DynamoDBがリージョンごとに数十万件のDNSレコードを管理しているという説明を見て驚いた。
dynamodb.us-east-1.amazonaws.comが数十万のIPに解決されうるとは、Route53の限界を超える規模 に思える。おそらくTTLを低くして一部だけ更新する方式なのだろうバグは常に存在する。形式検証(formal verification) は難しく、低確率のバグは何年も経ってから表面化することもある。
だからシステムは必ず失敗すると仮定し、被害を限定する構造 を設計しなければならない。セルベースアーキテクチャ、段階的ロールアウト、隔離されたゾーンがその例だ。
AWSもセルベース化を進めているが、特に us-east-1 には レガシーな相互依存 が残っている。長期的にはリージョンを完全に独立して設計すべきだ。
こうした作業は上級経営陣の支援がなければ進まないが、株主の立場では企業存続リスク を減らすための中核的投資だ
レポートで UTCではなくPTタイムゾーン を使っていたのは意外だった
エンドポイント単位のバージョン管理や 2PC、単一writer lease のようなパターンがないのは驚きだった。それでもAWSがこれほど透明に公開したことは高く評価したい
私は今回の 直接的な原因 が、DynamoDB DNS管理システムに潜んでいたレースコンディションだったと考えている。古いプランが最新のプランを上書きし、リージョナルエンドポイントのDNSレコードが空になってしまった
参考: How Complex Systems Fail