新ECS部署仍引用旧任务，CDK部署Fargate后健康检查异常如何解决？

异常触发原因 #

• ECS集群存在未清理的游离资源：集成GitLab CD部署失败后，会生成不属于初始CDK栈管理的任务定义、失败任务记录，执行cdk destroy时默认只会销毁CDK栈自身创建的资源，这些游离的失败任务引用会残留于集群中，干扰新部署服务的健康度判定逻辑，导致ECS误判新任务健康检查不通过。
• 负载均衡目标组配置残留：前序栈销毁时如果未完全解除旧任务与目标组的绑定关系，新部署的任务注册到目标组后，健康检查规则可能被残留的旧配置覆盖，出现端口、路径不匹配的情况，即使应用本身能正常响应请求，也会被判定为不健康。
• 任务定义配置冲突：GitLab CD部署时会生成独立的任务定义版本，残留的旧任务定义如果和新CDK部署生成的任务定义存在端口、健康检查参数、环境变量的冲突，会导致健康检查流量路由错误，无法正确打到新启动的任务实例上。

解决方案 #

• 清理ECS集群残留资源：进入AWS ECS控制台对应集群页面，手动删除所有状态为停止、失败的非当前栈关联的任务，同时在任务定义页面注销所有不属于当前新部署栈的任务定义版本，清除旧引用。
• 校验并修复负载均衡配置：进入EC2控制台目标组页面，删除前序栈遗留的目标组资源，检查当前ECS服务绑定的目标组健康检查配置，确认端口、访问路径、超时时间、健康阈值与应用实际暴露的配置完全一致，可手动调用健康检查接口确认返回符合预期。
• 调整CDK栈的资源生命周期配置：在CDK代码中为ECS服务、任务定义、关联的目标组资源显式配置removalPolicy: RemovalPolicy.DESTROY，确保销毁栈时所有关联资源都会被同步清理。重新执行cdk deploy前先运行cdk diff命令，确认没有引用旧的残留资源ARN。
• 隔离GitLab CD的部署权限：为GitLab CD使用的AWS部署角色配置最小权限，限制其只能修改对应CDK栈管理的ECS资源，避免GitLab部署生成的资源脱离CDK的生命周期管控，产生无法自动清理的游离资源。

内容的提问来源于stack exchange，提问作者Dragos Predi