AWSにおける大規模障害の原因と対策について

1. はじめに

「クラウドに移行すれば、インフラの悩みから解放される」ーーかつて多くのエンジニアが抱いたこの期待は、半分は真実であり、半分は幻想でした。

AWSは、業界をリードする技術と設備を持つプラットフォームですが、それでも「不沈艦」ではありません。2025年12月現在、私たちが直面している現実はシンプルです。「どんなに堅牢なクラウドであっても、障害は必ず発生する」ということです。

AWSの責任共有モデルにおいて、ハードウェアの故障はAWSの責任ですが、その上で動くサービスの「可用性（Availability）」をどう確保するかは、私たちユーザーの責任です。本コラムでは、大規模障害が発生するメカニズムを解明し、ビジネスを守るために必要な「Design for Failure（障害を前提とした設計）」の真髄について解説します。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

2. AWS大規模障害の「3つの発生源」

AWSで発生する障害は、根本原因をたどると大きく3つのパターンに分類できます。

2-1. 物理的要因

最もイメージしやすい原因です。データセンターへの電力供給停止、冷却システムの故障、あるいは台風や地震による物理的な損壊が該当します。AWSはこれらに備えて予備電源や冗長化を行っていますが、例えば「掘削工事で光ファイバーが切断された」といった物理的なアクシデントをゼロにすることは不可能です。

2-2. 論理的・ソフトウェア要因

現代のクラウド障害で最も厄介なのがこのパターンです。ハードウェアは正常に稼働しているにもかかわらず、ソフトウェアのバグ、設定ミス、リソースの枯渇などが引き金となり、システムが機能不全に陥ります。

2-3. オペレーション要因

いわゆるヒューマンエラーです。AWS内部のエンジニアによるメンテナンス時の操作ミスや、あるいはユーザー自身が誤った設定をデプロイしてしまうケースです。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

3. なぜ「大規模」に発展するのか？

単一のサーバー故障であれば、クラウドの基本機能で自動復旧できるはずです。しかし、なぜ時としてニュースになるような大規模障害へと発展するのでしょうか。

そのキーワードは「カスケード障害（連鎖的障害）」と「コントロールプレーンの停止」です。

AWSのサービスは、互いに深く依存し合っています。例えば、あるストレージサービスなどの基盤システムで障害が起きると、それに依存している認証サービスや監視サービスまでもが連鎖的にダウンします。これがカスケード障害です。

記憶に新しい2025年10月に発生したUS-EAST-1（バージニア北部）での大規模障害は、まさにこの教訓を突きつけました。 この事例では、特定の管理サービスの不具合がトリガーとなり、物理的にはサーバーが生きているにもかかわらず、依存関係にあるDNSやIAM（認証）などの広範囲なサービスに影響が波及しました。

参考：米国東部（バージニア北部、US-EAST-1）リージョンにおける Amazon DynamoDB サービス中断の概要

さらに恐ろしいのは、障害時に「コントロールプレーン（管理機能）」が停止することです。

• データプレーン： 実際にデータを処理する部分（EC2インスタンスなど）
• コントロールプレーン： 「サーバーを増やす」「設定を変更する」といった命令を受け付ける脳の部分

コントロールプレーンがダウンすると、エンジニアは「障害が起きているのに、新しいサーバーを立ち上げて逃がすこともできない」という手詰まり状態に陥ります。2025年の事例は、物理的な冗長化だけでなく、論理的な依存関係のリスクを改めて浮き彫りにしました。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

4. アーキテクチャによる「守り」の鉄則

では、私たちはどう備えるべきか。システムの重要度とコストに見合った4つのレベルで対策を定義します。

4-1. マルチAZ（アベイラビリティーゾーン）構成

前提：データセンターは壊れる

AWSの基本中の基本です。物理的に離れた複数のデータセンター群（AZ）にサーバーを分散配置します。一つのAZが停電しても、別のAZでサービスを継続できます。商用環境であれば、これは選択肢ではなく必須要件です。

