AWS障害はなぜグローバルに拡大したか？ US-EAST-1の「単一障害点」構造を徹底分析

はじめに：AWSを揺るがした大規模障害

2025年10月20日、多くのWebサービスやアプリケーションの基盤であるAmazon Web Services (AWS) で大規模な障害が発生しました。日本時間の夕方ごろから、SNS、ニュースサイト、ゲーム、金融サービスに至るまで、世界中のさまざまなプラットフォームで接続エラーや遅延が報告され、私たちのデジタルライフに大きな影響を及ぼしました。

本記事では、この障害がなぜ局所的な問題にとどまらず、グローバルなインシデントに発展したのかを、AWSのアーキテクチャに潜む構造的な課題、特に「単一障害点 (Single Point of Failure)」の観点から深掘りして分析します。

本記事は、障害発生時点での報道や公開情報、筆者の知見を基に構成しており、AWSの公式な見解ではありません。

障害のタイムラインと影響範囲

AWSの公式発表に基づくと、障害は以下のタイムラインで進行しました。

AWS 公式発表時間 (PDT)	日本時間 (JST)	内容の要約
Oct 20 12:11 AM PDT	Oct 20 4:11 PM JST	最初の確認: US-EAST-1で複数のAWSサービスのエラー率と遅延が増加。
Oct 20 12:51 AM PDT	Oct 20 4:51 PM JST	障害の特定開始: US-EAST-1で複数のAWSサービスのエラー率と遅延が上昇していることを確認。サポートケースの作成にも影響。
Oct 20 1:26 AM PDT	Oct 20 5:26 PM JST	DynamoDBの確認: US-EAST-1のDynamoDBエンドポイントへのリクエストで著しいエラー率を確認。他のサービスにも影響。
Oct 20 2:01 AM PDT	Oct 20 6:01 PM JST	根本原因の特定: DynamoDB APIエンドポイントのDNS解決に関連する問題が潜在的な根本原因であると特定。IAM更新などグローバルサービスへの影響を明記。
Oct 20 2:22 AM PDT	Oct 20 6:22 PM JST	緩和の開始: 初期緩和策を適用し、一部のサービスで回復の兆候。リトライ推奨。
Oct 20 2:27 AM PDT	Oct 20 6:27 PM JST	回復の兆候: 大幅な回復の兆候が見られ、ほとんどのリクエストが成功し始めている。
Oct 20 3:03 AM PDT	Oct 20 7:03 PM JST	広範な回復: 影響を受けた大半のサービスで回復を観測。US-EAST-1に依存するグローバル機能も回復を確認。
Oct 20 3:35 AM PDT	Oct 20 7:35 PM JST	DNS問題の緩和: 基盤となるDNSの問題は完全に緩和されたと報告。しかし、新規EC2インスタンスの起動（およびECSなどの依存サービス）でエラーが残存。
Oct 20 4:48 AM PDT	Oct 20 8:48 PM JST	EC2/Lambdaの問題継続: 新規EC2起動エラーの完全復旧に引き続き取り組み。SQS Event Source Mappingsを用いたLambdaのポーリング遅延も継続。
Oct 20 6:42 AM PDT	Oct 20 10:42 PM JST	回復作業継続: US-EAST-1の複数のアベイラビリティゾーンで緩和策を適用。新規EC2起動の復旧のため起動レートを制限。

キャッシュが隠した障害の連鎖と二次災害

タイムラインを見ると、障害の検知から根本原因の特定まで約2時間かかっていますが、多くのユーザーが実際に影響を感じ始めたのはさらに後でした。これは、CDN（コンテンツデリバリーネットワーク）によるコンテンツ配信や、各サービスが持つ認証情報のキャッシュなど、さまざまなレイヤーのキャッシュ機構が、一時的に障害の影響を覆い隠していたためです。

しかし、これらのキャッシュの有効期限（TTL）が切れると、サービスはAWSのバックエンドに再度アクセスを試みます。その結果、根本原因であるDNS解決の異常に突き当たり、次々とサービスが機能不全に陥っていきました。「エルデンリング」や「FGO」といった大規模オンラインゲームが、他のサービスより遅れてダウンし始めたのは、まさにこの時間差攻撃によるものだと考えられます。

さらに、事態を悪化させたのが「リトライストーム」です。キャッシュが切れてエラーを吐き始めても、クライアントやサーバーはすぐには諦めず、機械的にリクエストを再試行します。この無数のリトライが嵐のように押し寄せ、AWSのネットワークバックボーンや、復旧しかけていたサービスに対して、自己増殖的なDDoS攻撃のような状態を生み出します。この二次災害が、AWS側の復旧作業をさらに困難にし、障害の長期化を招いた一因とも言えるでしょう。

