未指定Health*属性时AWS如何对HTTP/TCP目标组执行健康检查

算力阿峰

2026-8-29

问题描述

我配置了两个目标组，对应的CloudFormation YAML定义如下：

ATargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      VpcId:
        Fn::ImportValue: !Join [ "", [ !FindInMap [ EnvironmentMap, !Ref Environment, VpcStackName ], "-VPCID" ] ]
      Port: 9001
      Protocol: TCP
      TargetType: ip
      TargetGroupAttributes:
        - Key: deregistration_delay.timeout_seconds
          Value: '30'
        - Key: preserve_client_ip.enabled
          Value: true

  BTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      VpcId:
        Fn::ImportValue: !Join [ "", [ !FindInMap [ EnvironmentMap, !Ref Environment, VpcStackName ], "-VPCID" ] ]
      Port: 9002
      Protocol: TCP
      TargetType: ip
      TargetGroupAttributes:
        - Key: deregistration_delay.timeout_seconds
          Value: '30'
        - Key: preserve_client_ip.enabled
          Value: true

两个目标组均将流量转发至同一组容器：其中9001端口承载HTTP流量，9002端口承载原始TCP流量。

咨询问题：若CloudFormation模板内的所有目标组均未配置任何Health*属性，AWS将按照什么规则对已注册的目标执行健康检查？

解答

你配置的两个目标组协议均为TCP，未显式配置任何Health*属性时，AWS会直接使用TCP类型目标组的默认健康检查规则，具体如下：

健康检查协议：默认与目标组的流量转发协议保持一致，即TCP，不会自动识别端口上运行的应用层协议。即使9001端口承载HTTP流量，默认也不会发起HTTP请求校验返回状态码，仅做TCP层连通性校验
健康检查端口：默认使用目标组配置的流量转发端口，即ATargetGroup使用9001端口做探测，BTargetGroup使用9002端口做探测
探测间隔：默认每30秒对每个注册的目标发起一次健康检查探测
超时阈值：单次探测发出后10秒内未收到有效响应，即判定本次探测失败
不健康判定阈值：连续3次探测失败，对应目标会被标记为不健康，负载均衡会停止向该目标转发流量
健康恢复阈值：连续3次探测成功，之前被标记为不健康的目标会被重新标记为健康，负载均衡恢复向其转发流量
探测判定逻辑：健康检查探测会尝试和目标对应端口建立TCP三次握手，握手成功即判定本次探测健康；出现连接被拒绝、超时、无响应等情况时判定本次探测失败

注意：如果需要对9001端口的HTTP服务做应用层健康检查（例如校验特定接口返回200状态码），必须显式配置HealthCheckProtocol为HTTP、HealthCheckPath为对应检查路径、Matcher配置合法状态码范围，否则默认不会做应用层校验，可能出现端口通但服务实际不可用却被判定为健康的情况。

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