エンジニアは何を思い、どう対応したのか AWSがDynamoDB、EC2、NLB障害の概要を公表：再発防止策は

世界規模の顧客が利用する基幹リージョンである米国東部「us-east-1」が、日本時間では2025年10月20日15時48分から21日6時20分にかけて障害に見舞われた。AWSは何が原因で多段階の不具合が発生したのか、その詳細を発表した。

[＠IT]

　Amazon Web Services（AWS）は2025年10月23日（米国時間、以下同）、米国東部リージョン（バージニア北部、us-east-1）で2025年10月19日23時48分〜20日14時20分と14時間半にわたり、段階的に顕在化した障害と復旧までの詳細を公開した。

　以降、翻訳された文書を基に、障害の概要とエンジニアがどう対応したのかを要約する。

　今回の事案は、「Amazon DynamoDB」の約3時間（19日23時48分〜20日2時40分）にわたるAPIエラー率上昇、「Amazon EC2」の約8時間（20日2時25分〜10時36分）にわたる起動失敗（接続の問題は13時50分に解決）、「AWS Network Load Balancer」（NLB）の約9時間（20日5時30分〜14時9分）にわたる接続障害という3つの異なる時間軸でユーザーに影響を及ぼした。多くの大規模なAWSのサービスはDNSに大きく依存しており、自動DNS管理システム内の潜在的な欠陥がDynamoDBエンドポイントの名前解決の失敗を招き、影響が広域に波及していったという。

発端はDynamoDB、自動DNS管理システムに“まれ”な事象が発生

　発端は10月19日23時48分から20日2時40分にかけてのDynamoDB APIエラー率上昇だった。

　DynamoDBは多数のロードバランサーと多様なエンドポイント（リージョナル、IPv6、FIPS《連邦情報処理標準》など）を扱い、自動DNS管理システムが可用性確保の要となる設計になっている。リージョナルエンドポイントの自動DNS管理システムが競合状態となったことが、APIエラー率上昇につながっている。

　自動DNS管理システムは可用性確保のためにDNSプランナーとDNSエナクターという2つのコンポーネントに分かれる。DNSプランナーは、ロードバランサーの健全性と容量を監視し、定期的に各サービスエンドポイントに対してロードバランサーとウェイトのセットで構成される新しいDNSプランを作成する。DNSエナクターは「何が起こってもシステムを回復できるように」最小限の依存関係で設計されており、DNSプラン実行の役割を担う。今回の自動DNS管理システムの競合状態は、2つのDNSエナクター間で“まれ”な相互作用が起こったことが要因だという。

　結果として、古いDNSプランが新しいDNSプランを上書きし、適用したプランよりも大幅に古いプランを特定して削除するクリーンアッププロセスが走り、リージョナルエンドポイントの全てのIPアドレスが消えたことで、DynamoDBへの新規接続が広域で失敗した。

　最終的に、オペレーターによる手動での修正によって、DynamoDBの復旧は20日2時25分に達成され、キャッシュ有効期限が経過すると接続は順次回復したが、DynamoDBへの新規接続が広域で失敗した影響は、DynamoDBユーザーのシステムのみならず、DynamoDBに依存するAWS内部の他のサービスにも波及していた。その一つがEC2だ。

DynamoDBのAPIエラーがEC2起動に影響した具体的なプロセスとは

　EC2では、インスタンスのホスティングに使用される全ての物理サーバ（以下、ドロップレット）の状態管理やリース管理を担う「DropletWorkflow Manager」（DWFM）と、起動直後のインスタンスにネットワーク状態を伝搬する「Network Manager」が可用性確保の中核になる。

　EC2ではリースの維持の一環として、DWFMホストは、管理下にある各ドロップレットに数分ごとにチェックインを行い、状態チェックを完了する必要がある。このチェックプロセスがDynamoDBに依存している。