このリトライストームの凄まじさは、障害発生時に観測された興味深い現象からも伺えます。当時、リアルタイム障害検知サイト「Downdetector」では、AWSと直接関係ないはずのGoogle CloudやMicrosoft Azureの障害ゲージまでもが上昇していました。もちろん、両社から公式な障害報告はありません。これは、AWSを原因とする接続エラーに遭遇したユーザーが、原因を切り分けられずに「Googleが落ちた」「Azureに繋がらない」とSNSに投稿し、それをDowndetectorが検知した結果と考えられます。リトライストームがインターネット全体に与える負荷を考慮すれば、実際にこれらのサービスへの接続が不安定になった可能性も否定できず、障害の混乱が広範囲に及んでいたことを示す好例と言えます。

広範囲に及んだ影響

最終的に、影響は以下のような主要サービスにまで及び、世界中のデジタルインフラが不安定な状態に陥りました。

• SNS: Snapchat, WhatsApp
• ゲーム: Fortnite, Roblox, Pokémon GO
• 金融: Bank of Scotland, Halifax, Lloyds Bank, Coinbase, Robinhood
• Amazon関連: Amazon.com, Alexa, Prime Video, Amazon Music

原因分析：US-EAST-1とDynamoDBの「単一障害点」

AWSのステータスページや複数の報道によると、障害の根本原因は US-EAST-1（バージニア北部）リージョンにおけるDNSの解決異常 にあり、特にキーバリューストアであるAmazon DynamoDBが深く関与していることが示唆されています。

グローバルサービスのホームリージョン

US-EAST-1は、AWSの歴史の中で最も古く、最大級のリージョンです。問題は、多くのグローバルコントロールプレーンサービスがこのリージョンを「ホームリージョン」としている点にあります。

例えば、ユーザー認証を管理するIAM (Identity and Access Management) や、DNSサービスであるRoute 53などのコア機能は、最終的な設定情報の参照先や更新の起点がUS-EAST-1に集中しています。つまり、このリージョンで発生した障害が、他のリージョンで稼働するサービスにも連鎖的に影響を及ぼすアーキテクチャになっているのです。

今回の障害では、US-EAST-1のDynamoDBエンドポイントへのDNS解決が失敗したことで、DynamoDBに依存する多数のAWSサービス（Lambda, API Gateway, ECSなど）が連鎖的に機能不全に陥りました。そして、これらのサービスに依存するグローバルなアプリケーションが、世界中で利用できなくなるという事態を招いたのです。

技術的負債としてのアーキテクチャ

このような構造は、AWSがサービスを開始した初期の設計思想に起因します。後発のMicrosoft AzureやGoogle Cloud Platform（GCP）が、より分散化されたアーキテクチャを採用しているのとは対照的です。

AWSにとって、このUS-EAST-1への依存構造は、膨大な数の既存サービスとの互換性を維持しつつ、大規模なアーキテクチャ変更を行うことの困難さを示す、一種の 「技術的負債」 と言えるでしょう。

公式発表と現状

障害発生後、AWSは迅速に原因究明にあたり、「根本的な問題は完全に緩和された」と発表しました。多くのサービスは正常に稼働を再開しましたが、一部ではリクエストの遅延（スロットリング）が残り、完全復旧に向けた作業が続けられました。

まとめ：クラウドの脆弱性と今後の課題

今回のAWS大規模障害は、クラウドアーキテクチャの利便性の裏に潜む脆弱性を白日の下に晒しました。US-EAST-1でのDNS解決異常という「ハチの一刺し」が、グローバルコントロールプレーンへの依存という構造的な急所に作用し、まるでアナフィラキシーショックのように広範なサービスを機能不全に陥らせたのです。

このインシデントは、クラウドプロバイダーごとに抱えるリスクの性質が異なることも示唆しています。AWSの障害が「地理的な集中」という技術的負債に起因する一方、Azureのような後発クラウドでは、過去にグローバル認証システムのバグといった「論理的な集中」が大規模障害を招いています。

私たち利用者側も、こうしたインシデントを教訓に、マルチリージョンやマルチクラウドといった、より回復力の高いアーキテクチャの検討が、今後のサービス継続性を担保する上で重要な課題となるでしょう。そしてAWS自身も、この技術的負債とどう向き合い、将来のアーキテクチャをどう進化させていくのか、その動向が注目されます。