EC2が落ちた！パニックになる前に読む、状況別・緊急復旧マニュアル

1. 問題が起きた！どうする？

1-1. まずは落ち着いて状況を「整理」しましょう

障害の一報を受けた際、最も怖いのは「パニックになり、確認不足で誤った操作を行い、事態を悪化させること」です。

焦る気持ちを抑え、まずは深呼吸をしましょう。その後の対応をスムーズに進めるため、以下の3点だけは動く前に確認します。

• 報告者の情報：誰から連絡が来たか？
• 発生時刻：いつからおかしいのか？
• 影響範囲：自分だけか？ 全員か？（Webサイトの場合は「自宅からもアクセスできないか」）

1-2. 関係者に「一次連絡」を入れる

運用において極めて重要なのはコミュニケーションです。関係者に一次連絡を入れることです。調査を開始するのと同時に、必ず「問題が発生しており、現在調査中である」という一次報告を関係者に入れましょう。これにより、現場のパニックを防ぎ、同じ情報が何度も報告されるのを避けることができます。

1-3. 本当にEC2が原因か？「問題の切り分け」

慌ててEC2の再起動などの操作を行う前に、その問題が本当にEC2インスタンス自体に原因があるのかを確認することが重要です。

実際には、EC2ではなく以下の要因で接続できなくなっているケースが多々あります。

• ネットワーク: 自分のパソコンのネットワークが不安定、VPNが切断されている
• 情報セキュリティ: AWSのセキュリティグループやNACLの設定を最近変更した
• DNS: ドメインの期限が切れた、DNSのキャッシュが残っている

これらの外部要因を一つずつ潰すことが、復旧への最短ルートです。EC2が原因ではないのに操作を始めることこそが、復旧を遅らせる最大の要因になります。

ここで問題がEC2にありそうだと濃厚になったら次章からの作業に取り掛かりましょう。

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

2. まずはAWSマネジメントコンソールを確認する

外部要因を排除し、EC2に問題がありそうだと判断したら、いよいよAWSマネジメントコンソールのEC2ダッシュボードを開いて現状を確認します。

ターミナルで何度も接続を試行錯誤する前に、焦らずにまずは現状を確認することが第一となります。

そこでまずやるべきは、AWSマネジメントコンソールのEC2ダッシュボードを開いて現状を確認することです。

まずはEC2ダッシュボードでサーバーの外観を確認しましょう。ここで見るべきポイントはたったの2つです。

2-1. インスタンスの状態を確認する

まずは基本中の基本です。対象のインスタンスがどのような状態にあるかを確認します。

• running: 稼働中。通常はこの状態です。ここに緑色の丸がついているのにつながらない場合、トラブル対応の本番です。
• stopped: 停止済み。誰かが誤って停止させたか、スケジュール設定で止まっている可能性があります。「開始（Start）」を押せば起動しますが、なぜ止まっていたのかのログ確認は必要です。
• terminated: 削除済み。残念ながら、このインスタンスは削除されています。復旧は不可能です（バックアップからのリストアのみ）。

2-2. ステータスチェックする

ここが一番重要な診断ポイントです。 EC2コンソールの一覧にある「ステータスチェック」の列を見てください。正常時は「2/2 のチェックに合格しました」と緑色で表示されています。

もしこれが赤くなっていたり、「1/2」等になっている場合、AWSはすでに「どこがおかしいか」を教えてくれています。

各ステータスがそれぞれ何をして問題が起きた場合の対処法は以下の通りです。

• 横にスクロールします

判断フロー

「システムステータス」が失敗している場合

• あなたの設定ミスではありません。運悪く収容されている物理サーバーが不調です。
• OSの中身を調べる必要はありません（そもそもつながりません）。
• 対処法： AWS側の障害が落ち着くのを待つか、この後のフェーズ2・ケースBで解説する「Stop/Start」で、元気な物理サーバーへ引っ越してください。

「インスタンスステータス」が失敗している場合

• インスタンスステータスの場合は、EC2内部に問題が起きています。
• OS自体は起動しようとしていますが、うまく動かない状況となっています。直近でネットワーク設定を変更したり、重い処理を実行しませんでしたか？
• 対処法： OSの再起動（Reboot）や、ログの確認が必要です。

「2/2 合格」なのにつながらない場合

• セキュリティグループ設定: 自分のパソコンのIPアドレスが変わっていませんか？
• アプリケーションのダウン: Webサーバー（Apache/Nginx）だけが落ちていませんか？
• CPU/メモリの高負荷: 負荷が高すぎて応答できない（SSHすら返せない）状態かもしれません。

