以下のAWSが公式に公表した記事を参考に、先日（2025/10/19, 20）に発生したAWSの障害の詳細を解説します。
影響が出たのは合計で3日間
今回の障害発生で影響が出た期間は合計で３日間です。
このイベントは 10 月 19 日午後 11 時 48 分 (PDT) に始まり、10 月 20 日午後 2 時 20 分 (PDT) に終了しましたが、お客様のアプリケーションに影響が出た期間は 3 日間ありました。
影響（障害、サービス中断）が発生した流れ
AWSのサービスが中断した流れについて解説します。
まず、10 月 19 日午後 11 時 48 分から 10 月 20 日午前 2 時 40 分までの間、バージニア北部 (us-east-1) リージョンで Amazon DynamoDB の API エラー率が増加しました。次に、10 月 20 日午前 5 時 30 分から午後 2 時 9 分までの間、バージニア北部 (us-east-1) リージョンの一部のロードバランサーで Network Load Balancer (NLB) の接続エラーが増加しました。これは、NLB フリートのヘルスチェックの失敗が原因で、一部の NLB で接続エラーが増加しました。 3 つ目は、10 月 20 日午前 2 時 25 分から午前 10 時 36 分まで、新しい EC2 インスタンスの起動に失敗しました。午前 10 時 37 分からはインスタンスの起動が成功し始めましたが、新しく起動されたインスタンスの一部で接続の問題が発生しましたが、午後 1 時 50 分までに解決されました。
まず、アメリカ合衆国バージニア北部リージョンでAmazon DynamoDB APIのエラー率が増加しました。その次に、同リージョンでNLB（ロードバランサー、複数のサーバーやネットワーク機器を使うことで通信の負荷分散する機能を持っているサービスのこと）の接続エラーが増加しました。
この間、EC2インスタンスの起動にも失敗するという事象が発生しました。EC2インスタンスとは、AWS上に仮想サーバーを立ち上げるAWSのサービスです。
なぜ障害発生に至ったか、その原因はDNSの管理の問題
今回のサービスの障害の原因は、「サービスの自動DNS管理システム」に存在していた欠陥によるものです。
このインシデントは、サービスの自動DNS管理システムに潜在的に存在する欠陥によって発生し、DynamoDBのエンドポイント解決に失敗することが原因でした。
そもそもDynamo DBとは
DynamoDB はサーバーレスのデータベースです。特にEC2等で仮想マシンを立ち上げたり、オンプレミスのサーバーにデータベースを作成せずともAWSのサービスとしてデータベースが提供されるサービスになります。
Amazon DynamoDB は、サーバーレスのフルマネージド NoSQL データベースで、あらゆる規模で 1 桁ミリ秒のパフォーマンスを実現します。
DNSとは
DNSは、IPアドレスとドメイン名を紐づけるサービスです。AWSでも使用されている技術になります。
DNS (ドメインネームシステム) は、人間が読み取れるドメイン名 (www.amazon.com など) を機械が読み取れる IP アドレス (192.0.2.44 など) に変換します。
以下の記事でもDNSの詳細を解説しています。
Dynamo DBを最適に運用するために、AWSはDNSの管理を自動化していた
Dynamo DBを運用するにあたって、AWSはDNSの管理を自動化して運用していました。
DynamoDB のようなサービスは、各リージョンで非常に大規模で異機種混在のロードバランサー群を運用するために、数十万もの DNS レコードを管理しています。これらの DNS レコードを頻繁に更新し、キャパシティが利用可能になったときに追加し、ハードウェア障害を適切に処理し、トラフィックを効率的に分散して顧客エクスペリエンスを最適化するためには、自動化が不可欠です。この自動化は、サービスがさまざまな運用上の問題から回復できるように、耐障害性を考慮して設計されています。
誤った空の DNS レコードが生成され、自動化では修復できなかった
Dynamo DBの運用に関して、DNSの管理システムは自動化されています。
このDNS管理サービスにて、誤った空の DNS レコードが生成され、最終的に手動での操作が必要な状態となりサービスの中断に至ったとのこと。
この問題の根本原因は、DynamoDB DNS 管理システムにおける潜在的な競合状態であり、その結果、サービスのリージョンエンドポイント (
dynamodb.us-east-1.amazonaws.com ) に誤った空の DNS レコードが生成されていました。) が発生し、自動化では修復できませんでした。（中略）
さらに、アクティブなプランが削除されたため、システムは不整合な状態のままになり、後続のプラン更新をどの DNS Enactor でも適用できなくなりました。この状況を修正するには、最終的にオペレータの手動介入が必要になりました。
