2025年10月20日のAWS障害を検証：原因・影響・復旧時系列と再発防止策

2025年10月20日15時48分（日本時間）、AWSの米国東部（バージニア北部）リージョンで大規模なサービス障害が始まりました。

最初のDynamoDB障害は約3時間で収束しましたが、EC2とNetwork Load Balancer（NLB）への連鎖を含む事象全体は、翌21日6時20分まで続きました。

この記事では、発生直後の推測ではなく、後日公開されたAWSの公式事後報告を基準に、原因、影響、復旧の流れを整理します。

後半では、単に「マルチリージョンにすればよい」と結論づけず、止められない業務と許容できる停止時間から対策を選ぶ方法を説明します。

最初に押さえる4つの結論

• 障害の起点は、US-EAST-1にあるAmazon DynamoDBのリージョナルエンドポイントを管理するDNS自動化システムでした。
• DynamoDBの復旧後も、同サービスに依存していたEC2の内部処理と、遅れて反映されたネットワーク情報の影響が残り、NLBなどへ障害が連鎖しました。
• 同一リージョン内のマルチAZ構成はAZ単位の障害に備える方法であり、リージョン内の共有サービスへの依存まで解消するものではありません。
• 対策は製品名から決めず、業務ごとのRTOとRPOを定め、バックアップ、マルチAZ、待機系リージョン、複数リージョンでの同時稼働を段階的に選びます。

障害の時系列を日本時間で確認する

リージョンとは、AWSがサービスを提供する地理的な単位です。

一つのリージョンには、物理的に分離された複数のアベイラビリティーゾーン（AZ）があります。

今回の起点はUS-EAST-1でしたが、このリージョンのエンドポイントやサービスに依存する機能を通じて、利用者が世界各地で影響を受けました。

元の速報段階では「3時間から4時間の障害」と捉えられていました。

これはDynamoDBの主要なDNS障害や、一部の外部サービスが回復した時間帯には当てはまりますが、AWS内部の連鎖と復旧作業を含む全体の長さではありません。

根本原因はDynamoDBのDNS管理にあった

DNSは、サービス名を接続先のIPアドレスへ変換する仕組みです。

DynamoDBのように大規模なサービスでは、多数の接続先を安全に入れ替えるため、DNSレコードの更新を自動化しています。

AWSの事後報告によると、今回の直接原因は、このDNS管理システムに潜んでいた競合状態（レースコンディション）でした。

競合状態とは、複数の処理がほぼ同時に動いたとき、実行順序によって想定外の結果になる不具合です。

二つの更新処理が古い計画と新しい計画を前後して適用し、古い計画の削除に伴ってDynamoDBのリージョナルエンドポイントからIPアドレスが消えました。

自動処理では状態を修復できず、AWSの担当者による手動対応が必要になりました。

EC2への連鎖

DNSを直せば、すべてが同時に回復するわけではありませんでした。

EC2で物理ホストの状態を管理する内部処理がDynamoDBに依存しており、障害中に管理用のリースが次々と期限切れになったためです。

DynamoDBの復旧後、一斉にリースを再確立しようとした処理が混雑し、新しいEC2インスタンスを起動できない状態が続きました。

ここで区別したいのは、既存のEC2インスタンスが停止したのではなく、主に新規起動と関連する操作が影響を受けた点です。

NLBへの連鎖

EC2の復旧過程では、滞留していたネットワーク設定の反映にも遅れが生じました。

NLBのヘルスチェックは、ネットワーク設定がまだ届いていない新規インスタンスを異常と判定し、利用可能な接続先から外しました。

判定が正常と異常の間で揺れた結果、ヘルスチェック処理自体の負荷が増え、一部のNLBで接続エラーが発生しました。

一つの不具合だけで全期間を説明するのではなく、DynamoDBのDNS障害、EC2内部処理の混雑、NLBヘルスチェックの不安定化という三つの段階に分けると、復旧が長引いた理由を理解できます。

どこまで影響したのか

AWSサービスへの影響

AWSは、DynamoDB、EC2、NLBに加え、Lambda、ECS、EKS、Fargate、Amazon Connect、STS、Redshift、AWS Supportなどでエラーや遅延が生じたと報告しています。

IAMユーザーによる管理コンソールへのサインインにも失敗が増えました。

リージョン内で稼働している機能だけでなく、US-EAST-1のエンドポイントに依存する一部のグローバル機能にも影響が及びました。

利用者が使うサービスへの影響

当時のThe Vergeの報道やThe Guardianの報道では、AmazonとAlexaのほか、Snapchat、Fortnite、Roblox、Signal、Canvaなど、多数のサービスで利用障害が確認されました。

ただし、障害報告サイトへの投稿は利用者が異常を知る手掛かりであり、それだけで原因まで証明するものではありません。

自社の障害対応でも、外部の報告、クラウド事業者の公式情報、自社の監視結果を分けて記録する必要があります。

マルチAZだけでは防げなかった理由

マルチAZは、同一リージョン内の複数AZへシステムを分散する構成です。

単一のデータセンターやAZで起きる障害への耐性は高められますが、同じリージョンのサービスエンドポイントや制御機能に共通して依存している場合、その依存関係は残ります。

今回のDynamoDB DNS管理システムは三つのAZで冗長化されていました。

それでも、複数の処理が共有する更新手順に潜んだ不具合によって、リージョナルエンドポイントが利用できなくなりました。

「複数AZに置けば、リージョン内のあらゆる障害を回避できる」という理解は正確ではありません。

RTOとRPOから復旧方式を選ぶ

対策の出発点は、利用するAWS製品の一覧ではなく、業務が許容できる停止とデータ損失の範囲です。

