EC2 Application Status Checks

Commands in this walkthrough are AWS CLI. You create a small VPC and an instance with a /health endpoint, then create the check and associate it.

Why another status check?

EC2 already reports whether the hypervisor and the instance are reachable. It does not know whether the process on the box is still serving traffic.

These application status checksapplication status checks
Opt-in EC2 HTTP or HTTPS probe (every 60 seconds, HTTP/2) from a managed ENI in your VPC. Reports next to system, instance, and attached EBS status checks. Port is 1–65535, not only 80/443. fill that gap: HTTP or HTTPS on any port (8080, 8081, 8443 — not only 80/443), from a managed ENImanaged ENI
AWS-created elastic network interface that originates health-check traffic. One per source subnet × source security group. Counts against ENIs per VPC, not per-instance ENI limits. in your VPC. A load balancer is optional. If you already have an ALBALB
Application Load Balancer — steers traffic with its own target-group health checks. Complementary to application status checks, which decide whether the instance should exist., the check still targets the instance, not the balancer.

What you’ll walk through

Concepts

The fourth EC2 status check, aggregation, HTTP/2 behaviour, and what the probe cannot see.

Architecture

Managed ENI, same-AZ traffic, overall status, and how Auto Scaling consumes impaired.

Deploy and Operate

VPC and EC2 with SSM, create and associate the check, verify, fail the endpoint, optional ASG replace, teardown.

Auto Scaling

No extra group health-check type. Tag aws:autoscaling:groupName and replacements follow overall status.

Pricing and quotas

$0.01 per hour per managed ENI per AZ, CloudWatch metrics, and silent target overflow at 5,000.

Reference

Comparison with ALB and Route 53, reason codes, and official docs.