【第一期】AWSのDynamoDBサービス中断

AWSのサービス中断に関する技術レポート（第一期）

概要

2025年10月19日および20日に(us-east-1)リージョンで発生したサービス中断について、AWSの外部声明/技術レポートに基づく要約

10月19日午後11時48分から10月20日午前2時40分まで、Amazon DynamoDBは(us-east-1)リージョンでAPIエラー率の上昇を経験しました。

• 事象発生：2025-10-20 06:49 UTC / 15:49 JST / Oct 19 11:49 PM PDT
• 事象緩和：2025-10-20 09:24 UTC / 18:24 JST / 2:24 AM PDT

DynamoDB 障害詳細

障害発生期間

2025年10月19日午後11時48分(PDT)から10月20日午前2時40分(PDT)まで

影響

リージョンでAmazon DynamoDB APIエラー率の増加を経験しました。この期間中、お客様およびDynamoDBに依存する他のAWSサービスは、サービスへの新規接続を確立できませんでした。

技術背景

多くの主要なAWSサービスは、シームレスなスケール、障害分離と復旧、低レイテンシー、およびロカリティを提供するためにDNSに大きく依存しています。DynamoDBのようなサービスは、各リージョンで非常に大規模で多様なロードバランサーフリートを運用するために、数十万のDNSレコードを維持しています。

自動化は、これらのDNSレコードを頻繁に更新したり、ハードウェア障害を正しく処理したり、お客様の体験を最適化するためにトラフィックを効率的に分散させることを保証するために極めて重要です。この自動化はレジリエンス（回復力）を持つように設計されており、サービスがさまざまな運用上の問題から回復できるようにしています。

DynamoDB DNS管理アーキテクチャ

システムは可用性の理由から、二つの独立したコンポーネントに分割されています：

1.DNS Planner

• ロードバランサーの健全性と容量を監視
• 各サービスエンドポイントの新しいDNSプランを定期的に作成
• ロードバランサーとウェイトのセットで構成
• 単一のリージョンDNSプランを生成（容量管理と障害緩和が大幅に簡素化）

1. DNS Enactor

• 最小限の依存関係を持つように設計されて、あらゆるシナリオでシステム回復を可能にする
• Amazon Route 53サービスで必要な変更を適用することでDNSプランを実行
• 回復力のために、3つの異なるアベイラビリティゾーン(AZ)で冗長かつ完全に独立して動作
• 各インスタンスは新しいプランを探し、Route 53トランザクションを使用して現在のプランを新しいプランに置き換えることでRoute 53を更新

レースコンディションの発生メカニズム

通常の動作：

1. DNS Enactorが最新のプランを取得し、サービスエンドポイントに適用（このプロセスは通常迅速に完了し、DNSの状態を常に最新に保つ上で効果的に機能する。）
2. 新しいプランを適用する前に、DNS Enactorはそのプランが以前に適用されたプランよりも新しいことを一度だけチェック

異常な状況の発生：

1. イベント直前、一つのDNS EnactorがいくつかのDNSエンドポイントで更新を再試行する際に異常に高い遅延を経験
2. エンドポイントをゆっくり処理している間、他の出来事も同時に発生：
   • DNS Plannerが実行を続け、多くの新しい世代のプランを生成
   • 別のDNS Enactorが新しいプランの一つを適用し始め、全てのエンドポイントを迅速に進行

レースコンディションのトリガー

1. 第1のEnactor（最新のプランを適用）がエンドポイント更新を完了すると、プランクリーンアッププロセスを呼び出す
2. クリーンアッププロセスは、適用したプランよりも大幅に古いプランを識別して削除
3. 同時に、第1のEnactor（異常に遅延していた）が、はるかに古いプランをリージョナルDDBエンドポイントに適用し、新しいプランを上書き
4. プラン適用プロセスの開始時に行われたチェックは、Enactor処理の異常に高い遅延により、この時点で古くなっていた
5. 従って、これは古いプランが新しいプランを上書きすることを防げなかった
6. 第2のEnactorのクリーンアッププロセスが、適用したプランよりも多くの世代古いため、この古いプランを削除
7. このプランが削除されると、リージョナルエンドポイントのすべてのIPアドレスが即座に削除された
8. さらに、アクティブなプランが削除されたため、システムは不整合な状態に陥り、その後のプラン更新がDNS Enactorによって適用されることを防いだ
9. この状況は最終的に手動オペレーターの介入を必要とした

タイムライン