EC2「Instance reachability check failed」(1/2 ステータスチェック失敗)の修正方法

エラーの内容

EC2コンソールを開くと、次のような表示が出ています：

Instance reachability check failed (1/2 status checks failed)

インスタンスは緑色の「running」ドットを表示しています。しかしSSHはタイムアウトする。アプリは応答を停止する。AWSはインスタンスが稼働中でありながら到達不能だと伝えています — 電源は入っているのにキーボード入力に反応しないコンピューターのような状態です。

システムステータスチェックは通過しています — AWSのハードウェアは正常です。失敗しているのはインスタンスレベルのチェックです。これはあなた自身が修正する必要があります。

各ステータスチェックの意味

システムステータスチェック (2/2) — AWSのハードウェア、ネットワーク、電源。失敗した場合はAWSが対処します。
インスタンスステータスチェック (1/2 失敗) — インスタンス内部で動作しているOSとソフトウェア。あなたの問題です。

原因はほぼ常にOS内部にあります：不正なカーネル、破損したファイルシステム、誤って設定されたネットワークスタック、またはインスタンスを中途半端な状態で残したブート失敗です。

根本原因

カーネルパニックまたはブート失敗 — yum/aptのアップグレードでカーネルが入れ替わったことで引き起こされることが多い
ルートファイルシステムの破損 — /etc/fstabの不正なエントリ、シャットダウン時にディスクが満杯になった、または書き込み中に強制停止された
ネットワークインターフェースの設定ミス — DHCPが無効、MTUが不正、デフォルトルートが欠落
OOMキラーの発動 — メモリが枯渇し、重要なシステムプロセスが終了させられた
SSHデーモンのクラッシュ — インスタンス自体は稼働しているが接続できない
セキュリティグループまたはNACLがヘルスチェックトラフィックをブロックしている（稀だが確認する価値あり）

手順1 — まずシステムログを確認する

他の作業を始める前に、ここから始めてください。EC2システムログは最後のブート時のシリアルコンソール出力を記録しており、通常は何が問題だったかを正確に教えてくれます。

コンソールから：

EC2 Console → インスタンスを選択 → Actions → Monitor and troubleshoot → Get system log

CLIから：

aws ec2 get-console-output \
  --instance-id i-0abc1234567890def \
  --region us-east-1 \
  --output text

次のパターンを探してください：

Kernel panic - not syncing → カーネルまたはinitrdの問題
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY → ファイルシステムの破損
fstabのコンテキストでのERROR: device not found → 不正なマウントエントリ
Out of memory: Kill process → OOMキラーが発動した

修正1 — インスタンスを停止してから起動する（再起動ではなく）

停止→起動を行うと、インスタンスが別の基盤ハードウェアに移動します。再起動では同じホストに留まります。まずこれを試してください — OSレベルの作業なしに、一時的なハードウェアやハイパーバイザーの問題を解決できます。

aws ec2 stop-instances --instance-ids i-0abc1234567890def
aws ec2 wait instance-stopped --instance-ids i-0abc1234567890def
aws ec2 start-instances --instance-ids i-0abc1234567890def

2〜3分待ってからステータスを確認します：

aws ec2 describe-instance-status \
  --instance-ids i-0abc1234567890def \
  --query 'InstanceStatuses[0].InstanceStatus.Status'

okが返ってきた？完了です。まだ失敗している？次の修正に進んでください。

修正2 — EC2シリアルコンソールで修復する

SSHはダウンしているがインスタンスはまだ起動中ですか？EC2シリアルコンソールはカーネルレベルで接続します — ネットワーク不要、SSH不要です。

EC2 Console → Instance → Actions → Monitor and troubleshoot → EC2 Serial Console → Connect

注意点が1つあります：これはNitroベースのインスタンス（t3、m5、c5、r5、および現行世代のほとんどのタイプ）でのみ動作します。まずアカウントで有効にしてください：

aws ec2 enable-serial-console-access --region us-east-1

接続したら、よくある問題を確認してください：

# ディスク容量を確認する
df -h

# ファイルシステムエラーを確認する（可能であれば先にアンマウントする）
sudo fsck -y /dev/xvda1

# /etc/fstabの不正なエントリを確認する
cat /etc/fstab

# ブートテストのため疑わしいマウントをコメントアウトする
sudo nano /etc/fstab

修正3 — ルートボリュームをデタッチして別のインスタンスから修復する

インスタンスが完全に応答せず、シリアルコンソールも使えない場合は？ルートボリュームをデタッチし、動作しているインスタンスにマウントして外部から修正します。複雑に聞こえますが、確実な方法です — データが失われることもありません。

1. 壊れたインスタンスを停止する（終了ではなく）。

