Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Application status checks add application-layer coverage; they do not replace existing EC2 system and instance status checks.
- When creating a check, specify the protocol, port, path, and HTTP response codes considered healthy, then associate it by instance ID or tags.
- EC2 sends an HTTP or HTTPS request every 60 seconds. A passing check proves only that the probed path meets the criteria, not that the entire application works.
- An Auto Scaling group can initiate recovery based on application status and replace unhealthy instances, but startup, draining, and warmup must be verified before automatic actions are enabled.
- At launch, the feature covered all commercial AWS Regions and AWS GovCloud (US) Regions. Verify pricing against the current EC2 User Guide before enabling it.
Why users can still see errors when the two existing status layers are green
System status checks focus on the AWS infrastructure hosting the instance; instance status checks focus on its operating system and network reachability. Both can still pass when a web process exits, Docker daemon stops, an application port is not listening, routing is wrong, or a business health endpoint fails.
Application status checks add a third layer of active probing. They suit teams that want a unified view of application reachability in the EC2 control plane and want Auto Scaling to act on application failures. They do not replace end-to-end transaction, database semantics, or regional user-experience monitoring.
What protocol, port, path, and status codes each determine
The protocol selects HTTP or HTTPS, the port selects the target listener, the path selects the application interface actually probed, and the response-code set determines how EC2 judges health. Together, these four settings form the health-check contract. Making any one too broad can produce false greens.
Do not probe only a static page that always returns 200. A health endpoint should at least confirm that the process can handle requests. Whether to check critical dependencies depends on the recovery strategy; avoid replacing an entire instance pool at once because a shared downstream dependency fails.
Associate checks by instance ID or tags?
Instance IDs suit small-scale, fixed targets and pilots. Tags suit dynamic scaling and consistent policies, but tag changes alter check coverage. Before rollout, define tag owners, allowed values, change auditing, and alerts for unmatched instances.
In blue-green or multiversion environments, separate version, service, and environment tags. Verify the new group before widening associations. Do not use an overly broad tag to put development, staging, and production under one health-check contract.
Seven rollout steps from observation to automatic recovery
First, record the baseline for system, instance, and application monitoring. Second, choose a representative health path that does not disrupt business operations. Third, fix the protocol, port, path, and healthy codes. Fourth, associate a small number of instances. Fifth, test normal operation, stopped processes, closed ports, incorrect status codes, and network misconfiguration. Sixth, connect alerting and observe false positives. Seventh, allow Auto Scaling to replace instances based on application status.
Before automatic replacement, verify connection draining, lifecycle hooks, startup scripts, configuration retrieval, spare capacity, and warmup time. Otherwise, the probe may detect a failure but worsen it through a replacement storm.
What checking every 60 seconds means
The AWS announcement says EC2 requests the check target every 60 seconds. This frequency supports instance-level failure detection. It is not a guarantee of recovery within 60 seconds, nor does it mean that alerts and Auto Scaling actions require no additional decision time.
Brief instability, deployment restarts, and cold starts can cross probe boundaries. In nonproduction drills, measure the actual time from failure to status change, alert, and completed replacement, then use those measurements to set deployment protections and capacity.
Limitations, risks, and common misconceptions
A successful check path does not mean that login, payments, message queues, or database transactions all work. Successful HTTPS also does not remove the need to monitor certificate lifecycles separately. An unhealthy application does not always mean its instance should be replaced: shared dependencies, configuration services, or network policies may affect the entire group.
Common mistakes include treating a 200 response from / as proof of business health, replacing external synthetic monitoring with application checks, accidentally associating production instances through tags, enabling ASG replacement without a drill, and blaming every unhealthy result on a proxy.
Troubleshoot the three layers, and know when to investigate proxies
For system status failures, first inspect AWS infrastructure. For instance status failures, inspect the operating system, boot process, and instance networking. Only when those two layers pass but the application check fails should you investigate the process, port, path, status codes, TLS, and security groups in that order. For shared-dependency failures, first prevent large-scale automatic replacement.
If the check target or operations API shows explicit evidence of DNS, TLS, connection timeout, or proxy authentication problems, consult the proxy connection failure checklist. Fixed egress can help stabilize access to cloud control planes; visit the PuppyIP website to learn about related services. It cannot restore a failed application or replace proper health-check design.
Sources
Frequently Asked Questions
Do EC2 application status checks replace system and instance status checks?
No. They provide a third, application-layer signal and should be used alongside system status, instance status, and external monitoring.
How often do application status checks run?
The AWS announcement says EC2 requests the configured HTTP or HTTPS target every 60 seconds.
What can these checks examine?
You specify the protocol, port, path, and healthy response codes when creating a check. This can help detect unavailable web services, Docker daemons, network configurations, or interfaces.
How are checks associated with instances?
They can be associated by instance ID or tags. Tags are better suited to dynamic environments, but their scope and changes must be governed.
Will Auto Scaling always replace an instance after an application check fails?
An Auto Scaling group only takes replacement actions based on application status after the relevant association and recovery configuration are complete. Rehearse draining, warmup, and capacity before rollout.
Should I change proxies first when a check fails?
No. First separate system, instance, and application layers, then inspect the process, port, path, status codes, TLS, and network policies. Address the proxy only when there is an explicit proxy error.