【運用監視】AWS大規模障害（2025年10月） - j-komatsu/myCheatSheet GitHub Wiki

【運用監視】AWS大規模障害（2025年10月）

📋 概要

発生日時: 2025年10月20日（月）16:11 JST（現地時間: 2025年10月20日 0:11 PDT） 影響範囲: AWS US-EAST-1リージョン（米バージニア北部）を中心とした大規模障害 復旧完了: 2025年10月21日（火）07:00 JST（主要サービス） 影響時間: 約15時間

この障害により、グローバルで数千の企業・サービスが影響を受け、日本国内でも多くのゲーム、業務システム、ECサイト、スマートデバイスが利用不可となりました。

⏱️ 時系列（日本時間）

日時（JST） 出来事
10/20 16:11 AWS Health Dashboardで「US-EAST-1リージョンで複数サービスのエラー率上昇と遅延」を検知。EC2、Lambda、DynamoDB等で障害が連鎖開始
10/20 16:10〜16:20 国内メディア（ITmedia等）が速報。「20サービスが停止・遅延、Zoomや任天堂のサービスにも影響」と報道
10/20 16:10頃 日本国内でサービス影響が顕在化開始- 任天堂: Nintendo Switch Onlineで接続障害- Skeb: メール配信不具合を公式発表- 各種ゲーム: Fortnite、Roblox等でログイン不可
10/20 18:01 AWSが「根本原因を特定、復旧作業中」と更新
10/20 18:22〜18:35 ThousandEyesが段階的な回復の兆候を観測（ただし完全復旧ではない）
10/20 夜〜深夜 国内で業務システム・EC・アプリでアクセス遅延/ログイン不能の報告がSNSで拡大
10/20 22:40頃 任天堂が「ネットワークサービス復旧」を公式発表
10/21 06:00 ITmedia「原因特定も完全復旧に至らず」と続報
10/21 07:00 AWS「通常運用へ回復」と発表（ロイター/ブルームバーグも報道）※一部サービスでバックログ継続
10/24 AWSが謝罪と再発防止策を発表

🔍 原因

直接原因

  1. Network Load Balancer (NLB) のヘルスモニタリングサブシステム異常

    • US-EAST-1リージョン内のNLBで障害発生
    • 内部通信・トラフィック分散機構に波及

  2. 内部DNS障害

    • DynamoDB APIエンドポイント向けの内部DNS解決が失敗
    • アプリケーションが「どのサーバに接続すべきか」を判断できず

  3. 連鎖的な障害拡大

    • コントロールプレーンとデータプレーンの両方が影響
    • EC2、Lambda、CloudWatch等のコアサービスが連鎖的に停止

根本原因

  • 単一リージョン依存のリスク顕在化

    • US-EAST-1はAWS最大級のリージョンで、多くのサービスがデフォルト使用
    • マルチAZ構成でも、リージョンレベルの内部通信障害には無力

  • サイバー攻撃ではない

    • 技術的・構成上の内部不具合（AWS公式、各種報道で確認済み）

🇯🇵 日本国内への影響

1. ゲーム・エンターテインメント

サービス 影響内容 時刻
Nintendo Switch Online ネットワークサービス全般が停止 16:00頃〜22:40頃
Fortnite ログイン不可、接続不調 16:11頃〜
Roblox 接続不調 16:11頃〜
ELDEN RING NIGHTREIGN 接続不調 16:11頃〜
パルワールド ログイン不可 16:11頃〜
Skeb（クリエイター向け） メール配信停止 16:10頃〜

2. IoT・スマートデバイス

サービス 影響内容
Furbo（ペットカメラ） サーバーエラーによるログイン不可
スマートホーム機器 接続断の報告

3. 業務システム・ECサイト

  • ITmediaブログの報告: 国内のAWS上の業務システム・ECサイト・アプリでアクセス遅延やログイン不能の報告がSNS上で相次ぐ
  • 具体的な社名の公開は限定的だが、認証・通知・課金・分析などのSaaS連携が米国リージョン経由の場合、影響を受けた

4. その他サービス

  • 銀行アプリ: アクセス遅延の報告
  • 暗号資産取引所: 一部で取引停止
  • SNS: 接続不調
  • 決済サービス（Venmo等）: グローバルで影響

影響の特徴（日本視点）

✅ 就業時間内に発生

  • 16時台〜夜にかけて障害が発生したため、B2B/B2C双方で運用影響が大きかった

✅ US-EAST-1依存の間接的影響

  • 自社サーバーが東京リージョンでも、外部SaaS（認証、通知、課金等）がUS-EAST-1経由の場合、ユーザー体験が毀損

✅ 復旧後もバックログ残存

  • 復旧宣言後も再送・遅延・再起動ループ等が継続し、完全な平常化には時間差が発生

📊 影響規模

