📅 2025年10月20日 大規模障害分析

⚠️ AWS障害はなぜグローバルに拡大したか?

US-EAST-1リージョンの「単一障害点(SPOF)」構造を
AWS初心者にも分かりやすく徹底解説

🎯 結論ファースト:3分で分かる障害の全体像

🏢

US-EAST-1は「本社ビル」

AWSの最古参リージョン。IAMやRoute 53などグローバルサービスの「本店」として機能し、世界中が依存。

📋

DNSの「住所録」が消えた

DynamoDBのDNS管理システムで競合状態が発生。エンドポイントのIPアドレス情報が全消失した。

⛓️

連鎖的に崩壊

DynamoDB → EC2 → NLB → Lambda... 内部サービスの密結合により、ドミノ倒しのように障害が拡大。

🌍

世界中に影響

FortniteやRoblox、金融サービスまで。約14時間にわたり世界中のサービスが混乱した。

🎭 たとえ話で理解する障害のメカニズム

🏢
US-EAST-1 = 巨大企業の「本社ビル」
グローバルサービスの中枢

🏙️ US-EAST-1は、AWSという巨大企業の「本社ビル」のようなもの。

📇 社員証の発行(IAM)、全社電話帳(Route 53)、経理システム(DynamoDB)など、会社全体を動かす重要部門が集中しています。

💥 本社ビルが火事になったら、支店は仕事ができなくなりますよね?それが今回起きたこと。

📖
DNS = 「電話帳」または「住所録」
名前とIPアドレスの対応表

📞 「dynamodb.us-east-1.amazonaws.com」という名前から、実際の「IPアドレス」を調べるのがDNS。

📕 これは「田中さんの電話番号は090-XXXX-XXXXです」と書かれた電話帳のようなもの。

🚫 この電話帳のページが白紙になったら、誰にも電話できなくなります。それが今回起きたこと。

👨‍🍳
レースコンディション = 「2人のシェフ問題」
競合状態による事故

👨‍🍳 シェフAとシェフBが同じ鍋を使おうとしている状況を想像してください。

🍲 シェフA「塩を入れた!」→ シェフB「古いスープを捨てるね」→ シェフBは新しいスープも一緒に捨ててしまった!

😱 お互いの作業タイミングがズレたことで、本来残すべきものまで消えてしまう。これが「競合状態」です。

🔋
キャッシュ = 「非常用バッテリー」
一時的な猶予時間

🔌 本社ビルの電気が止まっても、各支店にはUPS(無停電電源装置)があります。

⏱️ 障害発生後も「キャッシュ」のおかげで、しばらくは動き続けました。

🪫 でもバッテリーには限りがあり、切れた瞬間に次々とサービスがダウン。約5分後から影響が顕在化しました。

📞
リトライストーム = 「全員が一斉に再コール」
自己増殖するDDoS攻撃

☎️ 電話がつながらない時、あなたは何度もかけ直しますよね?

📈 世界中の何百万ものシステムが同時に「リトライ」し始めると...

🌊 それ自体がDDoS攻撃のような状態に。復旧作業をさらに困難にしました。

🐝
アナフィラキシーショック
「ハチの一刺し」が全身麻痺に

🦟 ハチに一度刺されただけで、全身がショック状態になることがあります。

💉 DNSという「一箇所」の障害が、免疫系(=依存関係)を通じて全身(=AWS全体)に広がった。

🏥 堅牢なはずのシステムが、予期せぬ一点から崩壊する「クランブルポイント」の典型例です。

🏗️ なぜUS-EAST-1が「単一障害点」なのか

⚠️ US-EAST-1(バージニア北部)
🌍 IAM(認証の本店)
🌍 Route 53(DNSの本店)
🌍 STS(トークン発行の本店)
💥 DynamoDB(障害発生元)
📦 EC2 / Lambda / ECS...
🌏 AP-NORTHEAST-1(東京)
📦 EC2 / Lambda...
⬅️ IAM参照はUS-EAST-1へ
🌍 EU-WEST-1(アイルランド)
📦 EC2 / Lambda...
⬅️ IAM参照はUS-EAST-1へ