2-3. 【重要】アクションを起こす前に「バックアップ」を！

具体的な復旧作業（特に再起動や設定変更）を行う前に、必ず現在のサーバーの状態を保存してください。 「バックアップが取れているか分からない」「担当者が不在」という場合は、迷わず手動でバックアップ（AMI）を作成します。

緊急バックアップの手順

• 対象インスタンスを選択し、「アクション」→「イメージとテンプレート」→「イメージを作成」をクリック。
• 「インスタンスを再起動」のチェックを外す
  稼働中の整合性は保証されませんが、強制再起動で状況が悪化するのを防ぐため、緊急時はこちらを推奨します。
• イメージ作成ボタンを押す。

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

3. サーバー内部に入り原因を特定する

AWSマネジメントコンソールでステータスを確認したら、次は「実際にサーバーに接続できるか」を確認します。これが復旧方針を決める最大の分岐点となります。

通常の保守の際の導線でSSH/RDP等でサーバーに接続しはコンソール/画面に入れるかを確認してください。

• 接続できる場合→ ケースA へ進みます
• 接続できない場合→ ケースB へ進みます

3-1. ケースA（ログイン可能）の対処法：内部リソースとログの確認

ターミナル（SSH）やリモートデスクトップ（RDP）がつながるのであれば、OSは死んでいません。 「とりあえず再起動」する前に、原因を特定しましょう。原因を潰さずに再起動しても、またすぐに同じ症状（ディスクフルなど）でダウンしてしまいます。

1. ディスク容量を確認する

ログファイルが肥大化し、ディスク使用率が100%になるとサーバーは正常に動作しません。

• Linux: $ df -h コマンドで Use% が100%になっているパーティションがないか確認。
• Windows: エクスプローラーを開き、Cドライブが赤くなっていないか確認。

2. メモリ・CPUの暴走プロセスを確認する

特定のプログラムがリソースを食いつぶしている可能性があります。

• Linux: $ top または $ htop コマンドを実行。CPUやMemoryの使用率が高いプロセスを特定し、必要であれば $ kill します。
• Windows: タスクマネージャーを開き、CPU・メモリ順にソートして確認。

3. ミドルウェアの生存確認

Webサーバー（Apache/Nginx）やDB（MySQL/PostgreSQL）のプロセスが落ちているだけかもしれません。

• コマンド例: $ systemctl status nginx などで Active: active (running) になっているか確認。落ちていれば再起動（systemctl restart ...）を試みます。

3-2. ケースB（ログイン不可）の対処法：AWS基盤側からのアプローチ

SSHやRDPがタイムアウトする場合、外から手を入れることができません。AWSマネジメントコンソール（外側）からのアプローチが必要です。

ステップ1：まずは「再起動（Reboot）」

AWSマネジメントコンソールの「インスタンスを再起動（Reboot）」は、パソコンの再起動と同じく、OSレベルでのソフトリセットです。 一時的なメモリリークや、プロセスのフリーズであればこれで直ることが多いです。まずはこれを試しましょう。

ステップ2：直らない場合は「停止・開始（Stop / Start）」

ここが一番のポイントです。Rebootで直らない、または「システムステータスチェック」が失敗している場合、一度「停止（Stop）」し、完全に停止してから「開始（Start）」を行ってください。

Stop/Start の注意点（必ず読んでください）

• パブリックIPが変わる: EIP（Elastic IP）を割り当てていない場合、IPアドレスが変わります。DNS設定の変更が必要になる可能性があります。
• インスタンスストアのデータ消失: EBSではなく、一時ストレージ（Instance Store）を使用している場合、そのデータは消えます。（現在の主流であるt3, m5系などでEBSのみを使っている場合は影響ありません）

ステップ3：画面が見えない時は「目」を使う

ログインできない原因が「Windows Updateが終わらない」「カーネルパニック」などの場合、外部からは分かりません。以下の機能で画面を確認します。

1. システムログの取得:

• 「アクション」→「モニタリングとトラブルシューティング」→「システムログを取得」
• Linuxの起動ログなどが確認でき、どこで止まっているか分かります。

2. インスタンスのスクリーンショットを取得:

• 「アクション」→「モニタリングとトラブルシューティング」→「インスタンスのスクリーンショットを取得」
• 「コンソール画面をキャプチャした画像」が見られます。ブルースクリーンや "Ready to configure Windows" などの画面が表示されていれば、OS内部の処理待ちであることが特定できます。

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

