EC2 application status checks catch a dead app even when the instance is healthy

August 10, 2026. AWS announces application status checks, a new EC2 probe that watches the application layer. 60 seconds. The cadence at which it hits your HTTP or HTTPS endpoints. $0.01. The hourly cost per managed network interface, per availability zone.

The problem this feature solves is as old as the cloud: the historical EC2 status checks tell you whether the machine is alive, never whether the application it hosts is answering. Between the two lies the full distance from “instance is healthy” to “service is down.”

What instance status checks cannot see

EC2 has always offered two levels of status. The instance status check verifies the hardware and hypervisor; the system status check verifies that the instance’s operating system and network stack are running. Both answer a single question: is the instance reachable and booted?

They never answer the one that matters in production: is the web server still accepting connections? Is the Docker daemon running? Is the network configuration correct? Is the interface still passing traffic? An instance can show 2/2 checks passed while the application process hangs, the port stops listening, or a config change breaks the network stack.

The three levels complement each other without overlapping:

Until now, closing that gap meant homegrown glue: a custom CloudWatch probe, a load balancer health check, a monitoring agent, or a cron job that pings an endpoint. All pieces to maintain — and, crucially, signals disconnected from Auto Scaling.

How it works

Application status checks bring that monitoring into the EC2 control plane. You define a check by specifying the protocol (HTTP or HTTPS), the port, the path (for example /health), and the status code matcher that marks an application healthy (for example 200). EC2 then sends a request to that port and path every 60 seconds.

The verdict is binary and smoothed. A check is marked impaired after a number of consecutive failures, and returns to healthy after a number of consecutive successes — two by default, configurable. Requests go out over HTTP/2, and the HTTPS variant does not validate the server certificate.

The network architecture is worth understanding. The probe does not arrive from outside: AWS creates a managed ENI in your VPC, one per combination of source subnet and security group that has associated instances. Traffic originates from AWS-managed instances in the same availability zone as the target, travels over the internal network, and never crosses the public internet. That managed ENI does not count against your per-instance ENI limit, but does count against the Network interfaces per Region quota.

The Auto Scaling integration is the point

This is the real payoff. Application status checks integrate natively with Auto Scaling: when an application is marked impaired, the group can replace the instance automatically. The detect-to-react loop closes with no glue Lambda, no custom alarm, no human in the middle.

Association happens by instance ID or by tag — including the aws:autoscaling:groupName system tag, which attaches a check to every instance in a group in one command. Each check can be marked included (contributes to the overall status and drives Auto Scaling) or excluded (reports its status without triggering replacement). The recommended workflow for adding a check to a live workload is precisely to deploy it as excluded first, validate, then flip it to included.

The overall instance status aggregates every associated check: ok if all pass, impaired if at least one fails, plus the transitional states initializing, insufficient-data, and suppressed.

Setting it up in a few commands

The full flow is three steps through the AWS CLI. Create the check:

aws ec2 create-application-status-check \
  --protocol https --port 443 --path "/health" \
  --status-code-matcher "200"

Associate it with instances, by ID or by group tag:

aws ec2 associate-application-status-check \
  --application-status-check-id asc-1234567890abcdef0 \
  --target-tag-associations Key=aws:autoscaling:groupName,Value=my-asg

Then read per-instance status:

aws ec2 describe-application-status --instance-ids i-0123456789abcdef0

For VPCs with strict segmentation, firewall rules, or compliance constraints, customer-managed network paths (the --health-check-paths parameter) let you choose the source and destination subnets and security groups; otherwise AWS picks them for you.

During deployments, you can pause the verdict

An impaired status triggers an instance replacement — exactly what you do not want in the middle of a canary deployment or an in-place patch. The documentation provides a suppressed state: check evaluation is suspended for the instance for the duration of a maintenance. That is the difference between a probe that signals an incident and one that causes one during an update window.

The default smoothing points the same way: two consecutive failures before flipping to impaired, two successes before returning to healthy. A plain reboot — during which the application mechanically cannot answer — therefore does not trigger a pointless replacement. Plan for the same behavior in your pipeline: suppress the check during a rolling restart, or a deploy will look like an outage to the very signal meant to catch one.

Limits and cost

The service is not free, but the price is predictable: $0.01 per hour per managed ENI, per availability zone, plus standard CloudWatch pricing for the metrics. Quotas are generous — 50 checks per account, 50 associations per check, 200 associations per account, 5,000 targets per account — and mostly auto-adjustable. One nuance worth a glance before a broad rollout: because a managed ENI is created per source-subnet and security-group combination, a fleet spread across many subnets multiplies the interface count against the Network interfaces per Region quota. A CloudWatch alarm on quota usage avoids a silent monitoring gap.

Two design limits to keep in mind. The probe only speaks HTTP and HTTPS: no raw TCP, no gRPC health check, no script execution. And each check is bound to a single IP version (IPv4 or IPv6); monitoring both requires two checks. For an application that only answers over TCP or needs rich application-level validation, a load balancer health check or custom CloudWatch remains necessary.

On the observability side, the checks feed CloudWatch metrics (at standard pricing) and state-change events: you can attach an alarm to the flip to impaired, or an automation system to the event, without polling the API by hand.

Verdict

If you run on EC2 with Auto Scaling and an HTTP endpoint, application status checks replace most of your homegrown probes: they detect a dead application where instance status checks detect a dead machine, and they close the replacement loop without external glue. Deploy them as excluded first, then flip to included once the matcher is validated.

If your applications do not speak HTTP — pure TCP services, gRPC with rich probes, complex health contracts — keep your current monitoring. The service closes one precise blind spot; it does not replace a full observability stack.

The underlying signal: by moving incident detection from the VM to the application and wiring it natively into Auto Scaling, AWS is acknowledging that workload health is measured at the service level, not the server level. It is one more brick toward groups that repair themselves.

References

• AWS — Amazon EC2 introduces application status checks, August 10, 2026
• AWS Documentation — Application status checks (Amazon EC2 User Guide), accessed August 18, 2026
• AWS News Blog — AWS Weekly Roundup (August 17, 2026)