項目 詳細
影響企業数 数千社
影響サービス 20以上のAWSコアサービス
主要影響サービス EC2、Lambda、DynamoDB、CloudWatch、ELB、S3等
グローバル影響 Snapchat、Zoom、Venmo、航空会社チェックインシステム等

💡 技術的教訓

1. リージョン設計の見直し

❌ 問題

単一リージョン（US-EAST-1のみ）
  └─ リージョン全体の障害で全サービス停止

✅ 対策

マルチリージョン構成
  ├─ US-EAST-1（Primary）
  └─ US-WEST-2（Secondary/DR）

または

マルチクラウド構成
  ├─ AWS（Primary）
  └─ Azure/GCP（Secondary）

2. 依存関係の可視化

重要な気づき:

  • マルチAZ構成でも、リージョンレベルの内部通信（DNS、NLB等）障害には無力
  • コントロールプレーン（管理機能）の障害は、データプレーン（実行環境）にも波及

対策:

graph TD
    A[自社アプリケーション] --> B[認証サービス]
    A --> C[決済API]
    A --> D[通知サービス]
    B --> E{AWS US-EAST-1}
    C --> E
    D --> E

    style E fill:#f99,stroke:#333,stroke-width:4px
  • 外部SaaS/APIのリージョン依存を洗い出す
  • 単一障害点（SPOF）の特定

3. フェイルオーバー戦略

戦略 実装例
DNSフェイルオーバー Route 53で正常なリージョンへ自動切り替え
グレースフルデグレード 重要機能のみ継続、一部機能を一時停止
サーキットブレーカー 異常検知時に自動的に別経路へ切り替え

4. SLI/SLO/SLAの定義

SLI（Service Level Indicator）:
  - API可用性: 99.9%
  - レスポンスタイム: 95%ile < 200ms

SLO（Service Level Objective）:
  - 月間ダウンタイム: < 43.2分（99.9%）

SLA（Service Level Agreement）:
  - 顧客向け保証: 99.5%以上
  - 違反時の補償条件

🛡️ 再発防止策（エンジニア/PM視点）

即座に実施すべきこと

  1. 現在のアーキテクチャレビュー

    • 使用しているAWSリージョンの棚卸し
    • US-EAST-1への依存度確認
    • 外部SaaSのリージョン確認

  2. 障害シミュレーション

    • Chaos Engineering（障害注入テスト）
    • リージョン停止時の影響範囲確認
    • RTO/RPOの現実的な検証

  3. モニタリング強化

    • AWS Health Dashboard監視の自動化
    • 複数リージョンのヘルスチェック
    • 外部監視サービス（ThousandEyes等）の導入

中長期的な対策

graph LR
    A[現状分析] --> B[リスク評価]
    B --> C{対策選択}
    C -->|低コスト| D[マルチAZ強化]
    C -->|中コスト| E[マルチリージョン]
    C -->|高コスト| F[マルチクラウド]

    D --> G[継続的改善]
    E --> G
    F --> G

  1. マルチリージョン戦略

    • アクティブ/パッシブ構成
    • アクティブ/アクティブ構成（コスト高だが可用性最大）

  2. データ同期戦略

    • DynamoDB Global Tables
    • Aurora Global Database
    • S3 Cross-Region Replication

  3. BCP（事業継続計画）の整備

    • 障害時の対応フロー文書化
    • エスカレーションパス明確化
    • 顧客コミュニケーション計画

📚 参考資料

  • AWS Service Health Dashboard
  • ITmedia - AWS障害関連報道（2025年10月）
  • ThousandEyes - AWS US-EAST-1 Outage Analysis
  • 任天堂公式サポート - ネットワークサービス障害情報
  • Furboヘルプセンター - サーバーエラー告知

🔗 関連トピック

  • 【運用監視】Datadog - クラウド監視ツール
  • 【運用監視】日本国内の大規模システム障害事例集 - 過去の障害事例
  • 【クラウド】【AWS】クラウド操作チートシート（AWS編） - AWS運用のベストプラクティス
  • 【アーキテクチャ】マイクロサービスアーキテクチャ - 障害の影響範囲を限定する設計
  • 【プロジェクト管理】SRE（Site Reliability Engineering） - 信頼性エンジニアリング

📝 チェックリスト（自社システム向け）

緊急度：高

  • 現在使用しているAWSリージョンを確認
  • US-EAST-1への依存度を評価
  • 単一リージョン障害時の影響範囲を特定
  • AWS Health Dashboard監視の自動化

緊急度：中

  • マルチリージョン構成の検討・設計
  • フェイルオーバー手順の文書化
  • 障害シミュレーションの実施
  • SLI/SLO/SLAの見直し

緊急度：低（中長期）

  • マルチクラウド戦略の検討
  • Chaos Engineeringの導入
  • インシデント対応訓練の定期実施
  • BCP文書の整備・更新

📝 作成日: 2025-10-25 📝 最終更新: 2025-10-25