💥 障害の連鎖フロー

1
📋

DNS消失

DynamoDBの住所が消えた

2
🗃️

DynamoDB停止

接続不能に

3
🖥️

EC2起動失敗

リース管理がダウン

4
⚖️

NLB異常

ヘルスチェック失敗

5
🌐

グローバル影響

世界中のサービス停止

🔬 障害の技術的詳細

📋 第1幕:DNS競合状態(レースコンディション)

🏗️ システム構成

DNS Planner:DNSプラン(どのIPアドレスを使うか)を作成
DNS Enactor:3つのAZで冗長的に動作し、プランを適用

⚡ 何が起きたか?

🐢
Enactor A(遅延)

古いプランを適用中...
時間がかかって遅れた

🐇
Enactor B(高速)

新しいプランを適用完了!
古いプランを削除しよう

💥 結果:Enactor Bが「古すぎる」と判断して、Enactor Aが適用したばかりのプランを削除 → IPアドレス全消失!

🖥️ 第2幕:EC2の輻輳崩壊

🔧 DWFM(DropletWorkflow Manager)とは

EC2インスタンスを動かす物理サーバー(Droplet)を管理するシステム。各サーバーとの「リース契約」をDynamoDBで管理。

💥 何が起きたか

DynamoDB停止中にリースが大量失効。復旧後、全サーバーが一斉にリース再取得を試み、処理が追いつかず「輻輳崩壊」に。新規EC2起動が「Insufficient Capacity」エラーに。

🌐 Network Managerも連鎖

DWFM復旧後、遅延していたネットワーク設定が殺到。新規インスタンスがネットワークに接続できない状態が続いた。

⚖️ 第3幕:NLBのヘルスチェック連鎖障害

🏥 ヘルスチェックとは

「このサーバーは元気ですか?」を定期的に確認するシステム。異常があればサービスから除外する。

💥 何が起きたか

ネットワーク未完了のEC2を「正常」と誤認してサービスに投入。その後のチェックで「異常」と判定。正常↔異常を繰り返す「フラッピング」状態に。

⚡ 結果

ヘルスチェックシステム自体が過負荷に。自動フェイルオーバーが誤作動し、本来正常なキャパシティまで除外されてしまった。

⏱️ 障害タイムライン(日本時間)

10月20日 15:48
💥 DNS競合状態発生
DynamoDBのリージョンエンドポイントからIPアドレスが消失。全接続が失敗し始める。
10月20日 15:53頃
🎮 外部サービスへの影響開始
Nintendo Switchのネットワーク障害として最初に検知。キャッシュ切れと共に影響が顕在化。
10月20日 16:38
🔍 原因特定
エンジニアがDynamoDBのDNS状態が障害の原因であることを特定。
10月20日 17:15
🔧 一時緩和策
一部の内部サービスがDynamoDBに接続可能に。重要な内部ツールが復旧し始める。
10月20日 18:25
✅ DNS情報復元
すべてのDNS情報が復元。DynamoDB自体は復旧へ。
10月20日 18:25〜21:28
🖥️ EC2復旧作業
DWFMの輻輳崩壊に対応。ホストの選択的再起動などで段階的に復旧。
10月21日 01:36
⚖️ NLB緩和策
NLBの自動ヘルスチェックフェイルオーバーを一時無効化。正常なキャパシティをサービスに復帰。
10月21日 05:50
✅ EC2完全復旧
すべてのEC2 APIと新規インスタンス起動が正常に動作。
10月21日 06:20
✅ 主要サービス完全復旧
約14時間半に及ぶ障害対応が完了。ECS、EKS、Fargateも復旧。

🌍 影響を受けた主なサービス

