EC2の新機能「アプリケーションステータスチェック」でAuto Scaling自動置換を試してみた
はじめに
2026年8月10日、Amazon EC2 にアプリケーションステータスチェックが追加されました。インスタンス上で動くアプリケーションに HTTP/HTTPS リクエストを送り、レスポンスコードをもとにアプリケーションの正常性を判定する機能です。
これまでの EC2 のステータスチェックは、システムステータスチェック、インスタンスステータスチェック、アタッチされた EBS ステータスチェックの3種類でした。いずれもアプリケーションが応答しているかまでは見ていません。
本記事では、アプリケーションステータスチェックの作成とステータス遷移を確認したうえで、Auto Scaling グループにおけるインスタンスの自動置換までを検証しました。
検証内容
検証環境
| 項目 | 値 |
|---|---|
| リージョン | ap-northeast-1 |
| サブネット | 2つの AZ（ap-northeast-1a / 1c） |
| インスタンスタイプ | t3a.micro |
| AMI | Amazon Linux 2023 (ami-016923362cc95896d) |
| セキュリティグループ | ポート80：アプリケーションステータスチェックの送信元セキュリティグループからのインバウンドを許可 |
| アプリケーション | Nginx で /health エンドポイントを提供 |
アプリケーションステータスチェックの作成
チェックは create-application-status-check で作成します。指定するパラメータは、プロトコル、ポート、リクエストパス、期待するステータスコードの4つです。
aws ec2 create-application-status-check \
--protocol http \
--port 80 \
--path "/health" \
--status-code-matcher "200" \
--region ap-northeast-1
作成時のレスポンス（主要フィールドのみ抜粋）:
{
"ApplicationStatusCheck": {
"ApplicationStatusCheckId": "asc-xxxxxxxx",
"Aggregation": "included",
"Protocol": "http",
"Port": 80,
"Path": "/health",
"DeviceIndex": 0,
"IpVersion": "ipv4",
"IpScope": "private",
"Interval": 60,
"Timeout": 6,
"FailureThreshold": 2,
"SuccessThreshold": 2,
"StatusCodeMatcher": "200",
"InitializationGracePeriodSeconds": 300,
"CreationTime": "2026-08-11T00:28:25.726000+00:00"
}
}
指定した4つ以外の値は自動で設定されています。チェック間隔は60秒（変更不可）、タイムアウトは6秒、失敗閾値と成功閾値はいずれも2回、初期化グレースピリオドは300秒です。宛先はプライマリENI（DeviceIndex が 0）のプライベート IPv4 アドレスになります。
作成したチェックは、インスタンスに紐付けて初めて動き始めます。
aws ec2 associate-application-status-check \
--application-status-check-id asc-xxxxxxxx \
--instance-ids i-xxxxxxxxxxxxxxxxx \
--region ap-northeast-1
ステータス遷移の確認
紐付けたインスタンスの状態は describe-application-status で確認します。以下は ApplicationStatus 部分の抜粋です。
{
"ApplicationStatus": {
"Status": "ok",
"Details": [
{
"ApplicationStatusCheckId": "asc-xxxxxxxx",
"Status": "passed",
"Reason": {
"Code": "ResponseCodeMatched",
"StatusCode": 200,
"Protocol": "HTTP"
}
}
]
}
}
Reason.Code が ResponseCodeMatched で、--status-code-matcher に指定した 200 と実際のレスポンスコードが一致したことを示しています。
次に Nginx を停止し、異常時の挙動を確認しました。
systemctl stop nginx
{
"ApplicationStatus": {
"Status": "impaired",
"Details": [
{
"ApplicationStatusCheckId": "asc-xxxxxxxx",
"Status": "failed",
"Reason": {
"Code": "ConnectionRefused",
"StatusCode": 0
}
}
]
}
}
ステータスは impaired に変わり、理由は ConnectionRefused でした。プロセスが停止して接続できなかったため、StatusCode は 0 です。チェック間隔が60秒で、失敗閾値が2回のため、impaired への遷移には約2分かかります。
Nginx を起動すると、ステータスは ok に戻りました。
systemctl start nginx
復帰時も成功閾値が2回のため、ok への復帰には同様に約2分かかります。
Auto Scaling 連携
グループは min=1、max=2、desired=1 で作成し、ヘルスチェックの種別はデフォルトの EC2 のままにしています。
紐付け時の対象指定には、インスタンス ID を列挙する方法のほか、タグを指定する方法もあります。Auto Scaling グループはインスタンスに aws:autoscaling:groupName タグを自動付与するため、このタグで紐付ければグループ内のインスタンスを対象にできます。
aws ec2 associate-application-status-check \
--application-status-check-id asc-xxxxxxxx \
--target-tag-associations Key=aws:autoscaling:groupName,Value=app-status-check-test-asg \
--region ap-northeast-1
タグで紐付けた状態から Nginx を停止し、impaired に遷移させました。describe-scaling-activities で確認すると、置換の経緯が記録されています。
[
{
"Description": "Launching a new EC2 instance: i-xxxxxxxxxxxxxxxxx",
"Cause": "At 2026-08-11T01:05:30Z an instance was launched in response to an unhealthy instance needing to be replaced.",
"StatusCode": "Successful"
},
{
"Description": "Terminating EC2 instance: i-yyyyyyyyyyyyyyyyy",
"Cause": "At 2026-08-11T01:05:30Z an instance was taken out of service in response to an EC2 Application Status check failure.",
"StatusCode": "Successful"
}
]
インスタンスがサービスから切り離された理由として、EC2 Application Status check failure が記録されています。チェックをインスタンスに紐付けただけで置換が発生しました。
マネージドENIの仕組み
アプリケーションステータスチェックでは、VPC 内のインスタンスへ AWS 側から HTTP リクエストを送るため、リクエスト元となる ENI が作成されます。CloudTrail の CreateNetworkInterface イベントには invokedBy として ec2.application-status-checks.amazonaws.com が記録されており、この ENI は AWS 側で作成されます。
ENI は describe-network-interfaces で確認できます。Operator フィールドを見ると、マネージドENI であることが分かります。
{
"NetworkInterfaces": [
{
"NetworkInterfaceId": "eni-xxxxxxxxxxxxxxxxx",
"Description": "ec2-asc-eni-123456789012-subnet-xxxxxxxxxxxxxxxxx-sg-xxxxxxxxxxxxxxxxx",
"Operator": {
"Managed": true,
"Principal": "ec2.application-status-checks.amazonaws.com",
"HiddenByDefault": true
}
}
]
}
Operator.Managed が true、Principal がアプリケーションステータスチェックのサービスプリンシパルになっています。HiddenByDefault が true のため、コンソールの ENI 一覧では既定で表示されません。
Description にはサブネット ID とセキュリティグループ ID が含まれており、ENI はサブネットとセキュリティグループの組み合わせごとに作られます。今回は2つの AZ にまたがる構成のため、ENI は2つ作成されました。
料金は ENI 1つあたり $0.01/時間、月額換算で約 $7.30 です。
留意点
HTTPS の証明書は検証されない
HTTPS を指定した場合でも、アプリケーションステータスチェックはサーバー証明書を検証しません。証明書の有効性を監視する用途には使えない点に注意が必要です。
想定外の自動置換を防ぐ
インスタンスのリブート中は、アプリケーションが応答できないためチェックが失敗します。チェックが included で Auto Scaling グループに紐付いている場合、計画的なリブートやデプロイ、パッチ適用中の一時的な停止であっても、インスタンスが自動置換される可能性があります。
新規インスタンスの起動直後については、初期化グレースピリオド（デフォルト300秒、最大600秒）を設定し、アプリケーションが起動するまでの失敗を判定対象から除外します。
保守作業などで一時的にチェックの評価を止める場合は、Suppression を使用します。チェックの評価を継続して個別の結果を確認しつつ、インスタンス全体のステータス集計や Auto Scaling による置換の対象から外したい場合は、集計設定を excluded にします。
まとめ
ロードバランサーを経由しない cron ジョブや SQS ワーカーのようなワークロード、または TCP ヘルスチェックを設定した NLB 配下で HTTP レスポンスも確認したいワークロードに適しています。これまで Lambda などで HTTP の死活確認と置換処理を独自実装していた場合は、その実装をマネージドな機能へ置き換えられる可能性があります。該当する環境では、ぜひお試しください。
