🙌

[AWS] 2025年10月19日に起きたDynamoDBのインシデントレポートを読み解いてみる

に公開
AWS
DynamoDB
tech

はじめに

このブログでは、AWSの2025年10月19日に起きたDynamoDBのインシデントレポートを2025年10月27日時点で読んで、私が理解したことを書いているものです。レポートの中では、DynamoDBの他、EC2やNLB、その他問題についても紹介していますが、本エントリではDynamoDBの話にフォーカスします。また、ブログ内容自体には間違いが含まれる可能性がありますので、ご承知おきください。また、間違いについてはコメント等でお知らせいただけると嬉しいです。

問題概要: DynamoDBのエンドポイントのDNSレコードが空になる

今回の一連の問題は、DynamoDBのエンドポイントを名前解決ができなくなったことに端を発しています。そして、それはAWS内部で使っているDynamoDBのDNS管理システムの問題によるものでした。
通常のシステムと同様に、DyanamoDBはDNSレコードの更新によりスケーリングや耐障害のためのノードの増減、移行などなどに対応しているわけですが、そのDNSレコードを管理するDNS管理システムの不具合により、us-east-1のDynamoDBのリージョンエンドポイントのDNSレコード自体が空になってしまい、エンドポイントに接続できなくなり、DynamoDB利用者や、AWSの複数サービス含むDynamoDBに依存するサービスに異常が発生していました。


通常時と今回の異常時の名前解決 (IPアドレスが返らない)

なぜDynamoDBのエンドポイントのDNSレコードが空になったのか？

DynamoDBのDNS管理システムの問題と前述しましたが、今回のレポートの中では、その説明をするために、DNS管理システムの仕組みが記載されています。まずはこれを理解しないと今回の問題の詳細に踏み込めないので、そちらを先に説明します。

DynamoDBのDNS管理システムの仕組み

DynamoDBのDNS管理システムには、DNSプランナーとDNSエンアクターというコンポーネントがあり、それぞれ以下の役割があるそうです。

  • DNSプランナー: DNSレコードの更新プランを作成
  • DNSエンアクター: 更新プランの変更内容を実際にAmazon Route53に適用

図で表すと下記のようになります。


DynamoDBのDNS管理システム

そもそも、単にDNSレコードを更新するならば、こんな複雑なことしなくても良いのでは？と思うかもしれませんが、Route 53では、フェイルオーバーや地理的情報によるローカリティなどルーティングポリシーの設定もあるため、それらを含めた更新作業が必要なのだと思います。

DNSエンアクターは、同時に複数が動作し、プランナーが作成したプランを随時適用します。各DNSエンアクターのフローチャートは以下のようになります。


DNSエンアクターのフローチャート

図に記載の通り、DNSエンアクターは以下の処理を実行します。

  1. 最新プラン取得：DNSプランナーが作成したプランのうち、最新のものを取得
  2. プランの新旧チェック：適用しようとしているプランが今アクティブなプランより新しいかどうかチェックし、古い場合には適用を取りやめ
  3. プラン適用：新旧チェックで新しいと判断された場合、プランを実際にRoute 53へと適用
  4. クリーンアップ：(おそらくDNS管理システム内で管理しているデータストアから)世代が大きく古いプランをクリーンアップ

このようにして、DynamoDBのリージョンエンドポイントのDNSは常に最新を保って更新をされています。

DNSエンアクターの競合問題によるプランの削除とDNSレコードの削除

さて、前述のDNSエンアクターですが、複数のインスタンスが並列に動作するよう設計されています。よって、プランが大量に発生するような場合には、DNSエンアクターによる適用処理が同時に走る可能性があります。
平時においては、同時に走っても問題なかったのですが、今回は、たまたま、下記の複合要因が重なり、問題が発生する状況になってしまいました。

  1. DNSプランナーが多数のプランを短期間に作成
  2. DNSエンアクターのプラン適用が普段より長時間化

上記の2つの事象により、2つの同時起動されたエンアクター(A),(B)の間で、(1)エンアクター(A)がアクティブにしてしまった世代的に古いプランを、(2)他の後発のエンアクターがクリーンアップ処理でそのアクティブな古いプランを消す、ということが起きるパターンにはまってしまいました。
アクティブなプランのデータが消されるというのは、通常想定される自体では(おそらく)なく、管理システムはこれをトリガーに、Route 53からそのプランのIPアドレスに該当するレコードを削除してしまう挙動を引き起こし、更には内部状態として不正な状態に陥ってしまいました。

下記にそのエンアクター部分のチャートを記載します。(フローチャートで時間を表現するのは良くないと思いますが、手間削減のため許してください。。。)


2つのDNSエンアクター(A)(B)による競合問題の発生

これによって、us-east-1のDynamoDBのリージョンエンドポイントに対するDNSのクエリのレスポンスが空になり、今回の事象を引き起こしました。
また、これは内部的に不整合な状態として判断され、自動で修復はできず、手動によるレコードの更新が必要となったことで問題の長期化につながりました。

まとめ

こういう競合状態の問題などのバグは往々にして、後から気をつけてみてみれば、なぜこのような事態になることに気づかなかったのだろう、と思うものです。AWSのような企業でもこういう実装上の問題は作り込むのだなと安心(？)しました。
いくつか明記されていない気になる点はいくつか残りますが、それにしてもこの短期間で内部の構造含めて、詳細を公開できるのは素晴らしいことだと思います。
また、障害時の対応を自動化するのはベストプラクティスですが、自動化ツールが動かなかったときのオペレーションを実際に考えておいて実施するのはかなり困難なことだと思います。今回、AWSはこの競合状態の問題のため、自動化システムを一時停止しているとのことですが、その上で実際に稼働維持をし続けられている点も素晴らしいことだなと感じます。

その他

この延長で、dynamodb.us-east-1.amazonaws.comの名前解決をしてみたとき、TTLが5secと非常に短かったこと、1つのIPアドレスしか返ってこなかったのが印象的でした。Google CloudのBigTableやSpannerはTTLが300秒か少し低いくらいで、多数のIPアドレスが返ってきています。これは、設計思想として、DynamoDBはOSのネットワーク層がDNSのTTL超過によって単一の最新の別のIPを取得する一方で、BigTableやSpannerはクライアント側のSDKがリトライ時に別IPを採用することで対応する、となっているのかなと。

※もしかしたらこのDynamoDBのリージョンエンドポイントのDNS設定はこの異常の対応のために一時的に設定しているだけかもしれないので、また時を置いてチェックしてみたいと思います。

Discussion