AWSで障害は起こる？障害情報の確認方法・発生時の対応・過去の事例

AWSでも障害は発生する

AWSを利用する際は、障害の発生そのものを完全に防ぐのではなく、発生時の影響を抑え、必要な時間内に復旧できる構成を考える必要があります。

AWSは世界各地の「リージョン」にインフラを展開しており、各リージョンは複数のアベイラビリティーゾーン（AZ）で構成されています。システムの重要度や求める可用性に応じて複数のAZを利用するなど、想定する障害範囲に合わせて構成を設計します。

障害が発生した際は、まずAWS側でどのような事象が起きているのか、自社環境が影響を受けているのかを把握します。

AWSで障害が発生しているか確認する方法

障害の有無を判断する際は、AWS Healthで公開されているイベント情報と、自社アカウントへの影響を確認します。あわせて、Amazon CloudWatchやログなどの監視データを照合し、影響範囲や原因を絞り込みます。

AWS Health Dashboardで障害情報を確認する

AWS Health Dashboardの「Service health」では、AWSアカウントにサインインしなくても、公開されているサービスイベントを参照できます。

サービスやリージョンごとの状況が表示されるため、異常を検知した時刻や利用中のリージョン、AWSサービスに該当するイベントがないかを調べます。

自社アカウント・リソースへの影響を確認する

AWSアカウントにサインインすると、自社アカウントに関連するAWS Healthイベントを確認できます。「Affected resources」が表示されるイベントでは、影響対象のリソースまで把握できます。

公開情報だけで判断せず、自社が利用するリージョンやサービス、リソースへの影響まで確認します。

AWS Healthと自社の監視情報から影響範囲を切り分ける

AWS Healthの情報だけでは、自社システムで発生している事象の原因まで特定できない場合があります。

Amazon CloudWatchのメトリクスやAmazon CloudWatch Logs、アプリケーションログなどから、エラーや性能低下が始まった時刻、影響している機能、直前の設定変更を調べます。

AWS側のイベントと自社環境の異常が発生した時刻や対象リソースを照合することで、AWSサービス側の障害なのか、自社の設定やアプリケーションなど別の要因なのかを切り分けます。

AWSで発生した主な障害事例

AWSでは、サービス、ネットワーク、データセンター設備など、異なる要因で障害が発生しています。近年の主な障害と、国内で発生した東京リージョンの事例を紹介します。

2026年7月｜CloudFront VPC Originsで発生した世界規模の障害

2026年7月16日、Amazon CloudFrontのVPC Originsを利用している環境で5xxエラーが増加する障害が発生しました。影響はVPC Originsを利用するディストリビューションに及び、その他のオリジンタイプは影響を受けませんでした。サーバーワークスの調査では、障害は約3時間33分継続しています。

国内でもPayPay、note、ニコニコ生放送、はてなブログなど、複数のサービスが同じ時間帯に利用しにくくなったと報じられました。

特定の機能や接続経路への依存は、障害時の影響範囲を広げる要因になります。重要なシステムでは、必要に応じて代替経路やフェイルオーバー方法をあらかじめ用意します。

障害の詳しい原因や、CloudFront Origin Groupを利用したフェイルオーバー構成については、サーバーワークスエンジニアブログの「CloudFront の VPC Origins を利用している環境で 5xx エラーが発生した障害について考えてみた」で解説しています。

2026年5月｜US-EAST-1の単一AZで発生した障害

2026年5月7日から8日にかけて、米国東部（US-EAST-1）リージョンの1つのアベイラビリティーゾーン（use1-az4）で、温度上昇に伴う電源喪失が発生しました。AWSによると、ハードウェアを保護するため一部のサーバーが停止し、Amazon EC2インスタンスやAmazon EBSボリュームに影響が生じました。これらに依存する一部のAWSサービスにも影響が及び、復旧対応は翌日まで続きました。詳細はAWS Health Dashboardで確認できます。

単一AZ内の障害でも、そのAZへの依存度が高いシステムではサービス継続に影響します。障害時に別のAZへ切り替えられる構成を検討する必要があります。

2025年10月｜US-EAST-1で発生した大規模障害

