AWS上で動かしているサイトやサービスが突然つながらなくなったとき、まず知りたいのは「自分の設定やアプリの問題なのか、AWS側の障害なのか」です。先に確認する場所を決めておけば、あわてて設定を変えずに原因を切り分けやすくなります。
ここでは、AWSで障害が疑われるときの確認方法、障害時の注意点、再発に備える考え方を初心者向けに解説します。公開されている障害情報と、ログイン後に見られる自分のアカウント向け情報は範囲が異なるため、両方を使い分けることが大切です。
まず確認：AWS Health Dashboardを見る
AWS全体で公表されている障害情報は、AWS Health Dashboard の「Service health」で確認します。ログインやAWSアカウントは不要で、AWS Health Dashboard – Service healthを開けば利用できます。この画面には公開イベントだけが表示され、サービス名、影響を受けるリージョン、重大度、更新履歴などを確認できます。（出典：AWS公式ドキュメント「AWS Health Dashboard – Service health」）
画面上部のService healthからOpen and recent issuesを開き、自分が使っているサービスとリージョンを確認しましょう。たとえば東京リージョンは ap-northeast-1 です。表示されたイベントの詳細では、どのリージョン・サービスに影響があるのか、状態がImpactedなのかDegradedなのか、更新がいつ行われたのかを確認します。（出典：AWS公式ドキュメント「AWS Health Dashboard – Service health」）
| 確認する場所 | ログイン | わかること | 主な用途 |
|---|---|---|---|
| Service health | 不要 | 公開されたサービス・リージョン単位のイベント | AWS全体で同様の障害が起きているかを最初に確かめる |
| Your account health | 必要 | 自分のアカウントやリソースに影響するイベント、予定変更、通知 | 自分のEC2、RDSなどが実際に影響対象かを確認する |
| 自分の監視・ログ | 構成による | アプリケーション、ネットワーク、CPU、エラーなどの実測値 | 公開・アカウント情報に出ていない問題も含めて切り分ける |
なお、Service healthに表示がないことだけを理由に、AWS側の要因を完全に除外することはできません。ここは公開イベントだけを示すページであり、アカウント固有の事象はログイン後の画面で確認する必要があります。公開情報、アカウント固有情報、自分の監視結果を合わせて判断しましょう。（出典：AWS公式ドキュメント「AWS Health Dashboard – Service health」）
ログインできる場合：Your account healthを見る
AWSアカウントにログインできる場合は、AWS Health DashboardのYour account healthを確認します。以前の「Personal Health Dashboard」という呼び方ではなく、現在はAWS Health Dashboard内のこの画面で、アカウントやAWS Organizationsに関係するイベントを見ます。公開ステータスページにログインした状態で開くと、アカウントのヘルス画面へ移動します。（出典：AWS公式ドキュメント「Getting started with your AWS Health Dashboard」）
ナビゲーションのYour account healthには、次の確認項目があります。障害時はまずOpen and recent issuesを開き、イベントを選んで詳細とAffected resourcesを確認しましょう。ここで影響を受けるリソースIDやARNが表示されれば、自分のアカウントに関係するイベントであることを具体的に確認できます。（出典：AWS公式ドキュメント「Viewing your account events in the AWS Health Dashboard」）
- Open and recent issues：過去7日間の継続中・最近の問題を確認します。
- Scheduled changes：予定されているメンテナンスや、対応が必要になるライフサイクル関連の変更を確認します。
- Other notifications：証明書ローテーション、請求、セキュリティ上の脆弱性など、その他の通知を確認します。
- Event log：過去90日間のイベントを、リージョン、サービス、状態、開始時刻などで絞り込んで確認します。
イベントの詳細では、サービス名、状態、リージョンまたはAZ、開始・終了時刻、更新の時系列、影響リソース数などを確認できます。予定されたライフサイクルイベントの影響リソースの状態は、通常24時間ごとに更新され、反映まで最大72時間かかることがあります。画面の更新時刻も確認してください。（出典：AWS公式ドキュメント「Viewing your account events in the AWS Health Dashboard」）
切り分け：自分側の問題かAWS側かを判断する
公式画面にイベントが見つかった場合でも、必ずしも自分のサービス全体が停止しているとは限りません。サービス名・リージョン・影響リソース・発生時刻を自分の構成と照合してください。逆に、公開イベントが見つからなくても、アプリケーション設定、DNS、CDN、ネットワーク、認証、証明書、外部連携先など、AWS以外も含めた原因の確認が必要です。
| 状況 | まず確認すること | 判断の目安 |
|---|---|---|
| Service healthに同じサービス・リージョンのイベントがある | 重大度、更新履歴、影響範囲を読む | AWS側の広域・公開障害の可能性が高い |
| Your account healthにイベントと影響リソースがある | 対象リソースID、対応期限、AWSからの案内を確認する | 自分のアカウントに影響するAWSイベントである可能性が高い |
| Health Dashboardに該当情報がない | 自分の監視、ログ、直前の変更、ネットワーク経路を確認する | 自分側または未公表・限定的な事象も含め、追加調査が必要 |
EC2に接続できない、またはEC2上のサイトだけが表示できないときは、EC2コンソールのInstancesで対象インスタンスを選び、Instance stateが running か、Status checkがすべて正常かを確認します。さらにSecurityタブのInbound rulesで必要な通信を許可しているかを見ます。SSHなら通常は22番ポート、Web公開なら通常は80番または443番ポートを使いますが、公開元は必要最小限の範囲に絞ることが重要です。（出典：AWS公式ドキュメント「Troubleshoot issues connecting to your Amazon EC2 Linux instance」）
EC2のステータスチェックには、AWS基盤側を見るSystem、OSやネットワーク設定を見るInstance、接続したEBSを見るAttached EBS、HTTP/HTTPS応答を監視する任意設定のApplication、GPUなどを使う一部のインスタンスで実行されるPerformanceがあります。System、Instance、Attached EBSはすべてのインスタンスで自動実行されますが、Applicationは自分で関連付けて設定する必要があります。状態だけで原因を断定せず、アプリケーションログや監視結果も確認しましょう。（出典：AWS公式ドキュメント「Status checks for Amazon EC2 instances」）
接続不良では、セキュリティグループだけでなく、サブネットのルートテーブル、ネットワークACL、インターネットゲートウェイ、パブリックIPv4アドレスまたはElastic IP、インスタンスのCPU負荷も確認対象です。ディスク容量不足、アプリケーションの停止、証明書期限切れ、DNS設定の誤りも、Health Dashboardには表示されない代表的な原因です。（出典：AWS公式ドキュメント「Troubleshoot issues connecting to your Amazon EC2 Linux instance」）
アカウントが停止している旨の通知がある場合は、請求・アカウントの問題も確認します。未払いで停止されたケースでは、Billing and Cost ManagementコンソールのPaymentsにあるPayments Dueで未払い請求を確認・決済します。決済方法によっては再有効化まで時間がかかることがあるため、急いでリソース設定を変更する前に、AWSから届いたメールとアカウント状態を確認してください。（出典：AWS re:Post「How do I reactivate my suspended AWS account?」）
他のツールでも障害を確認する
AWS公式のHealth Dashboardに加え、自分で用意した外形監視、CloudWatchのメトリクスやログ、ロードバランサーのヘルスチェック、DNSの応答などを確認すると、影響範囲を絞り込みやすくなります。監視地点を複数のネットワークやリージョンに分けておくと、特定の回線や監視サーバーだけの問題も見分けやすくなります。
XなどのSNSや外部の障害情報サイトで同じサービス・同じリージョンに関する報告を探すことは、異常に早く気づくための補助になります。ただし、投稿数や推測だけでは原因を確定できません。公式のイベント詳細、自分の監視データ、ログと照らし合わせ、SNS情報は一次情報の代わりではなく参考情報として扱いましょう。
障害が確認できたときにやるべきこと
AWS側のイベントが確認できたら、まずイベント詳細で影響範囲、対象リージョン、更新時刻、影響リソース、AWSから求められている対応を確認します。自社の監視で障害開始時刻、エラー内容、影響を受けた機能を記録しておくと、復旧後の確認や利用者への説明に役立ちます。（出典：AWS公式ドキュメント「Viewing your account events in the AWS Health Dashboard」）
- 無計画に設定を変えない：原因が確定する前に、セキュリティグループ、ルート、DNS、データベース設定を次々と変更すると、復旧後の不整合や二次障害につながります。変更が必要なら、承認済みの障害対応手順に従い、時刻と内容を残して実施します。
- 影響範囲を確認する：サイト全体か、一部の機能か、特定リージョン・特定リソースだけかを確認します。利用者に見えるエラーと、管理画面・監視画面の状態が一致するかも確認しましょう。
- 復旧情報を追う：Health Dashboardのイベント更新を確認し、復旧表示だけで終わらせず、自分の監視、ログイン、重要な処理で正常性を確かめます。
- 利用者へ事実ベースで告知する：サービス提供者は、判明している影響範囲、暖定対応、次回の案内予定を知らせます。原因を推測で断定せず、復旧後に実測結果を確認してから完了を案内します。
特にデータの更新処理や決済処理があるサービスでは、障害中に同じ処理を繰り返し実行すると、重複登録や不整合が起きることがあります。再実行やフェイルオーバーは、アプリケーション固有の復旧手順、データ整合性の確認、責任者による判断を前提に行いましょう。
再発に備える対策
障害を早く知るために、AWS Healthの通知を設定しておくと便利です。現在は、AWSマネジメントコンソールのUser NotificationsからAWS managed notifications subscriptionsを開き、AWS Healthイベントのカテゴリごとに通知を管理します。メール、チャット、AWS Console Mobile Applicationへのプッシュ通知を利用できますが、公開サービスイベントはこの管理通知の対象外です。公開イベントも受け取りたい場合は、Amazon EventBridgeのルールか、User Notificationsで自分で設定する通知（ユーザー設定通知）を使います。なお、AWS Healthのメール通知は2025年12月15日からAWS managed notificationsに移行し、送信元が「health@aws.com」に変わりました。メールの振り分けルールを作っている場合は見直しましょう。（出典：AWS公式ドキュメント「Manage AWS Health notifications in AWS User Notifications」）
より詳細な通知や運用自動化が必要な場合は、AWS HealthイベントをAmazon EventBridgeで受け、Amazon SNS、Amazon SQS、AWS Lambdaなどへつなぐ方法があります。EventBridgeは少なくとも1回の配信を行うため、同じイベントが複数回届く可能性を前提に、通知や自動処理を重複しても安全に実行できるよう設計してください。公開イベントは、ルール作成後に配信開始まで最大1時間かかることがあります。（出典：AWS公式ドキュメント「Monitoring events in AWS Health with Amazon EventBridge」）
また、Health Dashboardの確認だけに頼らず、利用者の画面に近い外形監視、アプリケーションのエラー監視、リソース監視、バックアップの成否監視を組み合わせましょう。通知先、担当者、確認手順、利用者への連絡手順をあらかじめ決めておくと、初動を速くできます。
障害と自分側トラブルの見分け方
「AWSの障害か、自分の設定ミスか」を素早く見分けるには、同じ時刻にどのサービス・リージョン・リソースで何が起きているかを比較します。Service healthに該当イベントがあり、Your account healthにも影響リソースが表示され、自分の監視でも同時刻に異常があるなら、AWSイベントとの関係を強く疑えます。（出典：AWS公式ドキュメント「AWS Health Dashboard – Service health」）
一方で、異常が自分のアプリケーションだけに限られ、直前にデプロイ、DNS変更、証明書更新、セキュリティグループ変更などを行っている場合は、まずその変更を確認します。ただし「自分だけに見える」ことと「AWS側ではない」ことは同じではありません。アカウント固有イベントは公開ページに表示されないため、必ずYour account healthの影響リソースも確認してください。（出典：AWS公式ドキュメント「Viewing your account events in the AWS Health Dashboard」）
障害に強い構成にするには
可用性が必要な本番システムでは、単一のAZに依存しないことが基本です。AWSは、同一リージョン内の少なくとも2つのAZへワークロードを分散し、ロードバランサーで正常なAZへ通信を振り分ける構成を推奨しています。EC2だけでなく、データ層もサービスごとの仕様を確認し、必要であればマルチAZレプリケーションやフェイルオーバーを有効にします。（出典：AWS Well-Architected Framework「Deploy the workload to multiple locations」）
ただし、マルチAZにしただけでリージョン全体の障害、設定ミス、データ破損、誤削除まで防げるわけではありません。停止許容時間と許容できるデータ損失を決めたうえで、バックアップと復元、パイロットライト、ウォームスタンバイ、複数リージョンのアクティブ・アクティブなどから、必要な復旧戦略を選びます。複数リージョンは可用性を高められる一方、データ複製、切替、運用、費用が増えるため、小規模なサービスで常に必要とは限りません。（出典：AWS Well-Architected Framework「Use defined recovery strategies to meet the recovery objectives」）
バックアップを取得しているだけでは、必要なときに復旧できるとは限りません。データだけでなく、インフラ設定とアプリケーションコードも復元対象に含め、定期的に復元テストと切替手順の訓練を行いましょう。継続的なデータ複製も、データ破損や削除までそのまま複製する場合があるため、バージョニングやポイントインタイム復元を組み合わせることが重要です。（出典：AWSホワイトペーパー「Disaster recovery options in the cloud」）
よくある質問（FAQ）
Q. 障害中に自分でできることはありますか？
まず、Service healthとYour account healthで、該当するイベントと影響リソースを確認します。そのうえで、自分の監視とログから影響範囲を記録し、あらかじめ定めた復旧手順があれば実行します。原因が不明なまま設定変更や再起動を繰り返すのは避け、AWS側のイベントであることがわかった場合は、イベント詳細の案内と更新を確認しながら対応しましょう。（出典：AWS公式ドキュメント「Viewing your account events in the AWS Health Dashboard」）
Q. 過去の障害履歴は確認できますか？
公開イベントについては、Service healthのService historyで過去12か月のサービス中断を確認でき、サービス、リージョン、日付で絞り込めます。アカウント固有のイベントについては、Your account healthのEvent logで過去90日間を確認します。両者は対象と保持期間が異なるため、目的に合う方を使い分けてください。（出典：AWS公式ドキュメント「AWS Health Dashboard – Service health」）（出典：AWS公式ドキュメント「Viewing your account events in the AWS Health Dashboard」）
Q. AWS Healthの通知をメールで受け取るにはどうすればよいですか？
AWSマネジメントコンソールでUser Notificationsを開き、AWS managed notifications subscriptionsからAWS Healthイベントの通知カテゴリを管理します。メールのほか、チャットやAWS Console Mobile Applicationへのプッシュ通知を選べます。影響リソースなどの詳しい情報が必要な運用では、Health DashboardやEventBridgeも併用しましょう。（出典：AWS公式ドキュメント「Manage AWS Health notifications in AWS User Notifications」）
AWSで障害が疑われるときは、まずService healthで公開イベントを確認し、ログインできるならYour account healthで自分のリソースへの影響を確かめます。その後に監視、ログ、ネットワーク、アプリケーションの状態を照合すれば、AWS側の障害と自分側の問題をより正確に切り分けられます。障害に備えるには、通知、バックアップ、復旧手順、必要に応じたマルチAZ・複数リージョン構成を、運用要件に合わせて準備しておきましょう。
