何ができるようになったか
EC2 インスタンス上で動いている「アプリケーション層」の異常を、EC2 自身が検知・通知できるようになりました。
検知できる例として挙げられているのは以下のようなケースです：
- Web サーバーがリクエストを受け付けなくなった
- Docker デーモンが停止している
- ネットワーク設定が誤っている
- ネットワークインターフェイスがトラフィックを通さなくなった
これまでとの違い
従来の EC2 ステータスチェックは「インスタンス自体」や「基盤システム」が到達不能になったときにアラートを出すもので、アプリケーションレベルの監視をしたければ自前で監視の仕組みを作って維持する必要がありました。今回の機能で、既存の instance status check / system status check と同じ枠組みの中でアプリの状態も見られるようになった、というのがポイントです。
使い方の流れ
- 監視するプロトコル・ポート・パスと、正常とみなすレスポンスコードを指定してチェックを作成
- インスタンス ID またはタグでチェックをインスタンスに関連付ける
- EC2 が指定のポート／パスに HTTP または HTTPS リクエストを送り、60 秒ごとにアプリの状態をレポートする
Auto Scaling との連携
Auto Scaling グループがアプリケーションステータスを判断材料にして、アプリが unhealthy と報告されたインスタンスを置き換えることで自動復旧を行います。
提供リージョン
全ての商用 AWS リージョンおよび AWS GovCloud (US) リージョン。
実務目線の補足
ALB のターゲットグループヘルスチェックと役割が似て見えますが、こちらはロードバランサーの背後にいないインスタンス（バッチサーバー、単体の踏み台的サーバー、内部処理用インスタンスなど）でもアプリ死活監視ができるのが大きい点です。ALB を置くほどでもないワークロードで、これまで CloudWatch Agent + カスタムメトリクス + アラームで組んでいた構成をかなり簡略化できそうです。
料金と詳細な設定手順は EC2 ユーザーガイドの application-status-checks ページに載っています。
なお、note の EC2 連載で「AMI/ストレージ」「Well-Architected のトレードオフ」あたりを扱う際、信頼性の柱（Reliability）の自動復旧の話として差し込みやすいアップデートだと思います。