　19日23時48分〜20日2時24分の間に、DWFM内のドロップレット間のリースが徐々にタイムアウトし始めた。2時25分のDynamoDB APIの復旧に伴い、DWFMはドロップレットとのリースの再確立を開始。アクティブなリースを持たないドロップレットは新しいEC2起動の候補と見なされないので、EC2 APIは新規のEC2起動リクエストに対して「insufficient capacity」（キャパシティー不足）を多発。DWFMは輻輳（ふくそう）崩壊の状態に陥り、このような状況に確立された運用回復手順は存在しなかったという。

　エンジニアは「さらなる問題を引き起こすことなくDWFMの問題を解決しよう」と慎重に複数の緩和策を試みたが、20日4時14分にリクエストの制限に踏み切り、DWFMホストの選択的な再起動を開始。DWFMのキューがクリアされて処理時間が短縮され、ドロップレットリースの確立が可能になったことで、5時28分にはDWFMが米国東部リージョン内の全てのドロップレットリースを確立し、新規起動が再び成功し始めた。

　だが、再起動開始前に、全体的な負荷を減らすために制限した多くのリクエストは依然として「request limit exceeded」（リクエスト制限超過）エラーを表示し、Network Managerにはネットワーク状態伝搬のバックログ（未処理）が蓄積していた。その結果、6時21分、Network Managerはバックログのネットワーク状態変更を処理する際に、ネットワーク伝搬時間の増加を観測し始めた。新しいEC2インスタンスは正常に起動できたものの、ネットワーク状態伝搬の遅延により、必要なネットワーク接続が確立できない状態だった。

　エンジニアはNetwork Managerの負荷を軽減してネットワーク設定伝搬時間に対処し、復旧を加速するための対策を講じた。10時36分までに、ネットワーク設定伝搬時間は通常のレベルに戻り、新しいEC2インスタンスの起動も再び正常に動作するようになった。APIコールとインスタンス起動リクエストが安定化したことで、11時23分に、エンジニアはリクエスト制限の緩和を開始。13時50分にEC2は全面的に正常化した。

　ところが、今度はEC2インスタンスのネットワーク状態伝搬の遅延がNLBおよびNLBを使用するAWSサービスにも影響を及ぼした。

EC2インスタンスのネットワーク状態伝搬の遅延は、NLBにどう影響したのか

　NLBは、主にEC2インスタンスなどのバックエンドサービスにトラフィックをルーティングする、スケーラブルなマルチテナントアーキテクチャ上に構築されている。このアーキテクチャは、NLB内の全てのノードに対して定期的にヘルスチェックを実行し、「不健全」と判断されたノードをサービスから除外する、独立したヘルスチェックサブシステムも利用している。

　NLBでは20日5時30分から接続エラーが増加した。具体的には、ヘルスチェックサブシステムが新しいEC2インスタンスをサービスに組み込む際に、それらインスタンスのネットワーク状態が完全に伝搬されていなかったことで、ヘルスチェックの失敗が増加し、失敗と正常を交互に繰り返す事態に陥ったのだ。

　エンジニアは9時36分に自動ヘルスチェックフェイルオーバーを無効化して安定化させ、EC2正常化後の14時9分に再度、有効化。影響を受けたロードバランサーへの接続エラーの増加は解決された。

その他のサービスへの影響

　DynamoDB、EC2、NLBで起こった障害が原因で影響を受けた主なAWSのサービスは以下の通り。

• AWS Lambda
• Amazon Elastic Container Service（ECS）
• Amazon Elastic Kubernetes Service（EKS）
• AWS Fargate
• Amazon Connect
• AWS Security Token Service（STS）
• AWS マネジメントコンソール
• AWS IAM Identity Center
• Amazon Redshift
• AWS サポートコンソールおよびAPI

再発防止策

　再発抑止策としてAWSは、DynamoDBのDNSプランナー／エナクターの自動化を停止し、競合状態を排除する保護を追加する方針を打ち出している。EC2には既存のスケールテストを補完する追加のテストスイートを構築し、DWFMリカバリーワークフローを実行して将来の機能低下を特定できるようにする。待機キューのサイズに基づいてリクエストを制限するEC2データ伝搬システムの制御メカニズムを改善する計画だ。NLBにはAZ（アベイラビリティーゾーン）フェイルオーバー時の除外量を抑える速度制御を追加するという。