🎮
ゲーム
Fortnite, Roblox, Pokémon GO, エルデンリング, FGO
📱
SNS
Snapchat, WhatsApp
💰
金融
Coinbase, Robinhood, Lloyds Bank
🎬
Amazon
Amazon.com, Alexa, Prime Video, Amazon Music
🎮
Nintendo
Nintendo Switch Online
📞
コミュニケーション
Zoom, Amazon Connect

📚 この障害から学ぶ教訓

🏗️

技術的負債の怖さ

US-EAST-1への依存は、AWSの初期設計から続く「技術的負債」。後発のAzureやGCPがより分散化されたアーキテクチャを採用しているのとは対照的です。

🤖

自動化の落とし穴

可用性向上のための「複雑な自動化」が、予期しない競合状態を生み、システムを破壊する「クランブルポイント」になりうる。

🔗

密結合のリスク

内部サービス間の依存関係が複雑すぎると、一箇所の障害が連鎖的に全体に波及する。疎結合の設計が重要。

🧠

組織知の重要性

The Registerは、検知から原因特定までの遅れを「シニアエンジニアの離職による組織知の喪失」が一因と指摘。暗黙知の形式知化が不可欠。

🛡️ AWSが発表した再発防止策

📋

DynamoDB DNS管理

自動化の一時停止

DNS PlannerとDNS Enactorの自動化を世界中で無効化

競合状態の修正

レースコンディションのシナリオを修正し、追加の保護措置を導入

⚖️

NLB(Network Load Balancer)

速度制御メカニズム追加

ヘルスチェック失敗時のAZフェイルオーバーで、単一NLBが除外できるキャパシティを制限

🖥️

Amazon EC2

テストスイートの強化

DWFMリカバリーワークフローを検証する追加テストを構築

スロットリング改善

待機キューサイズに基づく受信作業の制限で、高負荷時のサービス保護を強化

❓ よくある質問

なぜ東京リージョン(ap-northeast-1)を使っていても影響を受けたの?
IAM(認証)やRoute 53(DNS)などのグローバルサービスは、US-EAST-1を「ホームリージョン」として参照しています。そのため、US-EAST-1で障害が起きると、他のリージョンでもこれらのサービスが使えなくなることがあります。
「レースコンディション」って何?
複数のプロセスが同じリソースに同時にアクセスする際、実行順序によって予期しない結果が生じる状態です。今回は2つのDNS管理システムが「競争」した結果、本来消すべきでないデータを消してしまいました。
Multi-AZ構成にしていれば防げたの?
残念ながら、今回の障害はリージョン全体のコントロールプレーン(管理システム)に影響したため、同一リージョン内でのMulti-AZ構成だけでは防げませんでした。真の耐障害性にはマルチリージョン、またはマルチクラウド構成が必要です。
DynamoDBのグローバルテーブルを使っていた場合は?
他のリージョンのレプリカテーブルへの接続とリクエストは正常に行えました。ただし、US-EAST-1との間でレプリケーション遅延が発生しました。完全復旧後に同期が完了しています。
自分のサービスでできる対策は?
①マルチリージョン構成の検討 ②適切なタイムアウトとリトライ設定(エクスポネンシャルバックオフ) ③クリティカルパスからの単一リージョン依存の排除 ④障害発生時のフォールバック機能の実装 などが有効です。

📝 まとめ

2025年10月のAWS大規模障害は、クラウドの利便性の裏に潜む構造的リスクを改めて示しました。 US-EAST-1という「本社ビル」への依存、DNSの「住所録」消失、そして内部サービスの密結合による連鎖崩壊。 AWSは対策を講じていますが、私たち利用者側も、マルチリージョンやマルチクラウドといった より回復力の高いアーキテクチャの検討が重要な課題となっています。
約14時間
障害継続時間
20+
影響を受けたAWSサービス
数百万
影響を受けたユーザー

Created by SSuzuki1063

AWS SAP Learning Resources