AWSのリージョン（例：東京）の中には、アベイラビリティーゾーン（AZ）と呼ばれる独立したデータセンター群が複数存在します（例：ap-northeast-1a, 1c, 1d）。これらは互いに数十〜100kmほど物理的に離れており、電源も冷却設備も完全に別系統です。

つまり、「1つのAZだけにサーバーを置く」ことは、「自社ビルのサーバー室にサーバーを置く」のとリスクレベルは大差ないのです。

具体的な対策：どのレイヤーで何をすべきか？

マルチAZは、Webサーバー（ステートレス）とデータベース（ステートフル）で守り方が異なります。

1. Web/アプリサーバー層：ELB（ロードバランサー）とAuto Scalingによる「分散」

   アンチパターン（失敗例）

   • EC2インスタンスを1台手動で立ち上げ、Elastic IPを割り当てて公開している。
   • 結果： そのインスタンスがあるAZ（データセンター）で停電が起きると、復旧まで数時間〜数日間、サービスは完全に「404 Not Found」になります。EBS（ディスク）もそのAZに縛られるため、別の場所で起動し直すことも困難です。

   ベストプラクティス（成功例）

   • ELBの活用： 前段にELBを置き、背後のEC2インスタンスを必ず「2つの異なるAZ（例：AZ-1aとAZ-1c）」に最低1台ずつ配置します。
   • ヘルスチェックの自動化： ELBはサーバーの生死を監視し続けます。もしAZ-1aが全停電しても、ELBは即座にそれを検知し、全ての通信を生き残っているAZ-1c側のサーバーへ流します。ユーザーから見れば、サイトは落ちていません。

2. データベース層：マネージドサービスによる「同期レプリケーション」

   アンチパターン（失敗例）

   • EC2の中にMySQLをインストールしている、あるいはRDSを「シングルAZ」設定で作成している。
   • 結果： 障害時、バックアップからのリストアが必要になり、直近のデータ（数分〜数時間分）が失われる可能性が高く、復旧作業に専門的なDBエンジニアの手動操作が必要になります。

   ベストプラクティス（成功例）

   • RDS/Auroraの「マルチAZ」オプションを有効化： ボタン一つで有効にできます。
   • 同期レプリケーション： メインのDB（AZ-1a）に書き込まれたデータは、ミリ秒単位で予備のDB（AZ-1c）に同期的にコピーされます。
   • 自動フェイルオーバー： メインDBが応答しなくなると、AWSのシステムが自動的に予備DBをメインに昇格させます。アプリ側の接続先（DNS）も自動で切り替わるため、エンジニアが寝ている深夜に障害が起きても、数分以内に自動的に復旧プロセスが実行されます。

4-2. 疎結合アーキテクチャ

前提：システムの一部は壊れる

システム全体を密接につなぐのではなく、SQS（キュー）などを介して疎結合にします。また、エラーが起きた際に即座に切り離す「サーキットブレーカー」パターンを導入し、一部の機能不全がシステム全体のダウン（全停止）につながらないようにします。

密結合とは、「コンポーネントAが仕事を終えるために、コンポーネントBの応答を待たなければならない」状態です。これでは、Bが死んだ瞬間、Aも巻き添えで死んでしまいます。これを回避するのが「疎結合（Loosely Coupled）」です。

具体的な対策：同期から非同期へ

ここでの有効な手段は、AWSのキューイングサービスであるAmazon SQS（Simple Queue Service）を使った「非同期処理」への転換です。

1. 注文処理システムの例（Eコマース）

アンチパターン（密結合・同期処理）

• ユーザーが「購入」ボタンを押す。
• Webサーバーが「在庫システム」に在庫確認APIを投げる。
• 続けて「決済システム」に課金APIを投げる。
• 最後に「配送システム」に指示APIを投げる。
• 全て成功して初めて、ユーザーに「購入完了」画面を出す。
• 結果： もし「配送システム」が少しでも応答遅延したりダウンしたりすると、その手前の処理がすべてタイムアウトし、ユーザーは買い物ができません。 売上に直結する致命的なダウンです。

