AWSのEC2東京リージョンで接続できない時の対処|障害・ステータスチェックの確認

AWSのEC2に接続できない時、AWS全体の障害とは限りません。東京リージョンの公開情報と、対象インスタンスのチェック、アプリケーションの状態を照合します。本番サーバーは、原因が分からないまま停止・削除しないでください。

【要点】東京のEC2と自社リソースを照合

• リージョンが東京(ap-northeast-1)か確認します。
• インスタンスIDと、失敗したステータスチェックを記録します。
• チェックが正常でも、WebやDBなどのアプリが正常とは限りません。
• 停止・起動では一時データやIPアドレスへの影響を確認します。

公式サービス障害モニターほかのサービスの障害・メンテナンス・復旧履歴を確認

このモニターはEC2の東京リージョンの公開情報が対象です。AWS全サービス、全リージョン、S3・RDSや自社アカウント固有の障害を網羅するものではありません。必要に応じてAWS Healthの自社向け情報も確認します。

ステータスチェックと接続エラー

管理画面から確認する手順

1. EC2コンソールで東京リージョンを選び、対象インスタンスIDを確認します。
2. 実行中・停止中などの状態と、ステータスチェックの内訳を確認します。
3. 発生時刻のメトリクス、システムログ、アプリログを見て、直前の変更と照合します。
4. 同じ構成の他インスタンスやAZへの影響を比較し、対象を絞ります。

AWS公式のステータスチェックの説明を確認してください。アプリケーション用のチェックは設定状況も関係します。「チェックが通った」だけで業務画面の成功まで保証されるわけではありません。Linuxの調査は失敗したチェックの公式対処も参照します。

SSH・RDPだけつながらない場合

インスタンスが正常で、管理接続だけが失敗する場合は、接続先IP、認証方式、許可された送信元、セキュリティグループ、経路を確認します。エラーメッセージが認証失敗なのか、接続タイムアウトなのかを分けます。

接続確認のためにSSHやRDPを全世界へ開放することは避けます。必要な接続元だけを、社内の変更手順に従って確認してください。既に設定済みの管理経路がある場合は利用できますが、障害中に権限を広げて新しい経路を作る際は管理者判断が必要です。

再起動と停止・起動は同じではない

停止・起動でホストが変わる場合がありますが、インスタンスストアのデータ喪失や、自動割り当てのパブリックIPv4アドレス変更に注意が必要です。AWS公式の停止・起動の注意事項を確認し、必要なデータの保護と影響確認を先に行います。

Auto Scalingやロードバランサーがある環境は、その管理下での復旧手順に従います。手動停止によって置き換えが始まる場合もあるため、単体サーバーと同じ感覚で操作しません。DBや書き込み処理が残っている状態での強制停止は特に避けてください。

ステータスチェックは正常なのにサイトが開かない場合

チェックが通ることと、業務アプリが正常に応答することは同じではありません。Webサーバーやアプリのログ、待受ポート、ロードバランサーの対象状態、接続先DBなどを担当者が確認します。管理接続が使える場合も、原因を残すために再起動前のログや負荷を確保します。外からの接続だけ失敗するなら、セキュリティグループやネットワーク設定の変更履歴も調査対象です。

一台だけの不調と同一地域の複数台に同時発生した不調では、比較する範囲が変わります。影響台数、インスタンスID、AZ、失敗したチェック名を記録すると、AWS側への問い合わせに使えます。接続確認のために管理ポートを全世界へ開けないでください。再起動・停止開始・置き換えは別の操作なので、復旧策として実行する前に保存データと運用上の影響を確認します。

復旧後の確認とまとめ

ステータスチェック、管理接続、業務アプリ、依存するストレージやDBを順番に確認します。ジョブの再実行は処理済みデータと照合し、重複登録を防ぎます。EC2では「どのチェックが失敗したか」と「どの操作を戻す必要があるか」を分け、公開障害だけに依存しない判断が重要です。

国内の通信・アプリ・企業システム障害のまとめを見る