はじめに
2026年8月10日、Amazon EC2に「アプリケーションステータスチェック（Application status checks）」が追加されました。
EC2にはこれまでも「システムステータスチェック」と「インスタンスステータスチェック」がありましたが、これらが見ているのはあくまでインフラとOSのレイヤーです。そのため、次のような状態は検知できませんでした。
- OSは正常に起動しているが、Webサーバーのプロセスが落ちている
- Dockerデーモンが停止している
- アプリがハングしてリクエストを受け付けなくなっている
いわゆる「サーバーは生きているのに、アプリは死んでいる」状態です。これを検知するには、ALBのヘルスチェックに頼るか、CloudWatch Agentや自作のLambdaなどで独自に監視の仕組みを作り込む必要がありました。
アプリケーションステータスチェックは、この「アプリのレイヤー」の死活監視をEC2の標準機能として提供するものです。さらにAuto Scalingと連携し、アプリが異常と判定されたインスタンスを自動で置き換えることもできます。
本記事では、仕組みの整理から、マネジメントコンソールでの作成手順、異常系の挙動までをまとめます。
本記事の内容は2026年9月時点の情報です。最新情報は公式ドキュメントをご確認ください。
3つのステータスチェックの違い
| チェック種別 | 監視対象 | 検知できる例 |
|---|---|---|
| システムステータスチェック | AWS側の基盤（ハードウェア・ネットワーク） | 物理ホストの障害、電源喪失 |
| インスタンスステータスチェック | インスタンスのOS | カーネルパニック、メモリ枯渇、ネットワーク設定不備 |
| アプリケーションステータスチェック（NEW） | インスタンス上のアプリ | Webサーバー停止、アプリのハング、想定外のHTTPレスポンス |
既存の2つと並んで、インスタンスの「ステータスとアラーム」タブで確認できるようになっています。
仕組み
基本動作
アプリケーションステータスチェックは、次のように動作します。
- EC2が60秒ごとに、インスタンス上の指定ポート・パスへHTTPまたはHTTPSでリクエストを送信
- 返ってきたHTTPステータスコードを、あらかじめ設定した期待値（Status code matcher）と比較
- 連続2回失敗で異常（impaired）、連続2回成功で正常に復帰
チェック間隔は60秒固定で変更できませんが、失敗・成功の閾値やタイムアウトは変更可能です。
ちょっとした注意点
- ヘルスチェックのリクエストは HTTP/2 で送信されます
- HTTPSを選んでも サーバー証明書の検証は行われません
- リダイレクト（301/302）は追従しません
リクエストはどこから来るのか ― マネージドENI
気になるのが「チェックのリクエストがどこから飛んでくるのか」です。
アプリケーションステータスチェックでは、AWSがVPC内にマネージドなENI（Elastic Network Interface）を作成し、そこからインスタンスのプライベートIPに対してリクエストを送ります。インターネットを経由することはありません。
このマネージドENIには、次の特徴があります。
- 「送信元サブネット × セキュリティグループ」の組み合わせごとに1つ作成される
- インスタンスのENI上限にはカウントされないが、アカウントの「リージョンあたりのネットワークインターフェイス数」クォータ（AZ単位で適用）にはカウントされる
- デフォルトではコンソールやAPIの一覧に表示されない（表示設定で変更可能）
例えば、200台のインスタンスが2つのサブネットに分散していて、全台が同じSGを1つだけ使っている場合を考えます。このとき「サブネット × SG」の組み合わせは 2 × 1 = 2通りなので、マネージドENIは2つ作成されます。
では、同じ200台が3種類のSGを使い分けている場合はどうでしょうか。
組み合わせは 2サブネット × 3SG = 6通りになるため、マネージドENIは最大で6つ作成されます。「最大」としているのは、ENIが作られるのは実際にインスタンスが存在する組み合わせだけだからです。たとえば、あるSGを使うインスタンスが片方のサブネットにしかいなければ、その分の組み合わせは発生せず、ENIの数は6つより少なくなります。
2つのネットワーク経路モード
送信元・宛先のサブネットとSGを誰が決めるかで、2つのモードがあります。
| モード | 送信元・宛先の決定 | 向いているケース |
|---|---|---|
| AWSマネージドなネットワーク経路（デフォルト） | AWSが自動で選択 | まずは手軽に使いたい場合 |
| カスタマーマネージドなネットワーク経路 | 利用者が明示的に指定 | ネットワーク分離が厳格、FWルールやコンプライアンス要件がある場合 |
カスタマーマネージドにすると、ヘルスチェックの送信元を専用のサブネット・SGに限定できます。また、送信元を複数AZに配置することで、1つのAZに障害が起きても監視を継続できる構成も組めます。
セグメント設計が厳しい環境では「どこからどこへ通信が発生するか」を説明できることが重要なので、こちらのモードが選択肢になりそうです。
セキュリティグループの許可が必要
見落としやすいのが、宛先インスタンスのSGで、ヘルスチェック送信元SGからのインバウンドを許可する必要がある点です。
- AWSマネージドモード：送信元SGはチェック作成時にAWSから提示される
- カスタマーマネージドモード：自分で指定した送信元SGを許可する
これを忘れると、アプリが正常でもチェックはタイムアウトで失敗し続けます（後述の検証で実際に確認します）。
ステータスは「チェックごと」と「インスタンスごと」の2段階
アプリケーションステータスチェックは、1台のインスタンスに複数関連付けることができます。例えば、Webサーバー用（80番ポート）と管理API用（8080番ポート）の2つのチェックを、同じインスタンスに関連付けるといった使い方です。
そのため、ステータスは次の2段階で評価されます。
- チェックごとのステータス：個々のチェックが成功したか失敗したか
- インスタンスごとのステータス：そのインスタンスに関連付けられたチェックの結果をまとめた、インスタンスとしての総合判定
具体例で見てみます。
| チェック | 結果 |
|---|---|
| Webサーバー用（:80） | passed |
| 管理API用（:8080） | failed |
| インスタンスの総合判定 | impaired（1つでも失敗があるため） |
Auto Scalingが置き換えを判断するときや、CloudWatchのメトリクスStatusCheckFailed_Applicationが参照するのは、インスタンスの総合判定です。個々のチェックの結果が直接使われるわけではないようです。
総合判定に含めるかどうかを選べる（Aggregation）
各チェックは、インスタンスの総合判定に含める（included）か、含めない（excluded）かを選べます。デフォルトはincludedです。
- included：そのチェックの結果が総合判定に反映される。失敗すれば総合判定がimpairedになり、Auto Scalingによる置き換えにつながる
- excluded：チェック自体は動き、個別の結果も確認できるが、総合判定には反映されない。そのため、失敗してもAuto Scalingは動かない
先ほどの例で、管理API用のチェックをexcludedにした場合は次のようになります。
| チェック | 集約設定 | 結果 |
|---|---|---|
| Webサーバー用（:80） | included | passed |
| 管理API用（:8080） | excluded | failed |
| インスタンスの総合判定 | ― | ok（excludedのチェックは判定に使われないため） |
管理APIのチェックは失敗していますが、総合判定はokのままなので、インスタンスは置き換えられません。
この仕組みは、**本番環境に新しいチェックを追加するときの「お試しモード」**として使えます。いきなりincludedで追加すると、ポートやパスの設定ミスがあった場合に正常なインスタンスが次々と置き換えられかねません。まずはexcludedで追加して結果が想定どおりかを確認し、問題なければincludedに切り替える、という流れが公式でも推奨されています。
デフォルト設定
| 設定項目 | デフォルト値 |
|---|---|
| チェック間隔 | 60秒（固定） |
| 失敗閾値 | 連続2回 |
| 成功閾値 | 連続2回 |
| タイムアウト | 6秒（1〜30秒） |
| 期待するステータスコード | 200 |
| パス | / |
| IPバージョン | IPv4 |
| デバイスインデックス | 0 |
| 初期化猶予期間 | 300秒（1〜600秒） |
| 集約 | included |
初期化猶予期間は、インスタンス起動後チェックを開始するまでの待ち時間です。アプリの起動に時間がかかる場合、ここが短すぎるとAuto Scalingが起動途中のインスタンスを置き換えてしまうので注意が必要です。
料金
- マネージドENI 1つあたり $0.01/時間（AZごと）
- CloudWatchメトリクスは通常のCloudWatch料金
マネージドENIが1つなら、月あたり約$7.2（$0.01 × 720時間）です。監視対象のインスタンス数ではなく、ENIの数で課金される点が特徴です。
やってみた
検証構成
今回は次の構成で検証します。
- 東京リージョンのVPCに、2つのAZにまたがるパブリックサブネットを作成
- Auto Scalingグループで、Amazon Linux 2023のEC2を各AZに1台ずつ起動
- EC2にはnginxを導入し、
/healthで200を返すように設定 - アプリケーションステータスチェックは、Auto Scalingグループのタグ（
aws:autoscaling:groupName）で関連付け - ネットワーク経路はデフォルトの「AWSマネージド」を使用
EC2のセキュリティグループ（sg-app）では、インターネットからの受信は許可せず、ヘルスチェック送信元SGからの80/tcpのみ許可します。EC2への操作はSession Managerで行います。
この構成では「サブネット2つ × SG1つ」なので、マネージドENIは2つ作成される想定です。本当に2つ作られるのかも、あわせて確認してみます。
事前準備：前提リソースの作成
VPCやEC2、Auto Scalingグループは本記事の主題ではないため、CloudFormationでまとめて作成します。スタックをデプロイして、以下のリソースを作成しました。
| リソース | 内容 |
|---|---|
| VPC | 10.0.0.0/16 |
| パブリックサブネット | 10.0.1.0/24（1a）、10.0.2.0/24（1c） |
| セキュリティグループ | sg-app（インバウンドルールなし） |
| 起動テンプレート | Amazon Linux 2023 / t3.micro / nginx導入済み |
| Auto Scalingグループ | asc-verify-asg（希望容量2） |
EC2はユーザーデータでnginxを導入し、/health にアクセスすると OK を返すようにしています。
sg-appのインバウンドルールは意図的に空にしています。ヘルスチェックの送信元SGからの許可は、後の手順で追加します。
手順1：アプリケーションステータスチェックを作成する
EC2コンソールのナビゲーションペインで「インスタンス」→「アクション」→「アプリケーションのステータスチェック」を選択し、「アプリケーションステータスチェックの作成」をクリックします。
今回は次の設定で作成します。
| 項目 | 設定値 | 備考 |
|---|---|---|
| Protocol | HTTP | |
| Port | 80 | |
| Path | /health | |
| IP version | IPv4 | |
| Device index | 0 | デフォルト |
| Timeout | 6秒 | デフォルト |
| Status code matcher | 200 | デフォルト |
| Failure threshold / Success threshold | 2 / 2 | デフォルト |
| Initialization grace period | 300秒 | デフォルト |
| Aggregation | Excluded | ポイント |
| Health check paths | Do not specify network paths | AWSマネージドな経路 |
| Name tag | asc-verify-nginx |
ポイントは Aggregation（集計）をExcluded （除外されています）で作成する ことです。
仕組みのパートで触れたとおり、Excludedのチェックはインスタンスの総合判定に反映されず、Auto Scalingによる置き換えも発生しません。いきなりIncludedで作成して設定ミスがあると、正常なインスタンスが置き換えられてしまう可能性があるため、公式でも推奨されている「まずはExcludedで試す」流れで進めます。
手順2：Auto Scalingグループに関連付ける
作成したチェックを選択し、「ステータスチェックの関連付けを管理」→「タグで関連付けを管理する」を選択します。
Auto Scalingグループ配下のインスタンスをまとめて対象にするため、次のタグを指定します。
| タグキー | 値 |
|---|---|
| aws:autoscaling:groupName | asc-verify-asg |
aws:autoscaling:groupName は、Auto Scalingグループが起動したインスタンスに自動で付与されるシステムタグです。これで関連付けておけば、スケールアウトや置き換えで新しく起動したインスタンスも自動的にチェック対象になります。
手順3：SGを許可せずに結果を見てみる
ここで、あえてSGを許可しないまま結果を確認してみます。
EC2コンソールでインスタンスを選択し、「ステータスとアラーム」タブを開きます。「アプリケーションステータス」の欄に、関連付けたチェックの結果が表示されます。
数分待つと、チェックは 失敗 になりました。
手順4：SGにインバウンドルールを追加する
ヘルスチェック送信元のSGを確認し、sg-appのインバウンドルールに追加します。
（送信元SGの確認場所をスクショ付きで記載）
| タイプ | プロトコル | ポート | ソース |
|---|---|---|---|
| HTTP | TCP | 80 | ヘルスチェック送信元SG |
ルールを追加して数分待つと、チェックが 合格 に変わりました。
手順5：マネージドENIを確認する
仕組みのパートでは「サブネット×SGの組み合わせごとにマネージドENIが1つ作られる」と説明しました。今回は「サブネット2つ × SG1つ」なので、2つ作成されているはずです。
手順6：AggregationをIncludedに切り替える
動作確認ができたので、チェックを選択してAggregationを Included に変更します。
これで、このチェックの結果がインスタンスの総合判定に反映され、Auto Scalingによる置き換えの対象になります。
異常系を試してみる（nginxを停止する）
手順6でAggregationを Included に切り替えたので、ここからはチェックの結果がインスタンスの総合判定に反映され、Auto Scalingによる置き換えの対象になります。
この状態で、アプリのプロセスが落ちたことを想定してnginxを停止し、異常検知からインスタンスの置き換えまでの流れを確認します。
インスタンスへの操作はSession Managerで行います。EC2コンソールでインスタンスを1台選択し、「接続」→「セッションマネージャー」から接続してください。以降、この記事では操作対象のインスタンスを「対象インスタンス」と呼びます。
手順7：nginxを停止する
対象インスタンスでnginxを停止します。
sudo systemctl stop nginx
手順8：異常と判定されることを確認する
チェックは60秒間隔、失敗の閾値は2回なので、約2分で異常と判定されます。
SGは許可されているのでパケットはインスタンスまで届いていますが、80番ポートで待ち受けているプロセスがないため、接続が拒否されています。
手順9：Auto Scalingのアクティビティを確認する
EC2コンソールの「Auto Scaling グループ」から asc-verify-asg を選択し、「アクティビティ」タブを確認します。
Auto Scalingグループ側では、ヘルスチェックのタイプを変更するなどの設定は一切していません。アプリケーションステータスチェックを関連付けるだけで、置き換えまで自動で行われました。
なお、対象インスタンスは終了されるため、Session Managerのセッションも切断されます。
手順10：新しいインスタンスの状態を確認する
置き換えで起動した新しいインスタンスも、タグ（aws:autoscaling:groupName）で関連付けているため、自動的にチェックの対象になります。
EC2コンソールで新しいインスタンスを選択し、「ステータスとアラーム」タブを確認します。
新しいインスタンスは、起動直後は 「初期化しています」 になり、初期化猶予期間（デフォルト300秒）の経過後に評価が始まって 「成功」 になりました。
初期化猶予期間がアプリの起動時間より短いと、起動途中のインスタンスが impaired と判定され、置き換えが繰り返されるおそれがあります。起動に時間がかかるアプリでは、この値を実際の起動時間に合わせて調整しましょう。
メンテナンス中の置き換えを防ぐ（サプレッション）
Includedにしたチェックは便利な反面、デプロイやパッチ適用などでアプリを意図的に止めた場合にも、異常と判定されてインスタンスが置き換えられてしまいます。
これを防ぐための機能がサプレッションです。インスタンス単位でチェックの評価を一時停止でき、停止中のインスタンスは総合ステータスが suppressed になります。Auto Scalingは suppressed のインスタンスに対しては置き換えを行いません。
サプレッションには期間を指定でき、期間を過ぎると自動的に評価が再開されます。期間を指定しない場合は、明示的に解除するまで停止したままになります。
実運用では、デプロイツールのデプロイ前フックでサプレッションを有効化し、デプロイ後フックで解除する、という組み込み方が推奨されています。
サプレッションを解除するのは、アプリが正常に応答できる状態に戻ってからにしましょう。アプリが止まったまま解除すると、その時点から評価が再開され、異常と判定されて置き換えが始まってしまいます。
まとめ
EC2のアプリケーションステータスチェックを、マネジメントコンソールから試してみました。
- これまでのステータスチェックでは検知できなかった「OSは生きているがアプリが死んでいる」状態を、EC2の標準機能で検知できるようになった
- チェックはVPC内のマネージドENIから送られるため、宛先インスタンスのSGで送信元SGからの通信を許可する必要がある
- Auto Scalingグループにタグで関連付けるだけで、アプリの異常を検知したインスタンスが自動で置き換えられる
- 本番に導入する際は、まず
Excludedで動作を確認してからIncludedに切り替えるのが安全
ALBの配下にいないワーカーや社内向けのサーバーなど、これまでアプリレベルの死活監視を自前で作り込んでいたケースでは、特に導入を検討する価値がありそうです。