ベストプラクティス（疎結合・非同期処理）

• ユーザーが「購入」ボタンを押す。
• Webサーバーは、注文データをSQS（キュー）に入れるだけで、即座にユーザーへ「注文を受け付けました」と表示して解放する。
• バックエンドで、ワーカープログラムがSQSから注文データを取り出し、在庫引き当てや配送指示をゆっくり処理する。
• 結果： 仮に「配送システム」が全停止していても、SQSに注文データがたまる（待機する）だけで、Webサイト側の注文受付は止まりません。 障害が復旧した後に、たまった注文を順次処理すれば良いため、ビジネス機会の損失を防ぐことができます。

具体的な対策：「待たない」勇気（サーキットブレーカー）

全ての処理を非同期（SQS）にできるわけではありません。どうしてもAPIで直接データを取ってこなければならない場合（同期処理）は、「サーキットブレーカー」パターンを導入します。

2. 外部API連携やマイクロサービスの例

アンチパターン（無限待機）

• 自社システムから、連携先のAPI（または別のマイクロサービス）を呼び出す。
• 連携先が障害で応答しない。
• 自社システムはタイムアウト（例えば60秒）まで待ち続ける。
• アクセスが集中すると、全てのプロセスが「待ち状態」で埋め尽くされ、メモリやスレッドが枯渇し、自社サーバー自体がフリーズしてダウンする。

ベストプラクティス（サーキットブレーカー）

• プログラムに「ブレーカー（遮断機）」のロジックを組み込む。
• 「直近10回のアクセスのうち、5回エラーが返ってきた」などを検知したら、ブレーカーをOpen（遮断）にする。
• 遮断中は、連携先にアクセスせず、即座にエラー（またはキャッシュデータやデフォルト値）を返す。
• 結果： 連携先が死んでいても、自社システムは「待機」せずに即座に処理を終えられるため、リソースが枯渇せず、「連携機能以外は正常に動いている」状態を維持できます。

4-3. マルチリージョン戦略

前提：東京リージョン全体が止まる

大規模災害や、リージョン全体に及ぶネットワーク障害に備え、東京と大阪、あるいは海外リージョンを併用するBCP（事業継続計画）対策です。データの同期や切り替えの判断が難しくなりますが、非常に高い可用性を確保できます。

具体的な対策：2つの主要パターン

マルチリージョンには、コストとRTO（復旧目標時間）に応じて2つのパターンがあります。

1. パイロットライト/ウォームスタンバイ

多くの日本企業にとって、コストバランスが良いのがこの方式です。

• 平時の状態：
  • 東京（メイン）： 全開稼働
  • 大阪（サブ）： サーバーは最小限の数だけ起動しておくか、完全に停止（0台）させておく。ただし、データだけはリアルタイムで同期し続ける。
• 障害発生時：
  • 東京がダウンしたと判断したら、大阪側でAuto Scalingを作動させ、サーバーを一気に100台、200台と起動（スケールアウト）させる。
  • DNS（Route 53）を切り替え、ユーザーアクセスを大阪へ流す。
• メリット： 平時のEC2コストがかからない（または安い）。
• デメリット： 切り替えに数十分〜数時間のタイムラグ（サーバーが起動する時間）が発生する。

2. マルチサイト・アクティブ/アクティブ

「1秒も止めたくない」グローバルサービスや金融系システム向けです。

• 平時の状態：
  • 東京： 稼働（トラフィックの50%を処理）
  • 大阪（または米国）： 稼働（トラフィックの50%を処理）
• 障害発生時： 東京が消えた瞬間、Route 53のヘルスチェックが失敗を検知し、全トラフィックを大阪へ寄せる。
• メリット： ダウンタイムがほぼゼロ。
• デメリット： 常に2倍のインフラコストがかかる。そして後述する「データの整合性」問題が極めて難しい。

