✅ EC2ステータスチェック

マンション管理で理解する！System vs Instance

🏢 マンションで例えると超わかりやすい！

あなたはマンションに住んでいます。何か問題が起きたとき、
それは 「建物全体の問題」 ですか？それとも 「あなたの部屋だけの問題」 ですか？

🏢 マンションの構造とステータスチェック

🏗️ System Status Check
（建物全体）
🚪 Instance Status Check
（各部屋）
⚡ 電気
💧 水道
🌐 ネットワーク
🔥 ガス
🚪
301号室
(Instance 1)
🚪
302号室
(Instance 2)
🚪
303号室
(Instance 3)

💡 ポイント： 建物（System）が壊れたら全部屋に影響！部屋（Instance）の問題はその部屋だけ！

🔍 2つのステータスチェックを理解しよう

🏗️

System Status Check

建物全体の問題（AWSの責任範囲）

🏢 マンションの例
  • 建物全体の停電
  • 共用エレベーターの故障
  • 本管の水漏れ
  • インターネット回線の障害
☁️ AWSの実際の問題
  • 物理ホストの障害
  • ネットワーク接続の問題
  • 電源供給の問題
  • ハードウェアの故障

チェック項目

🔌
物理ホストへの電力供給
🌐
ネットワーク接続の可用性
🖥️
物理ホストのハードウェア
🔧
システムソフトウェアの動作
🚪

Instance Status Check

あなたの部屋の問題（ユーザーの責任範囲）

🏠 部屋の例
  • 部屋のブレーカーが落ちた
  • エアコンが壊れた
  • ルーターの設定ミス
  • 家具の配置で動線が悪い
☁️ AWSの実際の問題
  • OSのカーネルパニック
  • メモリ不足
  • ネットワーク設定の誤り
  • ファイルシステムの破損

チェック項目

🖥️
OSの動作状態
🌐
ネットワーク設定の正常性
💾
ファイルシステムの状態
🧠
メモリとCPUの使用状況

📊 詳細比較表

項目
🏗️ System Status Check
🚪 Instance Status Check
責任者
AWS（管理会社）
ユーザー（住人）
問題の範囲
物理インフラ全体
（建物レベル）
個別インスタンス
（部屋レベル）
修復方法
インスタンスの停止→起動
（別の物理ホストに移動）
インスタンスの再起動
（OS・設定の修正）
自動復旧
設定可能（Auto Recovery）
別ホストに自動移動
設定可能（Auto Recovery）
自動再起動
影響範囲
同じ物理ホストの全インスタンス
（同じ建物の全部屋）
該当インスタンスのみ
（その部屋だけ）
発生頻度
低い（AWSのインフラは堅牢）
比較的高い（設定ミスなど）

🔧 問題が起きたときの対処方法

🏗️ System Status Checkが失敗したら

建物全体の問題 = あなたには修理できません！AWSに任せて引っ越しましょう

  1. インスタンスを停止
    AWS CLIまたはコンソールでStop
  2. 少し待つ（5-10分）
    AWSが状態を確認する時間
  3. インスタンスを起動
    自動的に健全な物理ホストに配置される
  4. ステータスチェックを確認
    緑色の✓になれば完了！
💡 重要： Stop→Startで物理ホストが変わります（新しい建物に引っ越し）
⚠️ 注意： Reboot（再起動）では物理ホストは変わりません！
🚪 Instance Status Checkが失敗したら

部屋の問題 = あなたが修理する必要があります！

  1. 原因を調査
    CloudWatch Logs、システムログを確認
  2. インスタンスを再起動（Reboot）
    一時的な問題なら再起動で解決
  3. それでもダメなら詳細調査
    - メモリ不足？
    - ディスク容量不足？
    - 設定ミス？
  4. 問題を修正
    設定変更、不要ファイル削除など
💡 よくある原因：
• カーネルパニック（OSクラッシュ）
• メモリ不足でOOMキラーが発動
• ディスク容量100%
• ネットワーク設定の誤り

🎬 よくあるシナリオ

⚡

シナリオ1: 物理ホスト障害

状況： 突然インスタンスに接続できなくなった

診断：

  • System Status Check: ✗ Failed
  • Instance Status Check: ✓ OK

原因： 物理サーバーのハードウェア故障

対処： Stop → Start で別ホストに移動

🏢 マンションの例： 建物全体が停電 → 別の建物に引っ越し
💥

シナリオ2: カーネルパニック

状況： アプリケーションが応答しない

診断：

  • System Status Check: ✓ OK
  • Instance Status Check: ✗ Failed

原因： OSのクラッシュ

対処： Rebootで再起動

🏠 部屋の例： 部屋のブレーカーが落ちた → ブレーカーを上げる
🌐

シナリオ3: ネットワーク障害

状況： pingが通らない

診断：

  • System Status Check: ✗ Failed
  • Instance Status Check: ? Insufficient Data

原因： 物理ネットワーク機器の障害

対処： AWSサポートに連絡 or Stop → Start

🏢 マンションの例： 建物全体のネット回線が切断 → プロバイダに連絡
💾

シナリオ4: ディスク容量不足

状況： アプリケーションがエラーを吐く

診断：

  • System Status Check: ✓ OK
  • Instance Status Check: ✗ Failed

原因： ディスク使用率100%

対処： 不要ファイル削除 or ボリューム拡張

🏠 部屋の例： 部屋が荷物でいっぱい → 断捨離か引っ越し

🖥️ AWSコンソールでの表示例

EC2 Instance Status Checks
✓ 正常な状態（両方OK）
System Status Check: ✓ Passed
Instance Status Check: ✓ Passed
✗ 物理ホスト障害（System失敗）
System Status Check: ✗ Failed
Instance Status Check: ✓ Passed
⚠️ Action Required: Stop and Start the instance to migrate to a new host
✗ OS障害（Instance失敗）
System Status Check: ✓ Passed
Instance Status Check: ✗ Failed
⚠️ Action Required: Reboot the instance or check OS configuration

💡 知っておくべき重要なTips

🤖
自動復旧を設定しよう
CloudWatch Alarmで自動復旧を設定すると、ステータスチェック失敗時に自動的にインスタンスを復旧
📊
CloudWatchで監視
StatusCheckFailedアラームを設定して、問題をすぐに検知できるようにしましょう
🔄
Stop vs Reboot
System問題は「Stop→Start」、Instance問題は「Reboot」を使い分けましょう
⏱️
チェック間隔
ステータスチェックは1分ごとに実行されます。問題検知は迅速！
💾
データは大丈夫？
EBSボリュームはインスタンスの移動（Stop→Start）でも保持されます。安心！
🎯
テスト環境で試そう
本番前にテスト環境でStop→Startやアラームの動作を確認しましょう

🎓 まとめ

🏗️

System Status Check

建物全体の問題
AWSの責任
対処：Stop → Start

🚪

Instance Status Check

あなたの部屋の問題
ユーザーの責任
対処：Reboot or 設定修正

🎯 覚えておくべきこと：
マンションのトラブルと同じ！
建物の問題か、部屋の問題かを見極めることが大切です✨

Created by SSuzuki1063

AWS SAP Learning Resources

Created by SSuzuki1063

AWS SAP Learning Resources