米国東部（バージニア北部、US-EAST-1）リージョンにおける Amazon DynamoDB サービス中断の概要
※本情報は米国で2025年10月23日に公開された情報の翻訳です。
2025 年 10 月 19 日 PDT から 10 月 20 日 PDT (日本時間 2025 年 10 月 20 日から 10 月 21 日) にかけて、米国東部（バージニア北部、us-east-1) リージョンで発生したサービス障害について、追加情報をお知らせいたします。この事象は 10 月 19 日午後 11 時 48 分 PDT (日本時間 10 月 20 日午後 3 時 48 分) に始まり、10 月 20 日午後 2時 20 分 PDT (日本時間 10 月 21 日午前 6 時 20 分) に終了しましたが、お客様のアプリケーションには 3 つの異なる時間軸で影響がありました。
第一に、10 月 19 日午後 11 時 48 分 PDT から 10 月 20 日午前 2 時 40 分 PDT (日本時間 10 月 20 日午後 3 時 48 分から 10 月 20 日午後 6 時 40 分) の間、Amazon DynamoDB において、米国東部（バージニア北部、us-east-1) リージョンで API エラー率が上昇しました。
第二に、10 月 20 日午前 5 時 30 分 PDT から午後 2 時 09 分 PDT (日本時間 10 月 20 日午後 9 時 30 分から 10 月 21 日午前 6 時 09 分) の間、Network Load Balancer (NLB) において、米国東部（バージニア北部、(us-east-1) リージョンの一部のロードバランサーで接続エラーの増加が発生しました。これは NLB フリートのヘルスチェック失敗が原因で、一部の NLB で接続エラーが増加しました。
第三に、10 月 20 日午前 2 時 25 分 PDT から午前 10 時 36 分 PDT (日本時間 10 月 20 日午後 6 時 25 分から 10 月 21 日午前 2 時 36 分) の間、新規 EC2 インスタンスの起動が失敗し、午前 10 時 37 分 PDT (日本時間 10 月 21 日午前 2 時 37 分) からインスタンスの起動は成功し始めたものの、新しく起動されたインスタンスの一部で接続の問題が発生し、これは午後 1 時 50 分 PDT (日本時間 10 月 21 日午前 5 時 50 分) に解決されました。
DynamoDB
10 月 19 日午後 11 時 48 分 PDT から 10 月 20 日午前 2 時 40 分 PDT (日本時間 10 月 20 日午後 3 時 48 分から 10 月 20 日午後 6 時 40 分) にかけて、バージニア北部 (us-east-1) リージョンにおいて、Amazon DynamoDB API のエラー率が上昇しました。この期間中、お客様や DynamoDB に依存関係を持つ他の AWS サービスは、DynamoDB サービスへの新規接続を確立することができませんでした。この障害は、サービスの自動 DNS マネジメントシステム内の潜在的な欠陥によって引き起こされ、DynamoDB エンドポイントの名前解決の失敗を招きました。
多くの大規模な AWSのサービスは、シームレスなスケーリング、障害の分離と復旧、低レイテンシー、およびローカリティを提供するために DNS に大きく依存しています。DynamoDB のようなサービスは、各リージョンで非常に大規模な異種混在のロードバランサーフリートを運用するために、数十万の DNS レコードを保持しています。利用可能な容量の追加、ハードウェア障害の適切な処理、顧客体験を最適化するためのトラフィックの効率的な分散を確実にするため、自動化が極めて重要です。この自動化は、運用上の様々な問題から復旧できるよう、回復力（レジリエンス）を考慮して設計されています。パブリックリージョナルエンドポイントの提供に加えて、この自動化は、FIPS 準拠エンドポイント、IPv6 エンドポイント、アカウント固有のエンドポイントなど、複数の動的 DynamoDB バリアント用の追加の DNS エンドポイントを保持しています。 この問題の根本原因は、DynamoDB DNS マネジメントシステムにおける潜在的な競合状態（レースコンディション）により、サービスのリージョナルエンドポイント (dynamodb.us-east-1.amazonaws.com) に対して空の DNS レコードが誤って生成され、自動化システムがそれを修復できなかったことでした。この事象を説明するために、DynamoDB DNS マネジメントアーキテクチャについて詳細の一部を共有します。
このシステムは可用性のために、2 つの独立したコンポーネントに分かれています。最初のコンポーネントである DNS プランナーは、ロードバランサーの健全性と容量を監視し、定期的に各サービスエンドポイントに対して、ロードバランサーとウェイトのセットで構成される新しい DNS プランを作成します。最近導入された IPv6 エンドポイントやパブリックリージョナルエンドポイントのように、容量が複数のエンドポイント間で共有される場合、容量管理と障害緩和を大幅に簡素化するため、単一のリージョナル DNS プランを生成します。
2 つ目のコンポーネントである DNS エナクターは、あらゆるシナリオでシステム回復を可能にするために最小限の依存関係で設計されており、Amazon Route53 サービスで必要な変更を適用してDNS プランを実行します。レジリエンスのため、DNS エナクターは 3 つの異なるアベイラビリティーゾーン (AZ) で冗長かつ完全に独立して動作します。これらの独立した DNS エナクターのインスタンスはそれぞれ新しいプランを探し、Route53 トランザクションを使用して現在のプランを新しいプランに置き換えることで Route53 の更新を試みます。これにより、複数の DNS エナクターが同時に更新を試みる場合でも、各エンドポイントが一貫したプランで更新されることが保証されます。
競合状態は、2 つの DNS エナクター間のまれな相互作用に関係しています。通常の動作では、DNS エナクターは最新のプランを取得し、このプランを適用するためにサービスエンドポイントを順次処理していきます。このプロセスは通常、迅速に完了し、DNS の状態を最新に保つ効果的な役割を果たします。新しいプランの適用を開始する前に、DNS エナクターは自身のプランが以前に適用されたプランよりも新しいことを一度だけ確認します。DNS エナクターがエンドポイントのリストを処理する際、別の DNS エナクターが同じエンドポイントを更新している場合にトランザクションがブロックされ、遅延が発生する可能性があります。このような場合、DNS エナクターは全てのエンドポイントにプランが正常に適用されるまで、各エンドポイントの更新を再試行します。
今回の事象が始まる直前、1 つの DNS エナクターが複数の DNS エンドポイントの更新を再試行する必要があり、異常に大きな遅延が発生しました。エンドポイントの処理に時間がかかっている間に、他のいくつかの事象も発生していました。まず、DNS プランナーは継続して実行され、多くの新しい世代のプランを生成しました。次に、別の DNS エナクターが新しいプランの 1 つを適用し始め、全てのエンドポイントを急速に処理しました。これらの事象のタイミングが潜在的な競合状態を引き起こしました。
最新のプランを適用する 2 つ目のエナクターがエンドポイントの更新を完了したとき、適用したプランよりも大幅に古いプランを特定して削除するプランクリーンアッププロセスを呼び出しました。このクリーンアッププロセスが呼び出されたのと同時に、異常に遅延していた 1 つ目のエナクターが、かなり古いプランをリージョナル DynamoDB エンドポイントに適用し、新しいプランを上書きしました。プラン適用プロセスの開始時に行われる、プランが以前に適用されたプランよりも新しいことを確認するチェックは、エナクターによる適用が高遅延により異常に遅れたことで、古いプランが新しいプランを上書きするのを防ぐことができませんでした。
2 つ目のエナクターのクリーンアッププロセスは、このプランが適用したばかりのプランよりも何世代も古かったため、この古いプランを削除しました。このプランが削除されると、リージョナルエンドポイントの全ての IP アドレスが直ちに削除されました。さらに、アクティブなプランが削除されたため、システムは一貫性のない状態となり、その後のプラン更新がどの DNS エナクターによっても適用できなくなりました。この状況において、最終的に、オペレーターによる手動での介入による修正が必要となりました。
この問題が午後 11 時 48 分 PDT (日本時間 10 月 20 日午後 3 時 48 分) に発生した際、米国東部（バージニア北部、us-east-1) リージョンのパブリックエンドポイントを介して DynamoDB サービスに接続する必要のあるすべてのシステムが、一瞬にして DNS の障害に影響を受け、DynamoDB への接続に失敗しました。これには、お客様のトラフィックだけでなく、DynamoDB に依存するAWS 内部のサービスからのトラフィックも含まれていました。DynamoDB のグローバルテーブルを使用しているお客様は、他のリージョンのレプリカテーブルへの接続とリクエストの発行は正常に行えましたが、他のリージョンのレプリカテーブルとバージニア北部 (us-east-1) リージョンのレプリカテーブルとの間でレプリケーション遅延が発生しました。影響を受けた AWS サービスのエンジニアリングチームは直ちに対応し、調査を開始しました。10 月 20 日午前 12 時 38 分 PDT (日本時間 10 月 20 日午後 4 時 38 分) までに、エンジニアは DynamoDB の DNS の状態が障害の原因であることを特定しました。午前 1 時 15 分 PDT (日本時間 10 月 20 日午後 5 時 15 分) までに、適用された一時的な緩和策により、一部の内部サービスが DynamoDB に接続できるようになり、重要な内部ツールが修復されたことによって、さらなる回復操作が可能になりました。午前 2 時 25 分 PDT (日本時間 10 月 20 日午後 6 時 25 分) までに、すべての DNS 情報が復元され、すべてのグローバルテーブルのレプリカは午前 2 時 32 分 PDT (日本時間 10 月 20 日午後 6 時 32 分) までに完全に同期が完了しました。午前 2 時 25 分 PDT から午前 2 時 40 分 PDT (日本時間 10 月 20 日午後 6 時 25 分から午後 6 時 40 分)にかけて、キャッシュされた DNS レコードの有効期限が切れるにつれて、お客様は DynamoDB エンドポイントを名前解決し、正常な接続を確立できるようになりました。これにより、主要なサービスの中断イベントからの復旧が完了しました。
Amazon EC2
10 月 19 日午後 11 時 48 分 PDT から 10 月 20 日午後 1 時 50 分 PDT (日本時間 10 月 20 日午後 3 時 48 分から 10 月 21 日午前 5 時 50 分) にかけて、米国東部（バージニア北部、us-east-1) リージョンにおいて、EC2 API のエラー率の上昇、レイテンシーの増加、およびインスタンス起動の失敗が発生しました。イベント発生前に起動済みの既存の EC2 インスタンスは正常な状態を維持し、イベント期間中の影響を受けませんでした。午前 2 時 25 分 PDT (日本時間 10 月 20 日午後 6 時 25 分) に DynamoDB DNSの問題を解決した後も、新規インスタンスの起動において引き続きエラーが発生しました。復旧は午後 12 時 01 分 PDT (日本時間 10 月 21 日午前 4 時 01 分) に開始され、EC2 の完全復旧は午後 1 時 50 分 PDT (日本時間 10 月 21 日午前 5 時 50 分) に完了しました。この期間中、新規インスタンスの起動は「request limit exceeded」または「insufficient capacity」エラーで失敗しました。
何が起きたのかを説明するために、EC2 インスタンスの起動管理と、新しく起動された EC2 インスタンスのネットワーク接続設定に使用されるいくつかのサブシステムについて共有します。1 つ目のサブシステムは、DropletWorkflow Manager (DWFM) で、EC2 インスタンスのホスティングに使用される全ての物理サーバー (これらのサーバーを「ドロップレット」と呼びます) の管理を担当します。2 つ目のサブシステムは、Network Manager で、全てのEC2 インスタンスとネットワーク機器に対するネットワーク状態の管理と伝播を担当します。各 DWFM は、各アベイラビリティーゾーン内の一連のドロップレットを管理し、現在管理下にある各ドロップレットのリースを維持します。このリースによって、DWFM はドロップレットの状態を追跡し、EC2 API からの全てのアクション、または EC2 インスタンスのオペレーティングシステムから発生するシャットダウンやリブートなどの操作が、より広範な EC2 システム内で正しい状態変更として反映されることを保証します。このリースの維持の一環として、各 DWFM ホストは、管理下にある各ドロップレットに数分ごとにチェックインを行い、状態チェックを完了する必要があります。
10 月 19 日午後 11 時 48 分 PDT (日本時間 10 月 20 日午後 3 時 48 分) から、DynamoDB に依存するプロセスが完了できなかったため、これらのDWFM の状態チェックが失敗し始めました。これは実行中の EC2 インスタンスには影響を与えませんでしたが、ホストしている EC2 インスタンスのそれ以降の状態変更が行われる前に、ドロップレットが DWFM と新しいリースを確立する必要が生じました。10 月 19 日午後 11 時 48 分 PDT から 10 月 20 日午前 2 時 24 分 PDT (日本時間 10 月 20 日午後 3 時 48 分から午後 6 時 24 分) の間に、DWFM と EC2 フリート内のドロップレット間のリースが徐々にタイムアウトし始めました。
10 月 20 日午前 2 時 25 分 PDT (日本時間 10 月 20 日午後 6 時 25 分) 、DynamoDB API の復旧に伴い、DWFM は EC2 フリート全体のドロップレットとのリースの再確立を開始しました。アクティブなリースを持たないドロップレットは新しい EC2 起動の候補とみなされないため、EC2 API は新規の EC2 起動リクエストに対して「insufficient capacity」のエラーを返していました。DWFM は EC2 フリート全体のドロップレットとのリースの再確立を開始しましたが、ドロップレットの数が多く、新しいドロップレットリースを確立する作業がタイムアウトする前に完了できないほど長時間かかりました。ドロップレットリースの確立を再試行するための追加作業がキューに入れられました。この時点で、DWFM は輻輳崩壊の状態に陥り、ドロップレットリースの回復において進展を見せることができませんでした。この状況には確立された運用回復手順がなかったため、エンジニアは更なる問題を引き起こすことなく DWFM の問題を解決しようと慎重に対応しました。複数の緩和策を試みた後、午前 4 時 14 分 PDT (日本時間 10 月 20 日午後 8 時 14 分) にエンジニアは受信作業をスロットルし、この状況から回復するために DWFM ホストの選択的な再起動を開始しました。DWFM ホストの再起動により、DWFM のキューがクリアされ、処理時間が短縮され、ドロップレットリースの確立が可能になりました。午前 5 時 28 分 PDT (日本時間 10 月 20 日午後 9 時 28 分) までに、DWFM はバージニア北部 (us-east-1) リージョン内のすべてのドロップレットとリースを確立し、新規起動が再び成功し始めましたが、全体的なリクエスト負荷を減らすために導入されたリクエストのスロットルにより、多くのリクエストは依然として「request limit exceeded」のエラーを表示していました。
新しい EC2 インスタンスが起動される際、Network Manager と呼ばれるシステムが、同じ Virtual Private Cloud (VPC) 内の他のインスタンス、他の VPC ネットワーク機器、およびインターネットとの通信を可能にするネットワーク設定を伝播します。午前 5 時 28 分 PDT (日本時間 10 月 20 日午後 9 時 28 分)、DWFM の復旧直後、Network Manager は新しく起動されたインスタンスと、イベント中に終了されたインスタンスに対して、更新されたネットワーク設定の伝播を開始しました。これらのネットワーク伝播イベントは DWFM の問題により遅延していたため、バージニア北部 (us-east-1) リージョンの Network Manager で処理する必要のあるネットワーク状態伝播の大きなバックログが発生していました。その結果、午前 6 時 21 分 PDT (日本時間 10 月 20 日午後 10 時 21 分)、Network Manager はバックログのネットワーク状態変更を処理する際に、ネットワーク伝播時間の増加を観測し始めました。新しい EC2 インスタンスは正常に起動できたものの、ネットワーク状態伝播の遅延により、必要なネットワーク接続が確立できない状態でした。エンジニアは Network Manager の負荷を軽減してネットワーク設定伝播時間に対処し、復旧を加速するための対策を講じました。午前 10 時 36 分 PDT (日本時間 10 月 21 日午前 2 時 36 分) までに、ネットワーク設定伝播時間は通常のレベルに戻り、新しい EC2 インスタンスの起動も再び正常に動作するようになりました。
EC2 の完全な復旧に向けた最後のステップは、様々な EC2 サブシステムへの負荷を軽減するために設置されていたリクエストスロットルを完全に解除することでした。API コールと新しい EC2 インスタンス起動リクエストが安定化したため、午前 11 時 23 分 PDT (日本時間 10 月 21 日午前 3 時 23 分) に、エンジニアは完全な復旧に向けてリクエストスロットルの緩和を開始しました。午後 1 時 50 分 PDT (日本時間 10 月 21 日午前 5 時 50 分) には、すべての EC2 API と新しい EC2 インスタンスの起動が正常に動作するようになりました。
Network Load Balancer (NLB)
新規に起動された EC2 インスタンスのネットワーク状態伝播の遅延は、Network Load Balancer (NLB) サービスおよび NLB を使用する AWS サービスにも影響を及ぼしました。10 月 20 日午前 5 時 30 分 PDT から午後 2 時 09 分 PDT (日本時間 10 月 20 日午後 9 時 30 分から 10 月 21 日午前 6 時 09 分) にかけて、一部のお客様において、バージニア北部 (us-east-1) リージョンの NLB で接続エラーの増加が生じました。NLB は、負荷分散エンドポイントを提供し、主に EC2 インスタンスなどのバックエンドターゲットにトラフィックをルーティングする、高度にスケーラブルなマルチテナントアーキテクチャ上に構築されています。このアーキテクチャは、NLB アーキテクチャ内のすべてのノードに対して定期的にヘルスチェックを実行し、不健全と判断されたノードをサービスから除外する、独立したヘルスチェックサブシステムも利用しています。
イベント中、NLB ヘルスチェックサブシステムでヘルスチェックの失敗が増加し始めました。これは、ヘルスチェックサブシステムが新しい EC2 インスタンスをサービスに組み込む際に、それらのインスタンスのネットワーク状態が完全に伝播されていなかったことが原因でした。これにより、基盤となる NLB ノードとバックエンドターゲットが正常であるにもかかわらず、ヘルスチェックが失敗するケースが発生しました。その結果、ヘルスチェックが失敗と正常を交互に繰り返すことになりました。これにより、NLB ノードとバックエンドターゲットが DNS から除外され、次のヘルスチェックが成功した時点で再びサービスに戻されるという状況が発生しました。
監視システムは午前 6 時 52 分 PDT (日本時間 10 月 20 日午後 10 時 52 分) にこれを検知し、エンジニアが問題の解決に取り掛かりました。交互に発生するヘルスチェック結果は、ヘルスチェックサブシステムの負荷を増加させ、システムの性能が低下し、ヘルスチェックの遅延が発生し、自動的な AZ DNS フェイルオーバーがトリガーされました。マルチ AZ ロードバランサーの場合、これによりキャパシティがサービスから除外されました。この場合、残りの正常なキャパシティがアプリケーションの負荷を処理するのに不十分であった場合、アプリケーションで接続エラーが増加しました。午前 9 時 36 分 PDT (日本時間 10 月 21 日午前 1 時 36 分) に、エンジニアは NLB の自動ヘルスチェックフェイルオーバーを無効化し、利用可能な正常な NLB ノードとバックエンドターゲットをすべてサービスに復帰させることができました。これにより、影響を受けたロードバランサーへの接続エラーの増加は解決されました。EC2 が回復した直後の午後 2 時 09 分 PDT (日本時間 10 月 21 日午前 6 時 09 分) に、自動 DNS ヘルスチェックフェイルオーバーを再度有効化しました。
その他の AWS のサービス
10 月 19 日午後 11 時 51 分 PDT から 10 月 20 日午後 2 時 15 分 PDT (日本時間 10 月 20 日午後 3 時 51 分から 10 月 21 日午前 6 時 15 分) の間、米国東部（バージニア北部、us-east-1) リージョンにおいて、Lambda 関数の API エラーと遅延が発生しました。当初、DynamoDB エンドポイントの問題により、関数の作成と更新が妨げられ、SQS および Kinesis イベントソースの処理遅延と呼び出しエラーが発生しました。午前 2 時 24 分 PDT (日本時間 10 月 20 日午後 6 時 24 分) までに、SQS キューのポーリングを担当する内部サブシステムが故障し自動復旧しなかったことで影響を受け続けた SQS キュー処理を除き、サービス運用は回復しました。このサブシステムを午前 4 時 40 分 PDT (日本時間 10 月 20 日午後 8 時 40 分) に復旧し、午前 6 時 PDT (日本時間 10 月 20 日午後 10 時) までにすべてのメッセージのバックログを処理しました。午前 7 時 04 分 PDT (日本時間 10 月 20 日午後 11 時 04 分) より、NLB ヘルスチェックの失敗によりインスタンスが終了し、Lambda の内部システムの一部がスケール不足となりました。EC2 の起動が依然として影響を受けていたため、レイテンシーに敏感な同期呼び出しを優先するために Lambda イベントソースマッピングと非同期呼び出しをスロットルしました。午前 11 時 27 分 PDT (日本時間 10 月 21 日午前 3 時 27 分) までに十分な容量が回復し、エラーは収まりました。その後、段階的に抑制を解除し、午後 2 時 15 分 PDT (日本時間 10 月 21 日午前 6 時 15 分) までにすべてのバックログを処理し、通常のサービス運用が再開されました。
10 月 19 日 午後 11 時 45 分 PDT から 10 月 20 日午後 2 時 20 分 PDT (日本時間 10 月 20 日午後 3 時 45 分から 10 月 21 日午前 6 時 20 分) の間、米国東部（バージニア北部、us-east-1) リージョンにおいて、Amazon Elastic Container Service (ECS)、Elastic Kubernetes Service (EKS)、およびFargate でコンテナ起動の失敗とクラスターのスケーリングの遅延が発生しました。これらのサービスは午後 2 時 20 分 PDT (日本時間 10 月 21 日午前 6 時 20 分) までに回復しました。
10 月 19 日午後 11 時 56 分 PDT から 10 月 20 日午後 1 時 20 分 PDT (日本時間 10 月 20 日午後 3 時 56 分から 10 月 21 日午前 5 時 20 分) の間、米国東部（バージニア北部、us-east-1) リージョンにおいて、Amazon Connect の通話、チャット、およびケース処理において高頻度のエラーが発生しました。DynamoDB エンドポイントの復旧後、ほとんどの Connect 機能は回復しましたが、午前 5 時 PDT (日本時間 10 月 20 日午後 9 時) までチャットにおいて引き続き高頻度のエラーが発生しました。午前 7 時 04 分 PDT (日本時間 10 月 20 日午後 11 時 04 分) より、Connect が使用する NLBの影響および Lambda 関数呼び出しのエラー率と遅延の増加により、新規の通話、チャット、タスク、メール、およびケース処理においてエラーが再び増加しました。着信者は話中音やエラーメッセージが聞こえる、または接続が失敗しました。エージェント開始および API 開始の発信通話は失敗しました。応答された通話では、プロンプト再生の失敗、エージェントへのルーティング失敗、または無音が発生しました。さらに、エージェントのコンタクト処理において高頻度のエラーが発生し、一部のエージェントはサインインできませんでした。API と Contact Search へのアクセスにおいても高頻度のエラーが発生しました。リアルタイムと履歴のダッシュボード、および分析データレイクのデータ更新は遅延しており、すべてのデータは 10 月 28 日 PDT (日本時間 10 月 29 日) までにバックフィルされる予定です。Lambda 関数呼び出しエラーの回復に伴い、午後 1 時 20 分 PDT (日本時間 10 月 21 日午前 5 時 20 分) にサービスの可用性が復旧しました。
10 月 19 日の午後 11 時 51 分 PDT から午前 9 時 59 分 PDT (日本時間 10 月 20 日午後 3 時 51 分から 10 月 21 日午前 1 時 59 分) にかけて、米国東部（バージニア北部、us-east-1) リージョンにおいて、AWS Security Token Service (STS) API のエラーと遅延が発生しました。内部の DynamoDB エンドポイントの復旧後、午前 1 時 19 分 PDT (日本時間 10 月 20 日午後 5 時 19 分) に STS は回復しました。午前 8 時 31 分 PDT から午前 9 時 59 分 PDT (日本時間 10 月 21 日午前 0 時 31 分から午前 1 時 59 分) の間、NLB ヘルスチェックの失敗により、STS API のエラー率と遅延が再び増加しました。午前 9 時 59 分 PDT (日本時間 10 月 21 日午前 1 時 59 分) までに、NLB ヘルスチェックの失敗から回復し、サービスは通常運用を再開しました。
10 月 19 日午後 11 時 51 分 PDT から 10 月 20 日午前 1 時 25 分 PDT (日本時間 10 月 20 日午後 3 時 51 分から午後 5 時 25 分) にかけて、米国東部（バージニア北部、us-east-1) リージョンの基盤となる DynamoDB の問題により、IAM ユーザーを使用して AWS マネジメントコンソールにサインインしようとした AWS のお客様で認証失敗が増加しました。バージニア北部 (us-east-1) リージョンでIAM Identity Center を構成していたお客様も、Identity Center を使用してサインインすることができませんでした。ルート認証情報を使用するお客様、および signin.aws.amazon.com を使用するように構成されたアイデンティティフェデレーションを使用するお客様は、バージニア北部 (us-east-1) リージョン以外のリージョンで AWS マネジメントコンソールにログインしようとした際にエラーが発生しました。午前 1 時 25 分 PDT (日本時間 10 月 20 日午後 5 時 25 分) にDynamoDB エンドポイントがアクセス可能になり、サービスは通常運用を再開しました。
10 月 19 日午後 11 時 47 分 PDT から 10 月 20 日午前 2 時 21 分 PDT (日本時間 10 月 20 日午後 3 時 47 分から午後 6 時 21 分) の間、米国東部（バージニア北部、us-east-1) リージョンにおいて、Redshift クラスターの作成と変更、または既存クラスターへのクエリ実行時に API エラーを経験しました。Redshift のクエリ処理は、クラスターからのデータの読み書きに DynamoDB エンドポイントを利用しています。DynamoDB エンドポイントが復旧するにつれ、Redshift のクエリ操作も再開し、午前 2 時 21 分 PDT (日本時間 10 月 20 日午後 6 時 21 分) までには、クラスターへのクエリ実行やクラスター設定の作成と変更を正常に行えるようになりました。 しかし、DynamoDB エンドポイントが正常運転に戻った後も、一部の Redshift コンピュートクラスターは障害状態のままでクエリ実行ができない状態が続きました。クラスターノードの認証情報が更新されずに期限切れになると、Redshift の自動化システムは基盤となる EC2 ホストを新しいインスタンスに置き換えるワークフローをトリガーします。EC2 の起動に障害があったため、これらのワークフローがブロックされ、クラスターは「変更中」の状態となり、クエリ処理ができずワークロードに使用できない状態となりました。
午前 6 時 45 分 PDT (日本時間 10 月 20 日午後 10 時 45 分) に、エンジニアがワークフローのバックログの増加を止めるための対策を講じ、午後 2 時 46 分 PDT (日本時間 10 月 21 日午前 6 時 46 分) に Redshift クラスターが代替インスタンスの起動を開始すると、バックログのワークフローの処理が始まりました。10 月 21 日午前 4 時 05 分 PDT (日本時間 10 月 21 日午後 8 時 05 分) までに、AWS オペレーターは置き換えワークフローによって障害が発生したクラスターの可用性を完全に復旧させました。
クラスターの可用性の障害に加えて、10 月 19 日午後 11 時 47 分 PDT から 10 月 20 日午前 1 時 20 分 PDT (日本時間 10 月 20 日午後 3 時 47 分から午後 5 時 20 分) の間、全ての AWS リージョンの Amazon Redshift お客様は、ユーザーグループを解決するためにバージニア北部 (us-east-1) リージョンの IAM API を使用する Redshift の不具合により、IAM ユーザー認証情報を使用してクエリを実行することができませんでした。その結果、この期間中の IAM の障害により、Redshift はこれらのクエリを実行できませんでした。Redshift クラスターへの接続に「ローカル」ユーザーを使用していた AWS リージョンの Redshift お客様は影響を受けませんでした。
10 月 19 日午後 11 時 48 分 PDT から 10 月 20 日午前 2 時 40 分 PDT（日本時間 10 月 20 日午後 3 時 48 分から午後 6 時 40 分）にかけて、お客様は AWS サポートコンソールおよびAPIを通じてサポートケースの作成、参照、および更新ができなくなりました。サポートセンターは設計通り別のリージョンへフェイルオーバーしましたが、アカウントのメタデータを担当するサブシステムが正当なユーザーの AWS サポートセンターアクセスを妨げる応答を提供し始めました。サポートセンターは応答が失敗した場合にこのシステムをバイパスするよう設計されていますが、今回の事象ではこのサブシステムが無効な応答を返していました。この無効な応答により、正当なユーザーがサポートケース機能にアクセスできなくなる意図しないブロックが発生しました。この問題は午前2時40分 PDT（日本時間 10 月 20 日午後 6 時 40 分）に緩和され、再発防止のため追加措置を午前2時58分 PDT（日本時間 10 月 20 日午後 6 時 58 分）に実施しました。
新規 EC2 インスタンスの起動、Lambda の呼び出し、Fargate タスクの起動などの Apache Airflow 用 Managed Workflows、Outposts のライフサイクル操作などの DynamoDB に依存する他のサービスもバージニア北部 (us-east-1) リージョンで影響を受けました。影響を受けたサービスの完全なリストについては、イベント履歴を参照してください。
この運用上の事象の結果として、いくつかの変更を実施しています。すでに DynamoDB DNS プランナーと DNS エナクターの自動化を世界中で無効化しました。この自動化を再度有効にする前に、競合状態のシナリオを修正し、不適切な DNS プランの適用を防ぐための追加の保護措置を講じます。NLB については、ヘルスチェックの失敗により AZ フェイルオーバーが発生した際に、単一の NLB が除外できるキャパシティを制限する速度制御メカニズムを追加します。EC2 については、既存のスケールテストを補完する追加のテストスイートを構築し、DWFM リカバリーワークフローを実行して将来の機能低下を特定できるようにします。また、高負荷時にサービスを保護するため、待機キューのサイズに基づいて受信作業を制限する EC2 データ伝播システムのスロットリングメカニズムを改善します。最後に、すべての AWS サービスにわたってこの事象の詳細を引き続き検討し、同様の事象による影響を回避する追加の方法と、復旧時間をさらに短縮する方法を模索します。
最後に
この度の事象によりお客様にご心配やご迷惑をおかけしましたことを深くお詫び申し上げます。AWSのサービスは最高レベルの可用性で運用してきた実績があります。AWSのサービスがお客様のアプリケーション、その先のエンドユーザー、そして皆様のビジネスにとってどれほど重要であるかも認識しております。そして、今回の障害が多くのお客様に大きな影響を及ぼしたことを深く理解しています。我々は、この事象から学び、さらなる可用性の向上に活かすべく、あらゆる対策を講じてまいります。