---
title: EC2の4つのステータスチェックの使い方
tags: 
author: [Ryo Suzuki](https://www.docswell.com/user/suzryo)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/L71YGGNNJG.jpg?width=480
description: JAWS-UG横浜 #103 SRE支部コラボLT会 2026年4つに増えたEC2ステータスチェック。2012年頃からのアップデートと、使い分けを説明します。
published: September 19, 26
canonical: https://www.docswell.com/s/suzryo/Z9N7D9-2026-09-19-230527
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/L71YGGNNJG.jpg)

EC2の4つのステータスチェック
JAWS-UG YOKOHAMA × JAWS-UG SRE支部 共催LT会
対象: EBS-backed・非ASGの通常EC2
鈴木 亮 / @suzryo
|
スコープ外: Instance Store、ベアメタル、ASG


# Page. 2

![Page Image](https://bcdn.docswell.com/page/G7WGK5MME2.jpg)

鈴木 亮
suzuki.ryo / クラスメソッド
2014年〜
クラスメソッド株式会社
896 記事
6月:38 / 7月:124 / 8月:41 / 9月:37
Japan AWS Top Engineers
2019-2026
AWS GameDay 優勝
re:Invent 2023, 2025


# Page. 3

![Page Image](https://bcdn.docswell.com/page/4JZLZNQME3.jpg)

現在のステータスチェックは4種類
「検知」と「復旧」は別々に増えてきた
System
2012-01
AWS基盤・物理ホスト・基盤ネットワーク
Instance
2012-01
ENI経由のゲストOS到達性（ARP応答）
Attached EBS
2024-08
EC2からEBSへの到達性・I/O完了
Application
2026-08
HTTP/HTTPSのL7応答
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/YE6WZ865EV.jpg)

2012
System / Instance
System Status Check
Instance Status Check
AWS基盤・物理ホスト
NICへARPを送信
電源・基盤ネットワーク
ゲストOSのネットワークスタックが応答するか
お客様側では直接操作できない
HTTP/SSH/個別プロセスは確認しない
この時点では自動復旧も自動Rebootもない — 検知・報告だけの時代
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/GE5MW96GE4.jpg)

最初から役割が分かれていた
EC2 インスタンス
利用者に近い信号
Application
HTTP/HTTPS L7応答
Instance Status Checkは
Instance
ゲストOS到達性（ARP）
基盤・接続の観測点
System
AWS基盤・物理ホスト
ENI経由のゲストOS到達性
ENI自体の正常性ではない
Attached EBS
到達性・I/O完了
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/9729Q2MDJR.jpg)

2015〜2022年：復旧機能は後から追加
検知が先、復旧は後
時期
信号
追加された復旧
2015年1月
System
CloudWatch Recover
必要に応じて別ホストへ復旧
2015年7月
Instance
CloudWatch Reboot
同じホスト上でOSを再起動
2022年3月
System
簡易オートリカバリー
対応インスタンスでデフォルト有効化
Instance Status Checkの失敗にはOSやネットワーク設定の問題も含まれます。
Rebootで戻らない場合に備え、Stop/Startや手動修復へ段階的に進む余地があります。
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/DJY4WYXM7M.jpg)

2024
Attached EBS Status Check
EC2からアタッチEBSへの到達性とI/O完了を検知
チェック対象はディスク媒体ではなく、EC2からEBSへ到達でき、I/Oを完了できるか
OS到達性（Instance）とストレージ到達性（Attached EBS）を独立して検知できるようになった
障害時の切り分け:
• EC2ホスト/EBS接続経路の問題 → Stop/Startで別ホストへ移動
• EBS側の問題 → AWSの復旧待ち、ボリューム交換、復元など
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/V7NY9P13E8.jpg)

EBSが失敗してもOSは応答できる
System: OK
ストレージだけの異常
Instance: OK
Attached EBS: impaired
OSまで波及した場合
I/O障害がOS全体へ波及すると
ルートEBSでI/O障害が起きても
遅れてInstanceも失敗することがある
カーネルとネットワークスタックが
応答できればこの状態になり得る
Attached EBS impaired
Instance impaired
ストレージだけの異常か、OSまで波及したかを切り分けられる
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/YJ9P235P73.jpg)

2026
Application Status Check
System: OK
Instance: OK
Attached EBS: OK
Application: impaired
マネージドENIからVPC内のインスタンスへHTTP/HTTPSリクエストを送信
チェック間隔は60秒。実行基盤はAWS管理
ARPへ応答できることと、Webサービスが利用できることは別。
EC2の正常性判定がL7まで広がった。
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/GJ8D5MYXJD.jpg)

OSが正常でもサービスは正常とは限らない
Instance Status Check
Application Status Check
ARP応答でゲストOS到達性を確認
→
OSのネットワークスタックが動いていれば
Webサービスが停止していてもOK
HTTP/HTTPSでL7応答を確認
ARP応答より利用者価値に近い
サービスの応答を信号として扱える
60秒間隔
Lambda不要
月 7.30 USD
AWS管理の実行基盤
自前の監視コード不要
マネージドENI 1つあたり
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/LJLMY34NER.jpg)

4種類をどう使い分けるか
チェック
確認する場所
失敗時の代表的な操作
System
AWS基盤、物理ホスト
基盤ネットワーク
簡易オートリカバリー
CloudWatch Recover
Instance
ENI経由のゲストOS到達性
ARP応答
Reboot
直らなければStop/Start
Attached EBS
EC2からEBSへの到達性
I/O完了
AWS復旧待ち、Stop/Start
ボリューム交換
Application
HTTP/HTTPS
サービスプロセス
サービス再起動、Reboot
直らなければStop/Start
4つは競合しない。複数の結果を見ることで、異常箇所と波及範囲を切り分ける
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/47MYNDKQ7W.jpg)

定型復旧を段階化する
Step Functions
AWS SDK統合 + SSM + JSONata / Lambdaなし
Application impaired
各段階でL7応答を再確認し、復旧しなければ次の段階へ
↓
状態と診断情報を保存
↓
ブログで実装確認済み
Instance → Stop/Start → 復旧確認
約6分
SSMでサービス再起動
↓
Application → サービス再起動
4分27秒
EC2 Reboot
↓
サービス再起動失敗 → Stop/Start
5分29秒
EC2 Stop/Start（ホスト交換）
復旧成功 → 結果と診断情報を通知
復旧失敗 → 人へエスカレーション
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/P7R9D4XKE9.jpg)

復旧はワークフロー、
改善はエージェントと人
Step Functions
+ SSM Documents
DevOps Agent
Kiro
人
定型復旧
調査・改善案
判断・承認
事前に決め、安全性を
ログ・変更履歴の調査
状況判断、リスクを伴う
確認した段階的な復旧
原因候補・修正案の作成
操作の承認、恒久対策
復旧は決め打ちのワークフローへ。調査はエージェントへ。改善の判断は人へ。
実装詳細と出典は公開資料に掲載


# Page. 14

![Page Image](https://bcdn.docswell.com/page/PJXQ12657X.jpg)

実践例はブログで紹介済みです
dev.classmethod.jp/articles/ec2-application-status-check-stepfunctions-two-stage-recovery/