AWS EC2 应用状态检查怎么用：端口路径、健康码与自动恢复边界

线上服务偶尔返回 502 时，单看 EC2 的实例状态往往会得到一个“没问题”的结论：机器能连上，系统检查也通过，但 Web 进程可能已经不再接收请求。AWS 在 2026 年 8 月公布的应用状态检查，正好把这层应用可用性纳入 EC2 的状态观测。

它解决的不是“机器宕机”

EC2 原有的实例状态检查更接近基础设施层面的判断，例如实例是否可达、底层系统是否正常。应用进程卡死、容器端口还在但接口持续返回错误，这些情况可能不会让实例检查失败。

AWS 官方公布的应用状态检查允许指定 HTTP 或 HTTPS、端口、路径以及哪些响应码算健康。官方说明检查周期为 60 秒。这个变化的价值不在于多了一个绿色图标，而在于把“应用真的能回答请求”变成实例生命周期可以消费的信号。

先把健康端点设计成可验收的接口

不要直接拿首页或一个会访问数据库的复杂接口当健康端点。更稳妥的做法是提供一个轻量的 /healthz，让它只反映进程是否启动、关键依赖是否达到服务要求，并固定返回可判断的 HTTP 状态码。

curl -i --max-time 3 https://example.com/healthz

HTTP/1.1 200 OK
Content-Type: text/plain

ok

在控制台或自动化配置中，至少核对四件事：协议是否与监听方式一致，端口是否是应用实际监听的端口，路径是否包含正确前缀，以及 200–399 这类健康响应范围是否符合你的接口约定。这里别急着把所有 2xx、3xx、4xx 都算健康，否则“应用已经拒绝请求”的状态也可能被掩盖。

从人工探测到自动替换，中间还有一道门

应用状态一旦与 Auto Scaling 的实例替换动作相连，检查结果就不再只是监控信息。AWS 的说明提到，当应用报告不健康时，Auto Scaling 可以采取恢复动作，用新实例替换异常实例。

这对无状态 Web 服务很有吸引力，但也有三个容易被忽略的边界：应用启动慢时会不会被过早判死，依赖服务短暂抖动时是否会批量替换，以及新实例是否真的已经具备同样的配置和数据。建议先只接收告警，观察一段完整的发布周期，再打开自动替换。

上线前用一组故障注入做回归

验收不必一开始就模拟整台机器宕机，可以从应用层的几个小故障开始：

• 让 /healthz 返回 503，确认应用状态转为不健康。
• 只关闭 Web 进程，确认实例基础检查仍然可能正常，而应用检查能发现差异。
• 恢复进程后观察状态恢复时间，记录从失败到恢复的实际间隔。
• 在 Auto Scaling 场景下确认替换实例的启动日志、目标组注册和旧实例退出顺序。

每次只改变一个变量，并保留检查事件、应用日志和扩缩容活动记录。这样出现误替换时，能分清是端口填错、路径未部署，还是应用本身确实不可服务。

常见问题与延伸判断

应用状态检查会替代实例状态检查吗？

不会。两者观察层次不同，生产环境通常应该同时保留，用来区分基础设施故障和应用故障。

健康端点需要检查数据库吗？

取决于业务。如果数据库不可用时服务一定无法提供核心能力，可以检查一个有超时上限的关键依赖；但不要让健康接口执行昂贵查询，更不要让依赖抖动直接造成整组实例替换。

什么时候适合打开自动替换？

当启动流程可重复、实例不保存本地唯一数据、健康端点稳定且已经验证过误报和回滚，再考虑自动化。否则先把它当作告警信号使用。

把状态信号当成决策输入

EC2 应用状态检查的实际意义，是让“进程是否能服务”进入云基础设施的观测链路。配置本身并不复杂，难点在于健康端点的语义、失败时的处置和替换前的验证。先用人工告警跑通证据链，再逐步放大自动恢复范围，通常比一开始就交给 Auto Scaling 更容易控制风险。