2. ルートボリュームをデタッチする：

aws ec2 detach-volume --volume-id vol-0abc123def456

3. レスキューインスタンスにセカンダリボリュームとしてアタッチする（例：/dev/xvdf）：

aws ec2 attach-volume \
  --volume-id vol-0abc123def456 \
  --instance-id i-0rescue123456 \
  --device /dev/xvdf

4. レスキューインスタンスにSSH接続してボリュームをマウントする：

sudo mkdir /mnt/recovery
sudo mount /dev/xvdf1 /mnt/recovery

# /etc/fstabを修正する
sudo nano /mnt/recovery/etc/fstab

# アンマウントされたパーティションでfsckを実行する
sudo fsck -y /dev/xvdf1

# ディスク容量を消費しているものを探す
df -h /mnt/recovery
sudo du -sh /mnt/recovery/var/log/* | sort -rh | head -20

5. アンマウントし、デタッチして、元のインスタンスにルート（/dev/xvda）として再アタッチし、起動する。

修正4 — fstabの不正なエントリ（マウント追加後に最も多い原因）

よくある落とし穴があります。EFSマウントまたは追加のEBSボリュームを/etc/fstabに追加し、nofailオプションを省略すると、次回そのリソースが利用できない場合にインスタンスがブート時にハングします。たった1つのフラグの欠落で完全にブリックします。

常にこのフォーマットを使用してください：

# EBSボリューム — nofailはボリュームがデタッチされてもブートハングを防ぐ
UUID=xxxx-xxxx  /data  ext4  defaults,nofail  0  2

# EFSマウント — nofail + _netdev（マウント前にネットワークを待機する）
fs-12345.efs.us-east-1.amazonaws.com:/ /mnt/efs efs defaults,_netdev,nofail 0 0

_netdevフラグは、マウントを試みる前にネットワークが起動するまで待機するようsystemdに指示します。両方のフラグを組み合わせることで、ネットワークマウントをfstabに安全に記述できます。

修正5 — OOM/メモリ問題

ログにOut of memory: Kill process 1234 (mysqld)のような行を見つけましたか？カーネルがRAMを使い果たし、プロセスを終了させ始めました — おそらく重要なものを。2つの選択肢があります：

より大きなインスタンスタイプにリサイズする（停止→インスタンスタイプを変更→起動）
時間を稼ぐためにスワップを追加し、その後適切に根本原因に対処する

# 復旧後に2GBのスワップを追加する
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

スワップは十分なRAMの代替にはなりません — 負荷がかかるとインスタンスが大幅に遅くなります。適切なリサイズを計画する間のバッファとして扱ってください。

確認

修正後、両方のチェックが通過していることを確認してください：

aws ec2 describe-instance-status \
  --instance-ids i-0abc1234567890def \
  --query 'InstanceStatuses[0].{System:SystemStatus.Status,Instance:InstanceStatus.Status}'

期待される出力：

{
  "System": "ok",
  "Instance": "ok"
}

次にSSHアクセスを確認し、インスタンスだけでなくアプリケーションが実際に動作していることを確認してください。

予防策

/etc/fstab内のルート以外のすべてのボリュームとネットワークマウントに対して、nofailをチームのルールにする — 例外なし
StatusCheckFailed_InstanceにCloudWatchアラームを設定して、ユーザーより先に気づけるようにする：

aws cloudwatch put-metric-alarm \
  --alarm-name ec2-instance-check-i-0abc123 \
  --namespace AWS/EC2 \
  --metric-name StatusCheckFailed_Instance \
  --dimensions Name=InstanceId,Value=i-0abc1234567890def \
  --statistic Maximum \
  --period 60 \
  --evaluation-periods 2 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:your-alert-topic

システムレベルの障害に対してEC2自動復旧を有効にする — AWSサイドのハードウェアが故障した場合、インスタンスを自動的に正常なハードウェアに移行します：

aws cloudwatch put-metric-alarm \
  --alarm-name ec2-auto-recover-i-0abc123 \
  --namespace AWS/EC2 \
  --metric-name StatusCheckFailed_System \
  --dimensions Name=InstanceId,Value=i-0abc1234567890def \
  --statistic Minimum \
  --period 60 \
  --evaluation-periods 2 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:automate:us-east-1:ec2:recover

ルートEBSボリュームのスナップショットをスケジュールで取得する — 最低でも週1回。不正なカーネルアップグレード前のスナップショットがあれば、復旧時間を数時間から数分に短縮できます
カーネルのアップグレードはまずステージング環境でテストする。到達性障害の不釣り合いに多い割合が、実行中のカーネルを入れ替えたパッケージ更新の数分以内に発生しています