负载均衡器健康检查失败致CDK部署停滞，求助排查

使用AWS CDK部署内部型Application Load Balancer（ALB）和Fargate服务时遇到两个核心问题：

1. CDK部署进程停滞（例如卡在步骤4/6），AWS控制台显示部署持续进行中；
2. 负载均衡器的目标组健康检查失败，但容器自身健康检查正常；将LB改为互联网可访问时，手动调用/health接口能返回200 OK状态码。

部署代码片段 #

1. 创建内部型负载均衡器 #

const relayerLoadBalancer = new elbv2.ApplicationLoadBalancer(
  this,
  "RelayerLoadBalancer",
  {
    vpc: vpc,
    internetFacing: false,
  }
);

this.relayerLoadBalancer = relayerLoadBalancer;

2. 创建Fargate服务并关联负载均衡器 #

const listener = props.relayerLoadBalancer.addListener("RelayerListener", {
    port: 80,
    protocol: elbv2.ApplicationProtocol.HTTP,
    open: true,
  });

  listener.connections.allowFromAnyIpv4(ec2.Port.allTraffic());

const sg_service = new ec2.SecurityGroup(this, "RelayerSG", {
  vpc: vpc,
  allowAllOutbound: true,
  description: "Security group for Relayer tasks",
});
sg_service.addIngressRule(
  ec2.Peer.ipv4("0.0.0.0/0"),
  ec2.Port.allTraffic()
);

// Create a Fargate service
const relayerService = new ecs.FargateService(this, "RelayerServiceM", {
  cluster: cluster,
  taskDefinition: props.taskDefinition,
  enableExecuteCommand: true,
  securityGroups: [sg_service],
  assignPublicIp: false,
  healthCheckGracePeriod: Duration.seconds(3600),
});

listener.addTargets("RelayerTarget", {
  port: 80,
  targets: [relayerService],
  healthCheck: {
    path: "/health",
    healthyHttpCodes: "200-499",
  },
});

部署停滞的核心原因大概率是目标组健康检查持续失败，导致ECS服务无法完成部署（ECS会等待目标健康后才标记部署完成），以下是针对性排查步骤：

1. 网络连通性核查 #

内部ALB仅能在VPC内部访问，健康检查请求来自ALB所在VPC的节点IP段，需确认：

• ALB的安全组是否允许出站访问Fargate任务的80端口？当前代码仅配置了Listener的入站规则，未显式配置ALB自身的出站规则，默认SG可能限制了出站流量；
• Fargate任务与ALB是否在同一VPC？且子网路由表是否允许内部流量互通（无跨子网访问限制）；
• 使用ECS Exec进入容器，尝试ping ALB的内网DNS或curl ALB内网地址，验证双向连通性。

2. 健康检查配置细节校验 #

• 确认目标组健康检查的端口与容器暴露端口一致：检查Task Definition中容器的portMappings是否正确映射80端口（Fargate主机端口可留空自动分配，目标组会自动识别容器端口）；
• 核查健康检查协议：若容器/health为HTTP接口，需确保目标组健康检查协议为HTTP，而非HTTPS；
• 检查健康检查路径：确认路径大小写、拼写与容器接口完全一致（例如容器接口是/Health则不能配置为/health）；
• 调整健康检查超时/间隔：若/health接口响应较慢，可适当调大超时时间（默认5秒）或缩短间隔时间，避免误判；
• 注意：healthCheckGracePeriod仅允许容器启动后一段时期内跳过健康检查，超时后健康检查失败仍会导致部署停滞。

3. 部署停滞的额外排查手段 #

• 查看CloudFormation事件日志：打开对应CloudFormation栈，查看停滞步骤的具体资源（如ECS服务），获取失败原因；
• 查看ECS服务事件日志：在ECS控制台找到目标服务，查看Events标签，获取“无法注册目标”“健康检查失败”等具体报错；
• 分步部署验证：先移除健康检查配置部署服务，确认服务能正常启动后，再添加健康检查配置逐步排查。

4. 其他潜在问题 #

• 容器/health接口是否依赖外部服务？若内部ALB环境下容器无法访问数据库、缓存等依赖，会导致接口返回非200，但公网环境下可正常访问；
• 查看容器日志：通过CloudWatch Logs查看容器启动日志与/health接口访问日志，确认ALB的健康检查请求是否到达容器，以及容器的响应内容。

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