4-4. ハイブリッドクラウド・マルチクラウド戦略

前提：AWSというプラットフォーム自体が止まる

金融機関や社会インフラなど、数時間の停止も許容されないシステム向けの最終防衛ラインです。 AWSだけでなく、オンプレミス環境や他社クラウド（Microsoft Azure/Google Cloud）にもシステムを分散させます。これにより「特定のベンダーへの依存（ロックイン）」リスクを排除できます。 ただし、通信遅延、データ整合性、運用ツールの分散など、技術的難易度とコストは劇的に跳ね上がります。安易に導入するのではなく、ビジネス上のリスク許容度との厳しい天秤が必要です。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

5. 組織と運用による「攻め」の対策

アーキテクチャを組むだけでは不十分です。いざという時にその仕組みが動くよう、運用面でのアプローチが不可欠です。

5-1. IaC（Infrastructure as Code）の徹底

障害発生時の復旧作業を手動で行うのは危険です。焦りによる二次災害（オペレーションミス）を防ぐため、TerraformやCloudFormationなどでインフラをコード化し、いつでも同じ環境を自動で再現できるようにしておきます。

5-2. カオスエンジニアリング（Chaos Engineering）

「障害は起きるもの」なら、平時に自分たちで障害を起こしてテストしてしまおう、という考え方です。本番環境に近い状態で、意図的にサーバーを落としたり遅延を発生させたりして、自動復旧の仕組みが正しく機能するかを検証します。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

6. リスクとコストの天秤にかける

AWSにおける障害対策に「銀の弾丸」はありません。 マルチクラウド構成にすれば安心ですが、コストは倍増し、運用の複雑さは指数関数的に増します。逆に、コストを優先してレベル1の対策を怠れば、ビジネスの存続に関わるリスクを負うことになります。

重要なのは、「自社のサービスは、最大どれくらいのダウンタイムが許されるのか（RTO）」を定義することです。 1分も止まってはいけないのか、半日なら待てるのか。そのビジネス判断に基づき、適切なコストで適切なレジリエンス（回復力）を設計することこそが、私たちエンジニアに求められる責務なのです。

NTT東日本ではAWSの導入・移行・運用の支援を行っております。詳しくはこちらからお問い合わせください。

7. まとめ

「AWSは落ちない」という神話は、もはや過去のものです。2025年の大規模障害が私たちに改めて突きつけたのは、どれほど巨大で先進的なクラウドプラットフォームであっても、物理的・論理的な限界からは逃れられないという冷厳な事実でした。

本コラムでは、障害が発生するメカニズムと、それに対する防衛策をレベル別に提示しました。マルチAZという基本から、マルチリージョン、そして究極のマルチクラウドまで、私たちには多くの選択肢があります。

しかし、万能な「銀の弾丸」は存在しません。レベルの高い対策を追求すれば、それに比例してコストと運用の複雑性は跳ね上がります。逆に、コストを優先して対策を怠れば、ビジネスの存続に関わるリスクを抱え込むことになります。

重要なのは、技術的な完璧さを目指すことではありません。「自社のビジネスが許容できるダウンタイム（RTO）はどれくらいか」という経営的な問いに対し、最適なコストで技術的な解を実装することです。

クラウドネイティブ時代のエンジニアに求められる真の能力とは、障害を恐れることではなく、障害を前提として手懐ける「Design for Failure」の思想そのものです。「落ちないシステム」という幻想を捨て、「しなやかに回復する（Resilient）システム」を築くこと。それこそが、不確実なデジタル社会を生き抜くための大きな強みとなるはずです。

• Amazon Web Services（AWS）およびその他のAWS 商標は、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
• Microsoft Azureおよびその他のMicrosoft 商標は、Microsoft Corporationの米国及びその他の国における登録商標または商標です。
• Google Cloud および関連サービスは、Google LLC の商標です。