本番 EC2 サーバーがダウン!その時にまず確認するポイントと復旧手順
はじめに
アノテーションの Shimizu です。
弊社サポートデスクに「EC2 インスタンス 1 台のみで運用している本番サーバーがダウンし、サービスに影響が出ているため何とかしたい」という緊急のお問い合わせをよくいただきます。
このような場合は慌てずに、以下のポイントを1つずつ確認することで速やかに復旧できるケースがあります。
ここでは、弊社が実際のお問い合わせでよくご案内している内容をまとめました!
ポイント1: まずインスタンスの再起動を試してみる
EC2 インスタンスのCPU使用率が高騰するなどの原因で固まっている場合は、再起動で復旧するケースもあります。
下記画面のように対象の EC2 インスタンスの左側にチェックを入れて「インスタンスを再起動」を実行し、問題が解消するか試してみましょう。

なお EC2 のシステムステータスチェックが失敗している場合は「再起動」ではなく「停止と開始」で復旧するケースもありますので、こちらも試してみましょう。
この理由は以下をご参照ください。
ポイント2: インスタンスのバックアップから復元できるか確認する
インスタンスの再起動や停止・開始で問題が解消しない場合、バックアップからインスタンスを復元できるか確認しましょう。
まずは対象インスタンスのバックアップ AMI があるか確認します。
下記画面のようにインスタンス ID でそのインスタンスから取得された AMI を検索できます。

バックアップ AMI がない場合は、EBS ボリュームのスナップショットが存在するか確認します。
下記画面のようにまず対象インスタンスの画面からボリューム ID(vol-xxxx)を確認し、そのボリューム ID から取得されたスナップショットを検索できます。


バックアップ AMI または EBS スナップショットが存在する場合は、直近の日時のものを選択して復元を行いましょう。
もし問題が発生した日時を特定できている場合は、その直前の日時から復元すれば、解消できる可能性があります。
復元方法は以下リンクを参考にしてください。
新規インスタンスを作成して復元することも、既存のインスタンスのボリュームを置き換えることも可能です。
- 作成したAMIからEC2を作成してみた! | DevelopersIO
- Amazon EC2 インスタンスを停止させることなく、そのルートボリュームを置換する - Amazon Elastic Compute Cloud
- Amazon EBS ボリュームまたは EC2 インスタンスのリストア - AWS 規範ガイダンス
ポイント3: EC2 インスタンス内部にアクセスし、問題の根本原因を解決する
バックアップ AMI も EBS スナップショットも取得していない場合は、残念ながら復元ができないため、問題の根本原因を特定して解決する必要があります。
もし対象 EC2 インスタンスに何らかの手段(SSH、RDP、SSM接続等)で接続できる場合は、EC2Rescue ツールを利用してトラブルシューティングが可能です。詳細手順は以下を参照してください。
- EC2Rescue を使用して問題のある Amazon EC2 Linux インスタンスのトラブルシューティングを行う - Amazon Elastic Compute Cloud
- EC2Rescue を使用して問題のある Amazon EC2 Windows インスタンスのトラブルシューティングを行う - Amazon Elastic Compute Cloud
もしインスタンスへの接続もできなくなっている場合、問題のインスタンスから EBS ボリュームをデタッチし、他の正常なインスタンスにアタッチすることでボリューム内部を調査できます。詳細手順は以下を参照してください。
インスタンスを復旧した後の対応
とりあえず EC2 インスタンスを復旧できて原因調査のフェーズになった場合は、試みた内容や確認した EC2Rescue の結果などを添えて、サポートに問い合わせましょう。
もしインスタンスの復旧ができていない場合でも、上記のポイント1 〜 3 をすでに確認しており、その結果を添えてサポートに問い合わせれば、スムーズに回答を得られるはずです。
さいごに
いかがでしたでしょうか。
本番サーバーがダウンした時、慌てて根本解決をしようとお問い合わせをされるお客様もいらっしゃいますが、とり急ぎインスタンスの復旧さえできれば、あとは時間に余裕を持って原因調査ができますので、まずは上記のポイント1、2でサービスの復旧を目指しましょう。
一方で、残念ながらバックアップを定期的に取得されておらず、復旧したくても数ヶ月前の状態にしか戻せない、というケースもよく見られます。
その場合は根本原因を特定する必要があり、サポートへお問い合わせいただいたとしても、解決までに非常に時間がかかってしまうことが想定されます。
理想としては本番サーバーがダウンしてもすぐにはサービスへの影響が出ないように、複数台の冗長構成にしていただくことが望ましいですが、やむを得ず EC2 インスタンス 1 台のみで運用している場合は、こまめにバックアップを取得するように心がけましょう。(下記資料参考)
この記事がお役に立てば幸いです!
参考資料まとめ
上記で紹介した記事を含め、EC2 トラブルシューティングやバックアップに関する公式情報を以下にまとめました。
- なぜ「StatusCheckFailed_System」が出たら、停止して起動すると良いのか | DevelopersIO
- 作成したAMIからEC2を作成してみた! | DevelopersIO
- Amazon EC2 インスタンスを停止させることなく、そのルートボリュームを置換する - Amazon Elastic Compute Cloud
- Amazon EBS ボリュームまたは EC2 インスタンスのリストア - AWS 規範ガイダンス
- EC2Rescue を使用して問題のある Amazon EC2 Linux インスタンスのトラブルシューティングを行う - Amazon Elastic Compute Cloud
- EC2Rescue を使用して問題のある Amazon EC2 Windows インスタンスのトラブルシューティングを行う - Amazon Elastic Compute Cloud
- 起動できないEC2インスタンス内部の問題を調査する方法 | DevelopersIO
- 起動できないEC2インスタンスの内部の問題を調査する方法(Windows版) | DevelopersIO
- AWS Backup を使用した Amazon EC2 のバックアップと復元
- スナップショットと AMI による Amazon EC2 のバックアップとリカバリ - AWS 規範ガイダンス
アノテーション株式会社について
アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。当社は様々な職種でメンバーを募集しています。「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイトをぜひご覧ください。








