AWS于8月10日宣布，Amazon EC2新增应用状态检查。该功能可以直接监测云服务器内部的应用是否正常工作，包括Web服务器停止接受请求、Docker守护进程未运行、网络配置错误，以及网卡无法正常传输流量等情况。
EC2原有状态检查主要判断实例和底层系统能否访问，却无法说明网站、接口或容器服务是不是还在响应。新检查把可观测范围从云服务器是否在线推进到应用是否可用，让基础设施状态和业务状态能够在同一处查看。
原有检查只能确认实例和系统状态
EC2长期提供系统状态检查与实例状态检查。前者用于发现宿主硬件、电源和底层网络异常，后者侧重客户操作系统中的网络配置、内核或启动问题。两项检查通过，不代表应用进程一定正常。
一台云服务器可能仍能响应底层探测，但Nginx已经停止监听、Docker进程已经退出，或者应用端口被错误的安全规则阻断。过去要发现这类问题，管理员通常需要自行搭建CloudWatch代理、负载均衡健康检查或外部监控。
应用状态检查补上了中间这一层。它并不替代完整的应用性能监控，却能用较少配置确认关键端口和路径有没有按照预期返回结果。
检查按协议、端口和路径创建
创建检查时，用户需要指定HTTP或HTTPS协议、目标端口、请求路径，以及代表健康状态的响应代码。监测普通网站时可以选择80或443端口，接口服务则可以使用专门的健康检查路径。
健康路径应尽量轻量，同时覆盖应用真正依赖的关键环节。只返回固定文本的接口负担较小，但无法发现数据库连接或缓存故障；检查内容过重，又可能在高并发时额外消耗资源。
更合理的做法是根据业务拆分层级。基础检查确认进程与端口可用，外部监控继续观察页面加载、接口延迟和真实访问链路，两类信号相互补充。
EC2每60秒报告一次应用结果
检查与实例关联后，EC2会每60秒向配置的端口和路径发送HTTP或HTTPS请求，并根据响应代码报告应用状态。管理员可以按照实例ID关联，也可以用标签一次覆盖一组用途相同的云服务器。
标签方式更适合动态扩缩容环境。新实例只要带有对应标签，就能进入同一套检查范围，不需要每次扩容后重新维护固定服务器清单。
一分钟的探测周期适合发现持续故障，但并不是实时链路分析工具。持续时间很短的抖动、应用内部错误率和请求耗时变化，仍要依靠日志、指标与分布式追踪判断。
Auto Scaling可以自动替换异常实例
新功能可以与Auto Scaling组联动。当实例的应用状态持续异常时，Auto Scaling能够将其判定为不健康并启动替换，让新实例接管业务，减少值班人员手动登录和重启的等待时间。
自动替换前需要设置合理的启动宽限期和失败阈值。应用启动较慢、数据库迁移尚未完成或依赖服务短暂不可用时，过于敏感的规则可能连续淘汰本来能够恢复的实例。
应用还应尽量保持无状态，或把会话、上传文件和持久数据放到外部存储。否则实例被自动替换后，局部数据丢失带来的影响可能比一次进程重启更大。
全部商业区域和GovCloud均可使用
应用状态检查已经覆盖全部AWS商业区域和AWS GovCloud区域。现有实例和新建实例都可以按实例ID或标签配置，不必等待区域分批开放。
上线前应先在测试环境模拟端口关闭、Docker停止和返回码异常，确认告警、状态变化与Auto Scaling动作符合预期。生产环境还要保留日志与人工停用通道，避免错误配置导致实例反复替换。
这次更新最直接的价值，是让EC2自身就能识别常见的应用层失效。对运行Web服务和容器的团队来说，基础健康检查的配置入口更统一，但更深层的性能与业务监控仍然不可省略。