• RTO（目標復旧時間）：停止してから、業務を再開するまでに許容できる時間です。
• RPO（目標復旧時点）：復旧時に、どの時点までのデータを戻せればよいかを表します。

たとえば、商品閲覧は短時間なら縮退表示を許せても、注文確定と決済では重複処理やデータ欠落を避ける設計が必要です。

同じシステムでも、機能ごとにRTOとRPOを分けると、すべてを最高コストの構成にする必要がなくなります。

AWS Well-Architected Frameworkも、バックアップと復元、パイロットライト、ウォームスタンバイ、複数サイトの同時稼働を、復旧目標に応じて選ぶ考え方を示しています。

再発時に止めないための設計

依存関係をリージョン単位で洗い出す

アプリケーション、データベース、認証、シークレット、監視、通知、CI/CD、問い合わせ窓口まで、障害時に必要な機能を一覧にします。

別リージョンにアプリケーションだけを用意しても、認証や設定取得が元のリージョンに残っていれば切り替えられません。

待機先を独立して起動できる状態にする

Infrastructure as Codeでネットワーク、計算資源、権限、設定を再現し、待機先リージョンのクォータと接続先も確認します。

構成ファイルを保管しているだけでは復旧できません。

実際に起動し、依存サービスへ接続し、想定トラフィックを処理できるところまで試験します。

切替手段を障害対象から分離する

DNSやルーティングの変更手順は、管理画面だけに依存させないことが大切です。

AWSは、災害復旧時の切替にRoute 53のヘルスチェックとApplication Recovery Controllerのルーティング制御など、データプレーンを利用する方法を案内しています。

Route 53によるDNSとトラフィック制御を設計するときは、切替操作、権限、TTL、フェイルバックまで一つの手順として確認します。

データ複製と書き込み競合を一緒に設計する

DynamoDB Global Tables、Aurora Global Database、S3のクロスリージョンレプリケーションは、データを別リージョンへ配置する選択肢です。

ただし、複製があることと、アプリケーションが安全に切り替わることは同じではありません。

今回も、DynamoDB Global Tablesの他リージョンのレプリカには接続できた一方、US-EAST-1との間では複製遅延が発生しました。

アプリケーション側には、正常なリージョンへ通信を向ける仕組みと、同じデータが複数リージョンで更新された場合の扱いが必要です。

リトライを冪等にする

冪等性とは、同じ要求を複数回実行しても、意図した結果が一度分だけ反映される性質です。

障害時にはタイムアウト後の再送が増えるため、注文、決済、在庫更新などに一意の処理IDを持たせます。

指数バックオフやキューは一時的な混雑を和らげますが、無制限の再試行は復旧中のサービスへ負荷を戻します。

バックアップとフェイルオーバーを分けて試す

バックアップ設計と復旧運用は、データを戻すための備えです。

フェイルオーバー試験では、別系統へ切り替えて業務を続けられるかを確認します。

両方を実施し、実測した復旧時間とデータ差分をRTO、RPOと比較します。

障害当日の対応手順

1. 検知と変更停止：利用者視点の外形監視で異常を確認し、原因が不明なままのデプロイや設定変更を止めます。
2. 影響範囲の分離：新規処理、既存セッション、読み取り、書き込み、地域別の状態を分けて確認します。
3. 公式情報との照合：AWS Health Dashboardと自社のメトリクスを照合し、外部報告は補助情報として扱います。
4. 切替判断：事前に定めた条件を満たした場合だけ、待機リージョンへの切替や縮退運転を実行します。
5. 利用者への告知：確認済みの影響、回避策、次回更新時刻を伝えます。原因やデータ消失の有無は、確認前に断定しません。
6. 復旧後の確認：滞留したキュー、重複処理、決済、通知、監査ログを確認してから通常運転へ戻します。

一次告知の例：現在、一部機能でエラー率の上昇を確認しています。影響範囲を調査しており、確認できた情報をこのページで更新します。次回は○時○分までに状況をお知らせします。

この文面には、未確認の原因や「データ消失はない」といった断定を入れていません。

技術対応と顧客対応を分担し、更新時刻を守るほうが、推測を急いで発信するよりも信頼を保ちやすくなります。

見直しに使えるチェックリスト

• 止められない業務と、縮退できる機能を分けたか
• 機能ごとにRTOとRPOを定めたか
• 認証、DNS、監視、通知を含む依存関係をリージョン単位で把握したか
• 待機先リージョンを実際に起動し、接続と性能を確認したか
• 切替条件、実行権限、連絡先、フェイルバック手順を文書化したか
• 書き込み競合、重複実行、複製遅延への対応を決めたか
• バックアップからの復元時間と、フェイルオーバー時間を別々に計測したか
• 利用者向け告知に、確認済み情報と次回更新時刻を含めたか

この障害から得られる実務上の教訓

今回の障害は、単一リージョンの危険性だけを示した事例ではありません。

複数AZで冗長化された仕組みでも、共有する自動化処理に不具合があれば、広い範囲へ影響が及びます。

一方で、マルチリージョンやマルチクラウドは、導入しただけで可用性を保証する仕組みでもありません。

復旧目標、独立した待機系、データ整合、切替手順、利用者への告知を一続きの運用として試すことで、構成図上の冗長性を実際の復旧能力へ変えられます。

参考資料

• AWS：Amazon DynamoDB Service Disruption in the Northern Virginia Regionの事後報告
• About Amazon Japan：AWSサービス障害の更新
• AWS Well-Architected Framework：復旧目標に応じた災害復旧戦略
• AWS：Amazon Route 53 DNSのベストプラクティス
• AWS：DynamoDB Global Tablesの設計指針
• The Verge：外部サービスへの影響と復旧報道
• The Guardian：世界各地のサービスへの影響報道