日本時間の2025年10月20日から21日にかけて、米国東部（US-EAST-1）リージョンで大規模な障害が発生しました。発端はAmazon DynamoDBのDNS管理システムに潜在していた不具合で、DynamoDBのエンドポイントを名前解決できなくなり、APIエラーが増加しました。

DynamoDBに依存するAWSサービスにも影響が波及し、その後、Amazon EC2の新規インスタンス起動やNetwork Load Balancer（NLB）、AWS Lambda、Amazon ECS、Amazon EKSなど、複数のサービスでエラーや遅延が発生しました。AWSは、本障害についてPost-Event Summaryを公開しています。

このような連鎖的な障害に備えるには、個々のリソースだけでなく、システムがどのAWSサービスや機能に依存しているかを把握しておく必要があります。

2021年9月｜東京リージョンで発生したネットワーク障害

2021年9月2日、東京リージョン（AP-NORTHEAST-1）でAWS Direct Connectの障害が発生しました。東京リージョンへ接続するDirect Connect利用者の一部で、断続的な接続障害やパケットロスの増加が発生し、日本時間の午前7時30分から午後1時42分まで影響が続きました。

原因は、Direct Connectロケーションから東京リージョンへ至るネットワーク経路上の一部のネットワークデバイスで発生した障害でした。一方、AZ間通信やインターネット経由のリージョンへの接続、AWS VPNなどは影響を受けていませんでした。詳細はAWS公式の「東京リージョン（AP-NORTHEAST-1）で発生したAWS Direct Connectの事象についてのサマリー」で確認できます。

Direct Connectを利用する構成では、ネットワーク経路の障害も想定し、求める可用性に応じてAWS VPNなどの代替接続手段を用意します。

AWSで障害が発生した際の対応

障害発生時は、影響範囲を把握し、あらかじめ定めた手順に沿って復旧を進めます。平常時に判断基準や担当者まで決めておくと、初動の遅れや対応のばらつきを抑えられます。

障害情報を確認し、原因と影響範囲を切り分ける

AWS Healthのイベント情報と、自社環境の監視データやログを照合します。

対象となるリージョンやAWSサービスに加え、どのリソースや機能、ユーザーに影響しているかを整理します。エラーの発生時刻、Amazon CloudWatch のメトリクス、アプリケーションログ、直前の設定変更なども判断材料になります。

AWS側の障害と自社環境の問題が同時に発生している可能性もあるため、複数の情報から原因と影響範囲を絞り込みます。

事前に定めた復旧・フェイルオーバー手順を実行する

障害の内容とシステム構成に応じて、バックアップからの復旧や冗長系への切り替え、別のアベイラビリティーゾーン（AZ）やリージョンへのフェイルオーバーなどを実施します。

フェイルオーバーは、切り替えによる影響やデータの整合性、復旧に要する時間を踏まえて判断します。「どの状態になったら切り替えるか」「誰が判断するか」まで事前に決めておくと、障害発生時にも手順に沿って対応できます。

利用者や関係部署へ状況を共有する

障害対応と並行して、利用者や社内の関係部署へ以下の情報を共有します。

• 障害の発生状況
• 影響を受けているシステムや機能
• 現在の対応状況
• 復旧見込みや次回の情報更新予定

原因を特定できていない段階では、確認済みの事実と調査中の内容を分けて伝えます。

復旧後は、発生原因や対応内容、復旧までに要した時間を振り返り、監視設定や復旧手順、システム構成の改善に反映します。

AWSの障害に備えて実施したい対策

必要な障害対策は、システムの重要度や停止時の影響、許容できる復旧時間、コストによって異なります。RTO・RPOを起点に、マルチAZ やバックアップ、必要に応じたマルチリージョン（Multi-Region）を組み合わせ、監視・通知や復旧テストまで含めて設計します。

RTO・RPOを決める

RTO（目標復旧時間）は、障害発生から復旧までに許容できる時間、RPO（目標復旧時点）は、どの時点までのデータを復旧できればよいかを示します。

数時間の停止を許容できる社内システムと、短時間の停止でも業務や顧客に大きな影響が出るサービスでは、必要な構成やコストが異なります。許容できる停止時間とデータ損失の範囲を先に定め、それに合う復旧方法を選びます。

