アプリケーションステータスチェックの導入
2026/8/10にEC2に、既存のインスタンスそのもののステータスチェック・システムのステータスチェックに加えてアプリケーションステータスのチェックが追加されました。従来のステータスチェックでは検知できなかったインスタンス・システムのチェックは正常なのにアプリだけ落ちているという状態を検知できるようになったようです。また、オートスケーリングに紐づけてアプリケーションの異常時にインスタンスの置換を行うなどの対応も可能となります(ALBのヘルスチェックを利用することで以前も可能ではありましたが、オートスケーリングのグループにインスタンスを紐づけていてもできるようになっています)。
(1次ソース)
What’s Newアナウンス:
https://aws.amazon.com/jp/about-aws/whats-new/2026/08/amazon-ec2-application-status-checks/
EC2 User Guide: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-status-checks.html
ALBのヘルスチェックとの違い
似た機能にALBのヘルスチェックがありますが、当機能はALBがなくてもステータスチェックが可能になるという最も大きな利点で、そうでなくてもALBのヘルスチェックを通していない別のパスのチェックであったり、EventBridgeの発火元などにして、非正常状態になったことを検知して対応するアクションを行う設定をすることなども可能となります。
実際の画面
GUIでの設定も可能になっていてEC2のステータス表示の画面にもアプリケーションステータスの欄が追加されていました。
こちらのアプリケーションステータスの「管理」からアプリケーションのステータスのチェックというアプリケーションステータスの設定画面に遷移することができます。
アプリケーションのステータスチェックの作成ボタンから新規にステータスチェックを設定することが可能です。プロトコル(HTTP/HTTPS)やポート・チェック対象となるパスなどを設定し、対象のEC2のNameタグの値を入れることでGUIでの設定が完了できます。
CLIでも設定が可能で、チェック定義の作成→インスタンスへの紐付けの最短2コマンドで構築可能です(詳細は冒頭のユーザーガイド参照)。
コスト
また、設定したことによるコストとして、このステータスチェックは構築時にENIを作成するため、固定費として1AZごとに $0.01/hのコストはかかるようです。CloudWatchメトリクスとして利用する場合にはさらにその分の料金も別途かかります。
まとめ
これまでEC2の「アプリだけ落ちている」状態を検知するには、CloudWatchエージェントによるカスタムメトリクスや外部監視ツールなどを自前の仕組みを組む必要がありましたが、このアプリケーションステータスチェックは特にALBを介さない構成(バッチサーバーや内部サービスなど)を運用している場合に嬉しいアップデートだったのではないでしょうか。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
