AWSで大規模障害 ― マルチAZ構成でも防げなかった理由と今後の対策

AWSで大規模障害 ― マルチAZ構成でも防げなかった理由と今後の対策

2025年10月20日（日本時間）、Amazon Web Services（AWS）において大規模なサービス障害が発生しました。障害は主に米国東部リージョン（US-EAST-1）で発生し、世界中の多くのオンラインサービスやアプリケーションが一時的に停止しました。

本稿では、今回の障害の概要と影響範囲、マルチAZ構成を採用していても防げなかった理由、そして今後の設計指針について整理します。

障害の概要

AWS公式ステータスによれば、障害はUS-EAST-1リージョンにおける複数サービス（DynamoDB、Lambda、API Gateway、STSなど）で発生し、エラー率の急上昇およびレイテンシの増大が確認されました。

この影響により、Snapchat、Fortnite、Signal、Perplexity、Alexaなど、多数の世界的サービスが同時にダウンしました。AWSはその後「主要な根本原因を特定し、主要機能は緩和された（fully mitigated）」と発表していますが、一部では依然として遅延やキュー残りが発生していると報じられています。

マルチAZ構成でも防げなかった理由

AWSが推奨するマルチAZ構成は、高可用性を実現するための基本的な冗長化手法です。しかし今回の障害では、マルチAZ構成を採用していても影響を受けたケースが確認されました。その理由は、障害のレイヤーが「AZ内」ではなく「リージョン全体」に及んでいたためです。

制御プレーン障害が発生

今回の障害は、個別のデータセンターやハードウェア障害ではなく、AWSの制御プレーン（サービス間のAPI、認証、ルーティングなど）に影響したとみられています。

その結果、各AZの物理的な可用性は保たれていても、API呼び出しやリソース管理を行う中核部分が機能しなくなり、アプリケーションレベルでの可用性が確保できなくなりました。

マルチAZ構成の限界

マルチAZ構成は、AZ単位の停電・ネットワーク断などに対しては効果的ですが、制御プレーンや内部ネットワーク層に障害が発生した場合には対応できません。

このため、同一リージョン内の冗長化では「論理的単一障害点（Single Point of Failure）」が残るという設計上の限界が明確に浮き彫りになりました。

今後の対策と設計指針

今回の障害を踏まえると、ランニングコストと求める耐障害性のバランスをどう考えるかが構成設計の分岐点となります。冗長化を強化するほど可用性は向上しますが、運用コストや構成の複雑さも増大します。以下では、代表的な構成パターンと考慮点を整理します。

マルチAZ構成＋別リージョンでのコールドスタンバイ構成

平常時は単一リージョンで稼働させ、障害時にのみ別リージョンの環境を立ち上げる方式です。コストを抑えつつ大規模障害に備えられますが、復旧までに数時間単位のダウンタイムが発生します。

  • メリット：低コストで広域障害への備えが可能
  • デメリット：RTO（復旧時間目標）が長く、人的操作が必要

マルチAZ構成＋別リージョンでのウォーム／ホットスタンバイ構成

別リージョンにも一定のリソースを常時稼働させておき、障害時に迅速に切り替える構成です。ウォームは部分稼働、ホットは完全稼働を指します。コストと可用性のバランスを柔軟に調整できます。

  • メリット：自動フェイルオーバーが可能でRTOを短縮できる
  • デメリット：維持コスト・設計複雑度が上昇

マルチリージョン構成

複数リージョンで同時稼働させるアクティブ／アクティブ構成です。トラフィック分散や地理的冗長化に優れ、リージョン全体の障害にも耐えられますが、最も高コストかつ複雑です。

  • メリット：最高水準の可用性と応答性能を確保
  • デメリット：整合性維持とコストが大きな課題

マルチクラウド構成

AWS単独ではなく、GCPやAzureなど複数のクラウドを併用する構成です。ベンダー依存リスクを分散できますが、各クラウドのAPI差異・運用統合コストが課題になります。

  • メリット：クラウド全体の障害に対する強靭性を確保
  • デメリット：開発・運用の複雑化、スキル要求の増大

災害対策設計（DR: Disaster Recovery）の最低要件

いずれの構成を採る場合でも、最低限、別リージョンでサービスを再開できるDR設計を持つことが不可欠です。データバックアップ、DNSフェイルオーバー、クロスリージョンレプリケーションなど、迅速に代替リージョンへ切り替える仕組みを整備しておくべきです。

おわりに

今回のAWS障害は、クラウド基盤における高可用性設計の限界を改めて浮き彫りにしました。マルチAZ構成は依然として有効な手法であるものの、それだけで「クラウドは止まらない」と断言することはできません。過去にはAzureやGoogle Cloud Platform（GCP）でも大規模な障害が発生しており、大手クラウドベンダーであっても絶対的な安心・安全が保証されるわけではありません。

また、ランサムウェア被害の事例では、バックアップ自体が無事であったにもかかわらず、復旧がうまくいかなかったケースも報告されています。したがって、単にバックアップを取得するだけでなく、少なくとも年に一度はバックアップからの復旧訓練を実施し、実際に復元できることを検証することが重要です。

今回の事象は、制御プレーンやサービス間依存を含むリージョン単位の障害リスクを前提とした設計、およびバックアップ運用の実効性確保の重要性を改めて認識させるものとなりました。

参考文献

モバイルバージョンを終了