C2を使っていると、「突然アクセスできなくなった」「再起動したら直ったが原因が分からない」といった場面に出会います。
こうした状況で最初に確認すべき情報が、EC2のステータスチェックです。
ステータスチェックは、単なる監視項目ではありません。
障害の原因がAWS側にあるのか、それともインスタンス内部にあるのかを切り分けるための、非常に重要な判断材料です。
この記事では、EC2のステータスチェックを起点に、
- どのような障害パターンが考えられるのか
- どんな復旧判断につながるのか
を体系的に整理します。SAA-C03の学習においても、設計や運用を考える際の前提知識として役立つ内容です。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
EC2ステータスチェックの全体像を整理する
EC2のステータスチェックは、2種類に分かれています。
ここを曖昧なまま進むと、以降の判断がすべてブレます。
2種類のステータスチェック
EC2には次の2つのチェックがあります。
- システムステータスチェック
AWSが提供する物理ホストやネットワークなど、インスタンスを支える基盤側の状態を確認するもの - インスタンスステータスチェック
OSやネットワーク設定など、インスタンス内部の状態を確認するもの
AWS公式ドキュメントでも、この2つは明確に役割が分けられています。
どちらが失敗しているかで、取るべき行動の方向性が大きく変わります。
どこで確認できるか
ステータスチェックは、EC2コンソールの以下の場所で確認できます。
- インスタンス一覧画面の「Status check」列
- 個別インスタンス詳細画面の「ステータスとアラーム」
「2/2 checks passed」「1/2 checks failed」といった表示は、
どちらのチェックが失敗しているかを確認するための入口です。
ステータスチェックで分かること・分からないこと
ステータスチェックで分かるのは、
「AWS側の基盤に問題がありそうか」
「インスタンス内部に問題がありそうか」
という切り分けの方向性です。
一方で、アプリケーションの不具合やレスポンス低下など、
“動いてはいるが正しくない”状態までは検知しません。
そのため、CloudWatchメトリクスやログと組み合わせて判断する前提が重要になります。
システムステータスチェック失敗時の考え方
システムステータスチェックが失敗している場合、
インスタンスそのものよりもAWS側の基盤に問題がある可能性が高くなります。
何が起きている可能性があるのか
システムステータスチェックは、次のような状態を検知します。
- 物理ホストの障害
- ネットワークや電源など、AWS側設備の異常
この場合、OS設定を見直しても改善しないケースが多く、
利用者が直接修正できる範囲を超えていることもあります。
EBSルートかどうかが重要な分岐点
ここで重要になるのが、ルートボリュームがEBSかどうかです。
EBSルートのインスタンスであれば、
停止 → 起動を行うことで、別の物理ホスト上で再作成される可能性があります。
これはAWS公式ドキュメントでも説明されている性質で、
システム側の問題に対する現実的な対処方法の一つです。
ただし、停止・起動には以下の影響があります。
- パブリックIPv4アドレスの変更
- 一時停止中のサービス停止
そのため、Elastic IPの利用やDNS設計など、
「停止できる前提」の設計を事前に考えておくことが重要です。
自動復旧という設計の選択肢
AWSでは、システムステータスチェック失敗をトリガーに、
自動インスタンス復旧を行う仕組みも提供されています。
CloudWatchアラームでStatusCheckFailed_System を監視し、
復旧アクションを設定することで、
インスタンスを自動的に復旧させる設計が可能です。
SAA-C03の学習では、
「監視 → 検知 → 自動復旧」
という一連の流れとして理解しておくと、選択肢問題でも判断しやすくなります。
Auto Scaling配下の場合の考え方
Auto Scalingグループ配下のEC2では、
「個体を直す」よりも「置き換える」設計が自然になります。
障害が起きたインスタンスは切り離し、
新しいインスタンスを起動してサービスを継続する。
原因調査はログやメトリクスから行う、という役割分担です。
インスタンスステータスチェック失敗時の切り分け
インスタンスステータスチェックが失敗している場合、
原因はインスタンス内部にある可能性が高くなります。
よくある原因の方向性
実務や公式ドキュメントを踏まえると、
次のような切り口で考えると整理しやすくなります。
- OSの起動や設定に問題がある
- ネットワーク設定に矛盾がある
- リソース不足によって正常に動作していない
特に、OSアップデート後や設定変更直後に起きる障害は、
インスタンスステータスチェック失敗として現れることがあります。
最初に行うべき確認
ネットワーク経由で接続できなくても、
EC2コンソールから**システムログ（コンソール出力）**を確認できます。
起動プロセスで止まっている場合や、
ドライバ・ファイルシステム関連のエラーは、
ここから手がかりが得られることがあります。
Windowsインスタンスでは、
スクリーンショット機能が診断に役立つ場合もあります。
再起動で直るケースと直らないケース
一時的な問題であれば、再起動で回復することもあります。
ただし、設定ミスや構成不整合が原因の場合、
再起動しても再発することが少なくありません。
「再起動は万能ではない」という認識を持っておくことが重要です。
ネットワーク到達性の三点チェック
接続できない場合に、ほぼ必ず確認するのが次の3つです。
- Security Group
- Network ACL
- ルートテーブル
この3点の組み合わせで通信が成立しているかを確認することが、
インスタンス側障害の基本的な切り分けになります。
最終手段としてのシリアルコンソール
ネットワーク経由で一切入れない状況でも、
条件を満たせばEC2シリアルコンソールを使って調査できる場合があります。
常に使う機能ではありませんが、
「完全に詰んだ状態」を避けるための選択肢として、存在を知っておくと安心です。
予定イベントとリタイアを含めて考える
「突然落ちた」と感じる障害でも、
実際にはAWS側で予定イベントが発生している場合があります。
予定イベントとは何か
AWSは、基盤の保守や信頼性維持のために、
インスタンスの再起動や停止、リタイアをスケジュールすることがあります。
これらは利用者が自由に設定するものではなく、
通知を受けたうえで影響を最小化する行動を取る、という性質のものです。
インスタンスリタイアの意味
インスタンスリタイアは、
基盤ハードウェアに回復不能な問題が検出されたことを示します。
EBSルートの場合は停止、
インスタンスストアの場合は終了、
といった挙動の違いも理解しておく必要があります。
実務的に有効な対応
予定イベントやリタイアに対しては、
AMIを作成し、新しいインスタンスへ置き換える方法が現実的です。
「個体に依存しない」「再現できる復旧手順を持つ」
という考え方は、SAA-C03の設計問題にもつながります。
試験と実務で役立つ判断フレーム
ステータスチェックを活かすには、
単語の意味を覚えるだけでなく、判断の順番を持つことが重要です。
基本的な切り分けの流れ
- どちらのステータスチェックが失敗しているか
- ルートボリュームはEBSか
- 自動復旧やAuto Scalingで置き換える設計か
この順で考えるだけで、
取るべき選択肢がかなり絞られます。
学習時のおすすめアプローチ
SAA-C03対策では、
「システム側が落ちた場合」と
「インスタンス側が落ちた場合」
の2パターンを、自分の言葉で説明できるようにするのがおすすめです。
この整理ができていると、
設計問題でも“それっぽい単語”に引っ張られにくくなります。
体系的に学べる教材の一例
ステータスチェックは、
CloudWatch、Auto Scaling、可用性設計とセットで理解すると定着しやすくなります。
UdemyのSAA-C03向け講座のように、
監視から復旧までを一連で学べる教材を使うと、
知識が点ではなく線でつながりやすくなります。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ
EC2のステータスチェックは、障害対応の出発点です。
システムステータスチェックが失敗していれば、AWS側基盤を疑い、
停止起動や自動復旧、Auto Scalingによる置き換えを検討します。
インスタンスステータスチェックが失敗していれば、
ログ確認や再起動、ネットワーク設定の見直しといった利用者側の対応が中心になります。
さらに、予定イベントやリタイアの存在を知っておくことで、
「原因不明の障害」に振り回されにくくなります。
SAA-C03の学習では、
ステータスチェックを単独で覚えるのではなく、
障害 → 切り分け → 復旧設計という流れで理解することが、
試験対策にも実務にもつながります。
