EC2の4つのステータスチェックの使い方

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

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

現在のステータスチェックは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

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

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

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

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

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

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

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

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

定型復旧を段階化する 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

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

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