Amazon Web Services (AWS)で発生し、世界中のインターネットサービスを麻痺させた大規模障害は、米国太平洋標準時(PDT)10月20日午後3時1分（日本時間10月21日午前7時1分）に全面復旧が宣言された。しかし、その裏側では、最初の問題を解決した後に次々と新たな障害が発生する「二次災害」とも呼べる深刻な事態が進行していたことが、AWS自身の報告から明らかになった。本記事では、単一のDNS障害が如何にしてドミノ倒しのようにAWSの基幹サービス群を巻き込み、24時間近くに及ぶ混乱へと発展したのか、その技術的背景と詳細なタイムラインを見てみたい。
発端は「インターネットの住所録」DNSの異常
全ては2025年10月19日午後11時49分（PDT、日本時間20日午後3時49分）、AWSで最も古く、最大規模を誇る「US-EAST-1」リージョン（米国バージニア北部）で始まった。このリージョンに設置された複数のサービスで、エラー率と遅延の急増が観測されたのだ。
AWSのエンジニアが調査を進め、翌20日の午前0時26分（PDT、日本時間20日午後4時26分）に特定した根本原因は、多くのサービスの根幹をなすデータベースサービス「DynamoDB」におけるDNSの解決問題だった。
DNS（Domain Name System）は、人間が理解しやすいドメイン名（例: google.com）を、コンピュータが通信に使うIPアドレス（例: 142.250.196.110）に変換する、いわば「インターネットの住所録」だ。この住所録に異常が生じ、各サービスがDynamoDBの正しいIPアドレスを見つけられなくなった。これが、広範囲にわたる障害の最初のトリガーとなった。
このDNSの不具合は、グローバルに影響を及ぼした。IAM（IDおよびアクセス管理）やDynamoDBグローバルテーブルといった、US-EAST-1リージョンにエンドポイントを持つグローバル機能にも障害が波及。世界中のユーザーがAWSのサポートケースを作成できなくなるなど、影響はリージョン内に留まらなかった。
復旧を阻んだ「二次障害」の連鎖
AWSは懸命な復旧作業の末、20日午前2時24分（PDT、日本時間20日午後6時24分）にDynamoDBのDNS問題を解決した。これで事態は収束に向かうかと思われた。しかし、本当の戦いはここからだった。一つの問題を解決したことで、システム全体の歪みが別の場所に噴出したのである。
第1のドミノ：EC2インスタンスが起動不能に
DynamoDBが正常化した直後、今度はAWSの最も基本的なサービスである「EC2」（Elastic Compute Cloud）で深刻な問題が発生した。EC2は、ユーザーが仮想サーバーをレンタルし、アプリケーションを稼働させるための基盤サービスだ。そのEC2のインスタンス（仮想サーバー）を新たに起動する内部サブシステムが、機能不全に陥ったのだ。
原因は皮肉にも、障害から回復したはずのDynamoDBへの「依存」にあった。EC2の内部システムが正常に動作するためにDynamoDBを必要としていたため、その復旧過程で発生した不整合がEC2の足を引っ張る形となった。多くのユーザーは必要に応じてサーバーを自動的に増減させるスケーリング機能に依存しており、新規インスタンスを起動できないという事態は、多くのサービスにとって致命的だった。
第2のドミノ：ネットワークロードバランサーが機能停止
EC2の混乱と並行して、さらなる問題が発生する。「Network Load Balancer」（NLB）のヘルスチェック機能が損なわれたのだ。
NLBは、受け取った通信を複数のサーバーに適切に振り分ける「交通整理係」の役割を担う。その際、各サーバーが正常に稼働しているかを常に監視（ヘルスチェック）している。この監視機能が停止したことで、NLBは正常なサーバーと異常なサーバーを区別できなくなり、結果としてLambda（サーバーレスコンピューティング）、CloudWatch（監視サービス）、そして皮肉にもDynamoDB自身を含む多くのサービスでネットワーク接続の問題が引き起こされた。
苦渋の決断：「スロットリング」による復旧作業
障害の連鎖を食い止め、システム全体の崩壊を防ぐため、AWSは意図的に一部のオペレーションを制限する「スロットリング」という措置に踏み切った。具体的には、EC2インスタンスの新規起動、SQS（メッセージキューサービス）の処理、Lambdaの非同期実行などが一時的に抑制された。
これは、復旧しようとするサービス群から発生する膨大なリソース要求が、弱ったシステムに殺到して共倒れになるのを防ぐための苦渋の決断だった。いわば、大事故が起きた高速道路で、さらなる玉突き事故を防ぐために流入規制を行うようなものだ。AWSは、このスロットリングを徐々に緩和しながら、ネットワーク問題の解決を並行して進めるという、極めて困難な作業を強いられた。
影響は世界規模に、生活インフラが停止
US-EAST-1リージョンの一つの障害は、瞬く間に世界中に波及した。AWSがクラウド市場の約33%を占める支配的なプレイヤーであること、そして多くのグローバル企業がこのリージョンをインフラの核として利用しているためだ。
- コンシューマーサービス: Snapchat、Robloxといった人気アプリ、Epic Gamesの「フォートナイト」などのオンラインゲームが利用不能になった。
- 金融・決済: Coinbase、Venmoといった金融プラットフォームから、英国のLloyds銀行やHalifax銀行のアプリまで、ログイン障害が発生した。
- Amazon自身のサービス: 驚くべきことに、Amazon自身のサービスも例外ではなかった。Prime Videoでバッファリングが多発し、スマートドアベルのRingがリモートアクセス不能となり、AmazonのEコマースサイトでも決済処理に失敗するケースが見られた。
- その他: 航空会社のデルタ航空、Disney+やニューヨーク・タイムズといったメディア、さらには政府機関に至るまで、幅広い分野でサービスの中断が報告された。
24時間に及んだ復旧のタイムライン
AWSの公式発表に基づき、息詰まる復旧作業の道のりを時系列で追う。時間は太平洋夏時間（PDT）と日本標準時（JST）を併記する。
- 10/19 11:49 PM PDT (日本時間 10/20 15:49): US-EAST-1でエラー率と遅延が急増。障害発生。
- 10/20 00:26 AM PDT (日本時間 10/20 16:26): 原因をDynamoDBのDNS解決問題と特定。
- 10/20 02:24 AM PDT (日本時間 10/20 18:24): DynamoDBのDNS問題を解決。しかし、直後にEC2の起動障害、NLBのヘルスチェック障害といった二次障害が発生。
- 10/20 08:43 AM PDT (日本時間 10/21 00:43): NLBのヘルスチェックを担う内部サブシステムが問題の根源であると断定。EC2の起動をスロットリング（制限）して復旧を急ぐ。
- 10/20 09:38 AM PDT (日本時間 10/21 01:38): NLBのヘルスチェック機能が回復。多くのサービスで接続性が改善し始める。
- 10/20 02:48 PM PDT (日本時間 10/21 06:48): EC2インスタンス起動のスロットリングを障害発生前のレベルに戻し、起動失敗が解消。
- 10/20 03:01 PM PDT (日本時間 10/21 07:01): 全てのAWSサービスが通常オペレーションに復帰。全面復旧を宣言。
ただし、この時点でもAWS Config、Redshift、Connectといった一部のサービスでは、障害中に溜まったメッセージの「バックログ」処理が数時間にわたって続いた。
なぜ障害は連鎖したのか？クラウドの構造的課題
今回の障害は、現代のクラウドインフラが抱える「密結合」という構造的な課題を浮き彫りにした。一つ一つのサービスは独立して動いているように見えても、その裏側では互いに複雑に依存し合っている。特に、DynamoDBやEC2のような foundational service（基礎サービス）に異常が発生すると、それに依存する無数の上位サービスが一斉に機能不全に陥るリスクをはらんでいる。
注目すべきは、障害の震源地が「US-EAST-1」だった点だ。このリージョンはAWSで最も歴史があり、規模も最大であるため、多くのグローバル機能が歴史的な経緯からこのリージョンに依存する構造になっている。一つのリージョン、特にUS-EAST-1への過度な集中が、単一障害点（Single Point of Failure）となり、世界規模の障害を引き起こすリスクを増大させているという見方もできるだろう。
今回のAWSの障害は、サービスの可用性を高めるために導入されたマイクロサービスアーキテクチャが、一方でいかに複雑な依存関係のクモの巣を作り出し、一つの糸のほつれが全体を崩壊させかねないかを改めて示す事例となった。AWSは詳細な事後分析レポートの公開を約束しているが、この連鎖的な障害の根本原因をいかに分析し、再発防止策を講じるのか。その内容は、クラウドを利用する全ての企業にとって重要な示唆を与えるはずだ。
Sources