AWS Resilience Hubでは、設定したRTO・RPOに対してアプリケーションが目標を満たせる構成になっているかを評価し、レジリエンス上の課題や改善策を確認できます。

マルチAZを活用して可用性を高める

単一のアベイラビリティーゾーン（AZ） に依存していると、そのAZの障害によってサービスを継続できなくなる可能性があります。重要なシステムでは、複数のAZにリソースを分散し、一部のAZに障害が発生しても処理を継続・復旧できる構成を検討します。

ロードバランサーによるトラフィックの切り替えや、データベースのフェイルオーバー、アプリケーションの動作まで含め、システム全体で継続できるかを見ておく必要があります。

バックアップと復旧方法を整備する

バックアップは、取得頻度や保存期間、保存先だけでなく、復旧手順まで含めて設計します。

必要な時間内にデータを復元できなければ、想定したRTO・RPOを満たせません。定期的にリストアし、バックアップデータを利用できるか、復旧にどの程度の時間がかかるかを検証します。

必要に応じてマルチリージョンを検討する

リージョン全体に影響する障害や大規模災害まで想定する場合は、マルチリージョン構成も候補になります。

一方で、リージョン間のデータ同期やフェイルオーバー、DNSの切り替え、監視などが必要になり、構成や運用の複雑さ、コストも増します。マルチAZの単純な上位構成ではなく、RTO・RPOやシステムの重要度から必要性を判断します。

監視・障害通知の仕組みを整える

Amazon CloudWatchでは、AWSリソースやアプリケーションのメトリクスを監視し、しきい値を超えた場合にアラームを発生させられます。

AWS側のイベントはAWS Healthで把握します。AWS User Notificationsでは、アカウント固有のAWS Healthイベントをメールやモバイルプッシュ通知などで受け取れます。2025年12月15日以降、AWS Healthのメール通知はAWS User NotificationsのAWS managed notificationsへ移行し、送信元も「health@aws.com」に変更されています。

一般公開されるPublic eventはAWS managed notificationsの対象ではないため、AWS Health Dashboardで参照します。より詳細なイベント情報の取得や自動連携には、AWS Health APIやAmazon EventBridgeも利用できます。

自社環境の監視とAWS側のイベント情報を組み合わせ、異常を早期に把握できる体制を整えます。

障害復旧手順を定期的にテストする

バックアップからの復元や冗長系への切り替え、関係者への連絡まで実施し、想定した時間内に復旧できるかを定期的に検証します。

障害耐性の検証には、AWS Fault Injection Service（AWS FIS）も利用できます。AWS環境に意図的に障害条件を発生させ、フェイルオーバーや監視、復旧手順が想定どおり機能するかを確認できます。アベイラビリティーゾーン（AZ）の電源断に相当する症状を再現するシナリオも用意されています。

AWS FISは実際のAWSリソースに対して操作するため、本番環境で利用する際は事前の計画と検証が必要です。テストで見つかった課題は、復旧手順や監視設定、システム構成へ反映します。

AWSパートナー活用のすすめ

AWSとオンプレミス、どちらの環境でも、障害を想定した計画と対策が不可欠です。

自社だけで障害対応を万全にすることが難しい場合は、外部のサポートを利用しましょう。障害を見据えた設計やAWSの利用状況の監視もAWSのプロに相談することができます。運用の負荷を削減し、ビジネスに集中したい場合には、パートナーの利用もご検討ください。

こうした外部パートナーによる支援は、堅牢なセキュリティ基盤を整える上でも重要です。情報漏洩などの重大なインシデントを未然に防ぐためには、日々アップデートされるセキュリティのベストプラクティスを正確に捉え、維持し続けなければいけません。そのためには高度な専門性が不可欠であり、経験豊富なAWSパートナーの支援を受けることが有効です。

AWS運用代行・監視に関する詳細はこちら

サーバーワークスの支援内容

サーバーワークスは、最上位の「AWS プレミアティア サービスパートナー」として、国内トップクラスの技術力を有し、エンタープライズ企業を中心に多数の支援実績があります。 特にセキュリティ面での信頼性に定評があり、2025年には高度なセキュリティ運用能力を証明する「AWS MSSP コンピテンシー」も取得しました。安心・安全なクラウド環境の実現に向けて、貴社のAWS活用を強力にサポートします。