15時間のAWS大規模障害で、クラウド依存リスクが露呈。得られる教訓とは

太平洋夏時間2025年10月19日深夜（日本時間20日午後）、世界中のデジタルサービスを支えるAWSの大規模障害が発生。約15時間にもわたるこの障害は、世界中のインターネットサービスに深刻な影響を及ぼした。

AWSの公式発表によると、問題の震源地は同社最大級のリージョンである米国東部（バージニア北部、US-EAST-1）であり、その根本原因はデータベースサービス「Amazon DynamoDB」におけるDNS解決の異常にあったことが明らかにされている。

この障害は、単なる一サービスの不具合に留まらず、Snapchat、Fortniteといった人気サービスから、Slackのようなビジネスツール、さらにはPlayStation Networkに至るまで、現代社会に不可欠な多数のサービスを一時的に機能不全に陥らせた。

本記事では、クラウドインフラの心臓部で何が起きていたのかを詳細に分析し、ここから学んだ教訓を紹介する。

障害の全貌

AWS Health Dashboardに記録されたサマリーは、障害がどのように拡大し、長期化したかを物語っている。障害のプロセスは、大きく3つのフェーズに分けられる。

障害フェーズ	主要な問題	影響を受けた主要サービス
①トリガー	DynamoDBのエンドポイントに関するDNS解決異常	DynamoDB, IAM, その他US-EAST-1に依存するグローバルサービス
②依存関係による拡大	EC2のインスタンス起動用内部サブシステムの障害（DynamoDBへの依存が原因）	EC2, RDS, ECS, Glue
③復旧過程で二次障害	Network Load Balancer (NLB) のヘルスチェック機能不全	Lambda, DynamoDB, CloudWatch, その他多数のサービスでネットワーク接続問題

障害の引き金は、太平洋夏時間10月19日深夜、AWSインフラの極めて基本的な部分で引かれた。問題が発生したのは、インターネットの「住所録」に例えられるDNSだ。

アプリケーションがサービスのエンドポイントにアクセスしようとする際、DNSはその名前をコンピュータが通信に使うIPアドレスに変換する。今回、US-EAST-1リージョンのDynamoDB用エンドポイントに対する、このDNSの変換プロセスに異常が発生した。

これにより、DynamoDBにデータを読み書きしようとする膨大な数のリクエストは、宛先を見つけられずに即座に失敗。これが、AWSが報告した「大量のAPIリクエスト失敗」の正体である。

だが、問題の深刻度はここから一気に増す。認証・認可を司る最重要サービス「IAM」が、その内部でDynamoDBに依存していたためだ。DynamoDBが応答しないことでIAMは権限検証を完了できず、結果として正当なリクエストまでもが次々と拒否される事態に陥った。

さらに、IAMのようなグローバルサービスの管理機能はUS-EAST-1に集中しているため、このリージョンの機能不全が世界規模の障害へと拡大する引き金となった。

AWSがDynamoDBのDNS問題を解決した後、事態は収束に向かうかに見えた。しかし、ここで第二の障害が発生する。EC2インスタンスの起動を担う内部サブシステムが、基盤としてDynamoDBに依存していたため、連鎖的に機能不全に陥ったのだ。

これにより、EC2インスタンスの新規起動が困難になり、ECSやRDSといったEC2上で動作する多くのマネージドサービスも影響を受けた。

さらに、EC2の復旧作業を進める中で、事態をより複雑にする第三の障害が襲う。Network Load Balancer (NLB) の正常性を監視する内部サブシステムが不調をきたしたのだ。

NLBのヘルスチェックが機能しなくなった結果、Lambda、DynamoDB、CloudWatchなど、極めて広範囲なサービスでネットワーク接続の問題が発生。障害はAWSインフラの深層へと拡大していった。

AWSは、EC2インスタンスの起動を一時的にスロットリング（意図的に制限）するなど、システムの安定化を図りながら慎重に復旧作業を進め、最終的にすべてのサービスが正常運用に戻ったのは、最初の障害検知から約15時間後のことであった。

今回の件は、クラウド運用に携わる我々に、これまで以上に重い教訓を突きつけているように感じた。

1つ目の教訓は、システム全体が機能停止に陥ってしまう、致命的な依存箇所である「単一障害点」の概念を、拡張する必要があるということだ。

これまで、サーバーやストレージといった個別のコンポーネントの冗長化（マルチAZなど）に注力してきた企業は多いだろう。しかし、今回の障害は、サービス間の「依存関係」そのものが、より巨大で複雑な単一障害点になり得ることを示した。

また、利用しているサービスが内部で何に依存しているかを把握することは当然だが、AWSのアーキテクチャ上の特性、例えばIAMのようなグローバルサービスの管理機能が歴史的にUS-EAST-1に集中している、といった背景知識の必要性も痛感した。

これらを理解せずして、真の耐障害性は実現できない。

そして2つ目の教訓は、障害は「連鎖する」ことを前提とした設計の重要性だ。

あるサービスの障害が、ドミノ倒しのように他のサービスに波及する「カスケード障害」は、大規模システムにおいて常に起こりうる。

カスケード障害を防ぐための設計思想「サーキットブレーカーパターン」の実装や、クラウドプロバイダー側が復旧のために行うスロットリング（性能制限）を想定したリトライ処理など、アプリケーションレイヤーでの防御策も重要だ。

今回のAWS大規模障害は単純なDNS障害ではなく、DynamoDBからEC2、そしてNLBへと、AWS内部の複雑な依存関係を伝って連鎖した「複合障害」であった。

公式レポートが示すこの事実は、我々がクラウドの利便性の裏側にある複雑性と向き合い、より回復力の高いシステムをいかに構築すべきか、という根本的な問いを投げかけている。

AWSが後日公開するであろう詳細な事後分析報告書（Post-Event Summary）を注視し、自らのシステムの弱点を再点検したい。