4. 再発防止と自動復帰

無事にサーバーが復旧したら、最後に「二度と同じ苦労をしないための仕組み」を作りましょう。 AWSのようなクラウドを使う最大のメリットは、「障害をゼロにすること」ではなく、「障害が起きても勝手に直るようにできること」です。

ここでは、1台構成のサーバー（SPOF構成）でも導入できる、3つの「自動化」設定を紹介します。

4-1. ダウンを即座に知る（CloudWatchアラーム）

「Webサイトが見れないんですけど」というユーザーからのクレームでサーバーダウンに気づくのは、管理者として最も避けたい事態です。サーバーが応答しなくなったら、即座にスマホへ通知が飛ぶように設定しましょう。

• 設定すべき項目: CloudWatch アラーム
• 監視指標: StatusCheckFailed（ステータスチェック失敗）
• アクション: 失敗（1以上）を検知したら、Amazon SNSを通じて自分のメールアドレスへ通知を送る。

これで、少なくとも「誰かに言われる前に」調査を開始できます。

4-2. 寝ている間に直す（EC2 Auto Recovery / Auto Scaling）

通知が来ても、深夜3時に起きてパソコンを開き、再起動ボタンを押すのは苦痛です。この「再起動」作業すらAWSに任せてしまいましょう。

A. ハードウェア障害からの自動復旧（EC2 Auto Recovery）

フェーズ2で解説した「システムステータスチェック（AWS側の障害）」が失敗した際に、AWSが自動的に復旧措置を行ってくれる機能です。

• 仕組み: インスタンスを自動的にストップ＆スタートし、正常なハードウェアへ移動させます。
• メリット: インスタンスID、IPアドレス、EBSボリュームのデータがそのまま維持されます。
• 設定方法: 「EC2アクション」→「自動復旧動作を変更」を選択するだけです。
  現在、多くのインスタンスタイプでデフォルト有効化されていますが、必ず確認しましょう

B. 作り直しによる自動復旧（Auto Scaling Group）

さらに進んだ運用として、「Auto Scaling Group」の使用を強く推奨します。通常は負荷分散（スケーリング）に使われますが、1台構成（最小:1、最大:1）で使うことで強力な「自動蘇生装置」になります。

• 仕組み: ヘルスチェック（生存確認）に失敗すると、そのインスタンスを破棄（Terminate）し、新品のインスタンスを自動で起動します
• メリット: OS内部のフリーズや、プロセスダウンなど、Rebootだけでは直らない問題も「作り直し」で強引に解決できます。
• 注意点: サーバーの中身が初期化されるため、データはEBSやS3、DB（RDS）などの外部に保存する設計（ステートレス化）が必要です。

4-3. バックアップの重要性と自動化（AWS Backup）

今回の障害対応で、「いつ取ったか分からないバックアップ」に肝を冷やしませんでしたか？ 手動バックアップは必ず忘れます。また、オペレーションミスや、近年急増しているランサムウェア被害から身を守る最後の砦はバックアップだけです。

• 推奨ツール: AWS Backup
• 設定:
  • 頻度: 1日1回（深夜帯など）
  • 保持期間: 最低でも7日間、余裕があれば1ヶ月
• メリット: EC2全体（AMI）をスケジュール通りに自動取得し、古いものは自動で削除してくれます。

「何かあったら、昨日の夜の状態に戻せばいい」という安心感があれば、障害対応時の精神的負担は劇的に軽くなります。

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

5. まとめ

サーバーダウンのアラートが鳴った瞬間、心拍数が上がるのはベテランエンジニアでも同じです。しかし、正しい手順を知っていれば、パニックは「冷静な対応」へと変わります。

「1台構成（SPOF）」のリスクと向き合う

もし今回の障害で業務が完全にストップしてしまったのなら、それはサーバー単体（SPOF：単一障害点）に依存しすぎていたサインかもしれません。

物理的な機械である以上、サーバーはいつか必ず壊れます。しかし、AWSのようなクラウドの醍醐味は、「壊れないように祈る」のではなく、「壊れても勝手に直る（あるいは予備が動く）ように設計できる」ことにあります。

今回のトラブルを教訓に、CloudWatchでの監視やAuto Recoveryの設定、あるいはマルチAZ構成への移行など、少しずつインフラを「眠れる構成」へとアップデートしていきましょう。

このコラムが、あなたの緊急対応を助け、より堅牢なシステムを作るきっかけになれば幸いです。

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

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