Create health checks

Google Cloud provides health checking mechanisms that determine whether backend instances respond properly to traffic. This document describes how to create and use health checks for load balancers and Traffic Director.

This page assumes that you are familiar with the following concepts:

Health check categories, protocols, and ports

Google Cloud organizes health checks by category and protocol.

There are two health check categories: health checks and legacy health checks. Each category supports a different set of protocols and a means for specifying the port used for health checking.

Traffic Director and most load balancers use non-legacy health checks, but target pool-based external passthrough Network Load Balancers require that you use legacy health checks. Refer to Selecting a health check on the Health checks overview page to determine the appropriate category, protocol, and port specification method.

The protocol you select for a health check is not required to match the protocol used by the load balancer, and in some cases, it cannot. Refer to Protocols and load balancers for more information.

The term health check does not refer to legacy health checks. Legacy health checks are explicitly called legacy health checks in this document.

Listing health checks

Console

Go to the Health checks page in the Google Cloud console.
Go to the Health checks page
Click a health check to view its details.

gcloud

To list health checks, use the compute health-checks list command:

To list global health checks:

gcloud compute health-checks list \
   --global

To list regional health checks: Replace REGION_LIST with a comma-delimited list of Google Cloud regions to query.
```
gcloud compute health-checks list \
   --regions=REGION_LIST
```

After you know the name and scope of a health check, use the compute health-checks describe command to view its current configuration.

To describe a global health check, replace NAME with its name.

gcloud compute health-checks describe NAME \
   --global

To describe a regional health check, replace NAME with its name and REGION with its region.
```
gcloud compute health-checks describe NAME \
   --region=REGION
```

API

To list health checks, use these API calls:

To list global health checks: healthChecks.list
To list regional health checks: regionHealthChecks.list

To describe a health check's current configuration, use these API calls:

To describe a global health check: healthChecks.get
To describe a regional health check: regionHealthChecks.get

Creating health checks

Google Cloud allows you to create or select a health check when you complete the load balancer's backend configuration in the Google Cloud console.

You can also create a health check independently of load balancer configuration in the Google Cloud console. This is useful if you need to create your health check first, or if you need to use a health check for multiple load balancers. You can create a health check using the Google Cloud console, the Google Cloud CLI, or the REST APIs.

Console

Go to the Health checks page in the Google Cloud console.
Go to the Health checks page
Click Create a health check.
On the Create a health check page, supply the following information:
- Name: Provide a name for the health check.
- Description: Optionally, provide a description.
- Scope: Select a scope, either Global or Regional, depending on the type of load balancer.
  - If you selected Regional, pick a Region from the dropdown.
- Protocol: Choose a health check protocol.
- Port: Provide a port number. When you create a health check in the Google Cloud console, you must specify the port using a port number.
- Proxy protocol: Optionally, you can append a proxy header to the requests made by the health check probe systems.
- Request path and Response: For HTTP, HTTPS, and HTTP2 protocols, you can optionally provide a URL path for the health check probe systems to contact. For more information, see Additional flags for HTTP, HTTPS, and HTTP/2 health checks.
- Request and Response: For TCP and SSL protcols, you can specify an ASCII text string to send and expected text response string. For more information, see Additional flags for SSL and TCP health checks.
- Check interval: Define the amount of time from the start of one probe to the start of the next one.
- Timeout: Define the amount of time that Google Cloud waits for a response to a probe. Its value must be less than or equal to the check interval.
- Healthy threshold: Define the number of sequential probes that must succeed for the VM instance to be considered healthy.
- Unhealthy threshold: Define the number of sequential probes that must fail for the VM instance to be considered unhealthy.
Click Create.

gcloud

To create a global health check, use the appropriate compute health-checks create command:

gcloud compute health-checks create PROTOCOL NAME \
    --global \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

To create a regional health check, use the appropriate compute health-checks create command:

gcloud compute health-checks create PROTOCOL NAME \
    --region=REGION \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

Replace the following:

PROTOCOL defines the protocol used for the health check. Valid options are grpc, http, https, http2, ssl, and tcp.
NAME is the name of the health check. Within a given project: Each global health check must have a unique name, and regional health checks must have unique names within a given region.
REGION: All load balancers except for regional external Application Load Balancers and regional internal Application Load Balancers use global health checks (--global). Regional internal Application Load Balancers use regional health checks whose region must match the region of the backend service.
DESCRIPTION is an optional description.
CHECK_INTERVAL is the amount of time from the start of one health check probe system's connection to the start of the next one. Units are seconds. If omitted, Google Cloud uses a value of 5s (5 seconds).
TIMEOUT is the amount of time that Google Cloud waits for a response to a probe. The value of TIMEOUT must be less than or equal to the CHECK_INTERVAL. Units are seconds. If omitted, Google Cloud uses a value of 5s (5 seconds).
HEALTHY_THRESHOLD and UNHEALTHY_THRESHOLD specify the number of sequential probes that must succeed or fail for the VM instance to be considered healthy or unhealthy. If either is omitted, Google Cloud uses a default threshold of 2.
PORT_SPECIFICATION: Defines the port specification using one of the Port specification flags.
ADDITIONAL_FLAGS are other flags for specifying ports and options specific to the PROTOCOL. See Additional flags for HTTP, HTTPS, and HTTP/2 health checks, Additional flags for SSL and TCP health checks, or Additional flag for gRPC health checks.

Terraform

To create a global health check, use the google_compute_health_check resource.

lb/health_check_tcp/main.tf

View on GitHub Feedback

resource "google_compute_health_check" "health_check_tcp_with_logging" {
  provider = google-beta

  name = "health-check-tcp"

  timeout_sec        = 1
  check_interval_sec = 1

  tcp_health_check {
    port = "22"
  }

  log_config {
    enable = true
  }
}

To create a regional health check, use the google_compute_region_health_check resource.

lb/health_check_region/main.tf

View on GitHub Feedback

resource "google_compute_region_health_check" "default" {
  name               = "tcp-health-check-region-west"
  timeout_sec        = 5
  check_interval_sec = 5
  tcp_health_check {
    port = "80"
  }
  region = "us-west1"
}

To learn how to apply or remove a Terraform configuration, see Basic Terraform commands.

API

To create a global health check, use healthChecks.insert
To create a regional health check, use regionHealthChecks.insert

Modifying health checks

You cannot convert a health check to a legacy health check (or the reverse) by modifying the health check. You also cannot change a health check's name or scope (for example, global to regional).

Console

Go to the Health checks page in the Google Cloud console.
Go to the Health checks page
Click a health check to view its details.
If you need to modify the health check, click Edit, then:
- Make changes to the parameters as necessary.
- Click Save.

gcloud

Identify the name and scope of the health check. For instructions, see Listing health checks.
Except for a health check's name, protocol, and scope, you can modify any of the common flags, the port specification flags, and optional flags. To modify an existing health check, use the appropriate compute health-checks update command command. For flags that you omit, preconfigured settings are preserved.
- Example modification of a global health check: The following command modifies a global HTTP health check named hc-http-port-80 by changing its check interval, timeout, and request path:
```
gcloud compute health-checks update http hc-http-port-80 \
    --global \
    --check-interval=20s \
    --timeout=15s \
    --request-path="/health"
```
- Example modification of a regional health check: The following command modifies a regional TCP health check in us-west1 named hc-west1-tcp-ldap by changing its port specification:
```
gcloud compute health-checks update tcp hc-west1-tcp-ldap \
    --region=us-west1 \
    --port=631
```

API

Identify the name and scope of the health check. See Listing health checks for instructions.
Except for a health check's name, protocol, and scope, you can modify any of the common flags, the port specification flags, and optional flags with these API calls. Use patch API calls to preserve any preconfigured settings that are not explicitly set in the request.
- To modify a global health check, use either healthChecks.update or healthChecks.patch.
- To modify a regional health check, use either regionHealthChecks.update or regionHealthChecks.patch.

Additional flags

This section describes additional flags you can use when creating or modifying a health check. Some flags, such as port specification, must be set by using gcloud or the API.

Port specification flags

If you create a health check by using the Google Cloud CLI or the API, you have two options to specify the health check's port. The following table shows port specification options for valid load balancer and backend combinations. The term instance group refers to unmanaged instance groups, zonal managed instance groups, or regional managed instance groups.

Each health check can only use one type of port specification.

Product	Backend type	Port specification options
External passthrough Network Load Balancer	Instance groups	• `--port`: Specify a TCP port by number, from `1` to `65535` The `--use-serving-port` flag will be ignored for a health check associated with an external passthrough Network Load Balancer because backend services for external passthrough Network Load Balancers lack a port specification.
Internal passthrough Network Load Balancer	Instance groups	• `--port`: Specify a TCP port by number, from `1` to `65535` The `--use-serving-port` flag will be ignored for a health check associated with an internal passthrough Network Load Balancer because backend services for internal passthrough Network Load Balancers lack a port specification.
Global external Application Load Balancer Regional external Application Load Balancer Cross-region internal Application Load Balancer Regional internal Application Load Balancer Global external proxy Network Load Balancer Regional external proxy Network Load Balancer Regional internal proxy Network Load Balancer Traffic Director	Zonal NEGs	• `--port`: Specify a TCP port by number, from `1` to `65535` • `--use-serving-port`: Use the port of each endpoint in the network endpoint group.
	Instance groups	• `--port`: Specify a TCP port by number, from `1` to `65535` • `--use-serving-port`: Use the same instance group named port to which the backend service subscribes.

If you omit the port specification, Google Cloud uses the following defaults:

If the health check's protocol is TCP or HTTP, it uses --port=80.
If the health check's protocol is SSL, HTTPS, or HTTP2, it uses --port=443.
If the health check's protocol is GRPC, there is no implied default; you must include the port specification.

Additional flags for HTTP, HTTPS, and HTTP/2 health checks

In addition to the common flags and port specification, you can use the following optional flags for HTTP, HTTPS, and HTTP/2 health checks. This example creates an HTTP health check named hc-http-port-80 using port 80 with default interval, timeout, and health threshold criteria.

gcloud compute health-checks create HTTP_PROTOCOL hc-http-port-80 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --host=HOST \
    --proxy-header=PROXY_HEADER \
    --request-path=REQUEST_PATH \
    --response=RESPONSE

HTTP_PROTOCOL: Can be http (HTTP/1.1 without TLS), https (HTTP/1.1 with TLS), or http2 (HTTP/2 with TLS).
COMMON_FLAGS: Defines the common flags. See Creation procedure.
PORT_SPECIFICATION: Defines the port specification using one of the Port specification flags.
HOST allows you to provide a Host HTTP header. If omitted, the IP address of the load balancer's forwarding rule is used.
PROXY_HEADER must be one of NONE or PROXY_V1. If omitted, Google Cloud uses NONE. The value of PROXY_V1 adds the header PROXY UNKNOWN\r\n.
REQUEST_PATH specifies the URL path that Google Cloud uses when sending health check requests. If omitted, the health check request is sent to /.
RESPONSE defines an optional expected response. Response strings must follow these rules:
- The response string must consist of ASCII letters, numbers, and spaces.
- The response string can be up to 1,024 characters long.
- Wildcard matching is not supported.
- Content-based checking does not support inversion; for example, operators such as ! in HAProxy are not supported.

If Google Cloud finds the expected response string anywhere in the first 1,024 bytes of the received response body, and if the HTTP status is 200 (OK), the probe is considered successful.

The --request-path and --response flags modify the success criteria for the health check probe.

Additional flags for SSL and TCP health checks

In addition to the common flags and port specification, you can use the following optional flags for SSL and TCP health checks. This example creates a TCP health check named hc-tcp-3268 using port 3268 with default interval, timeout, and health threshold criteria.

gcloud compute health-checks create tcp hc-tcp-3268 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --proxy-header=PROXY_HEADER \
    --request=REQUEST_STRING \
    --response=RESPONSE_STRING

The protocol can be tcp (in this example) or ssl.
COMMON_FLAGS: Defines the common flags. See Creation procedure.
PORT_SPECIFICATION: Defines the port specification using one of the Port specification flags.
PROXY_HEADER must be one of NONE or PROXY_V1. If omitted, Google Cloud uses NONE. The value of PROXY_V1 adds the header PROXY UNKNOWN\r\n.
REQUEST_STRING: You can provide a string, up to 1,024 ASCII characters long, to send once the TCP or SSL session has been established.
RESPONSE_STRING: You can provide a string, up to 1,024 ASCII characters long, for the expected response.

The --request and --response flags modify the success criteria for the health check probe. If you use the --response flag, either by itself or in conjunction with the --request flag, the response returned must exactly match the expected response string.

Additional flag for gRPC health checks

Your backend gRPC server must implement the gRPC health service as described in the gRPC health checking protocol. Google Cloud sends a HealthCheckRequest message to your backends by calling the Check method of the health service on your backend. The service parameter in the request is set to an empty string unless a gRPC service name is specified.

A gRPC health check can check the status of a gRPC service. You can include a string, up to 1,024 ASCII characters long, that is the name of a particular gRPC service running on a backend VM or NEG. To do this, use the following optional flag for gRPC health checks:

--grpc-service-name=GRPC_SERVICE_NAME

For example, you might have the following services and status that the backend server registers with your backend's gRPC Health service.

MyPackage.ServiceA with the serving status SERVING
MyPackage.ServiceB with the serving status NOT_SERVING
Empty service name with the serving status NOT_SERVING

If you create a health check against MyPackage.ServiceA, as follows, the health check probe returns HEALTHY, because the service's status is SERVING.

gcloud beta compute health-checks create grpc MyGrpcHealthCheckServiceA \
    --grpc-service-name=MyPackage.ServiceA

If you create a health check against MyPackage.ServiceB, the health check probe returns UNHEALTHY because the service's status is NOT_SERVING.

If you create a health check against MyPackage.ServiceC, which is not registered with the gRPC Health service, the health check probe returns the gRPC status NOT_FOUND, which is the equivalent of UNHEALTHY.

If you create a health check against the empty service name, the health check probe returns the status UNHEALTHY, because the empty service name is registered with the status NOT_SERVING.

Legacy health checks

This section describes how to list, create, and modify both legacy HTTP health checks and legacy HTTPS health checks.

If the response received by the legacy health check probe is HTTP 200 OK, the probe is considered successful. All other HTTP response codes, including a redirect (301, 302), are considered unhealthy.

Legacy health checks are supported as follows:

The global external Application Load Balancer and the classic Application Load Balancer support legacy health checks if both of the following are true:
- The backends are instance groups.
- The backend VMs serve traffic that uses the HTTP or HTTPS protocol.
Target pool-based external passthrough Network Load Balancers require legacy HTTP health checks to determine the health of instances in the target pool. A target pool-based external passthrough Network Load Balancer can only use a legacy HTTP health check, not a legacy HTTPS health check. Backend service-based external passthrough Network Load Balancers use non-legacy health checks.

Listing legacy health checks

Console

Go to the Health checks page in the Google Cloud console.
Go to the Health checks page
Click on a legacy health check to view its details.

gcloud

To list legacy HTTP health checks, use the compute http-health-checks list command:
```
gcloud compute http-health-checks list
```
To list legacy HTTPS health checks, use the compute https-health-checks list command:
```
gcloud compute https-health-checks list
```
To describe a legacy HTTP health check, use the compute http-health-checks describe command, replacing NAME with its name.
```
gcloud compute http-health-checks describe NAME
```
To describe a legacy HTTPS health check, use the compute https-health-checks describe command, replacing NAME with its name.
```
gcloud compute https-health-checks describe NAME
```

API

To list legacy health checks:
- Use httpHealthChecks.list to list legacy HTTP health checks.
- Use httpsHealthChecks.list to list legacy HTTPS health checks.
To describe a legacy health check:
- Use httpHealthChecks.get to describe legacy HTTP health check.
- Use httpsHealthChecks.get to describe legacy HTTPS health check.

Creating legacy health checks

Console

Although the Google Cloud console's health checks page lists and allows you to edit both health checks and legacy health checks, you cannot create a new legacy health check from the Google Cloud console's health checks page.

You can create a legacy health check in the Google Cloud console only while creating a target pool-based external passthrough Network Load Balancer. To create the legacy health check by itself, use this section's gcloud or API instructions.

gcloud

To create a legacy health check, use the compute http-health-checks create command:

gcloud compute LEGACY_CHECK_TYPE create NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --host=HOST \
    --port=PORT \
    --request-path=REQUEST_PATH

Replace the following:

LEGACY_CHECK_TYPE is http-health-checks for a legacy HTTP health check or https-health-checks for a legacy HTTPS health check. If you are creating the legacy health check for a target pool-based external passthrough Network Load Balancer, you must use http-health-checks.
NAME is the name of the legacy health check. Within a given project, each legacy health check must have a unique name.
DESCRIPTION is an optional description.
CHECK_INTERVAL is the amount of time from the start of one probe to the start of the next one. Units are seconds. If omitted, Google Cloud uses a value of 5s (5 seconds).
TIMEOUT is the amount of time that Google Cloud will wait for a response to a probe. The value of TIMEOUT must be less than or equal to the CHECK_INTERVAL. Units are seconds. If omitted, Google Cloud uses a value of 5s (5 seconds).
HEALTHY_THRESHOLD and UNHEALTHY_THRESHOLD specify the number of sequential probes that must succeed or fail for a VM instance to be considered healthy or unhealthy. If either is omitted, Google Cloud uses a default threshold of 2.
HOST allows you to provide a host HTTP header. If omitted, the IP address of the load balancer's forwarding rule is used.
PORT allows you to provide a port number. If omitted, Google Cloud uses 80.
REQUEST_PATH specifies the URL path that Google Cloud uses when sending health check requests. If omitted, the health check request is sent to /.

API

To create a legacy HTTP health check, use the httpHealthChecks.insert API call.
To create a legacy HTTPS health check, use the httpsHealthChecks.insert

Terraform

To create a legacy HTTP health check resource, use the google_compute_http_health_check resource.
To create a legacy HTTPS health check resource, use the google_compute_https_health_check resource.

Modifying legacy health checks

Console

Go to the Health checks page in the Google Cloud console.
Go to the Health checks page
Click on a health check to view its details.
Click Edit , make changes, and then click Save.

gcloud

To modify a legacy HTTP health check, use the compute http-health-checks update command, replacing NAME with its name. When modifying a legacy health check with gcloud, preconfigured settings for flags you omit are preserved. The OTHER_OPTIONS are the options described in creating a legacy health check.
```
gcloud compute http-health-checks update NAME \
  OTHER_OPTIONS
```
To modify a legacy HTTPS health check, use the compute https-health-checks update command, replacing NAME with its name. When modifying a legacy health check with gcloud, preconfigured settings for flags you omit are preserved. The OTHER_OPTIONS are the options described in creating a legacy health check.
```
gcloud compute https-health-checks update NAME \
  OTHER_OPTIONS
```

API

Except for a legacy health check's name and type, you can modify any of the flags used for its creation. The patch API calls preserve any preconfigured settings that are not explicitly set in the patch request.

To modify a legacy HTTP health check, use either httpHealthChecks.update or httpHealthChecks.patch.
To modify a legacy HTTPS health check, use either httpsHealthChecks.update or httpsHealthChecks.patch.

Required firewall rules

You need to create ingress firewall rules applicable to all VMs being load balanced to allow traffic from health check prober IP ranges. The following examples create firewall rules that are applicable to VM instances by target tag. For more information about specifying targets for firewall rules, see the explanation of targets in the Firewall Rules Overview and Configuring Network Tags.

Each of these examples allows all TCP traffic from Google Cloud health check systems to your VM instances. (TCP traffic includes SSL, HTTP, HTTPS, and HTTP/2 traffic.) If you prefer, you can specify ports along with the TCP protocol; however, if you specify ports, your firewall rules might become specific to a particular health check. If you use tcp:80 for the protocol and port, this allows TCP traffic on port 80, so Google Cloud could contact your VMs using HTTP on port 80, but it could not contact them using HTTPS on port 443.

Firewall rules for health checks

The following example creates an ingress firewall rule for the following load balancers:

Cross-region internal Application Load Balancer
Regional internal Application Load Balancer
Global external Application Load Balancer
Regional external Application Load Balancer
Global external proxy Network Load Balancer
Regional external proxy Network Load Balancer
Regional internal proxy Network Load Balancer
Internal passthrough Network Load Balancer

For these load balancers, the source IP ranges for health checks (including legacy health checks if used for external Application Load Balancers) are:

35.191.0.0/16
130.211.0.0/22

For internal passthrough Network Load Balancers handling IPv6 traffic, you must allow health check probes from the following source IP address ranges:

35.191.0.0/16
130.211.0.0/22

For IPv6 traffic to the backends:

2600:2d00:1:b029::/64

There are certain exceptions to the firewall rule requirements for these ranges:

External passthrough Network Load Balancers use a different set of health check probes. If you need to create firewall rules for an external passthrough Network Load Balancer, see the next section, Firewall rules for external passthrough Network Load Balancers.
Allowlisting Google's health check probe ranges isn't required for regional Envoy-based load balancers if you're using only hybrid NEG backends that use distributed Envoy health checks. This is because health check probes for hybrid NEGs originate from the load balancer's proxy-only subnet. However, if you're using a combination of hybrid and zonal NEGs in a single backend service, you need to allowlist the Google health check probe ranges for the zonal NEGs.
For regional internet NEGs, health checks are optional. Traffic from load balancers using regional internet NEGs originates from the proxy-only subnet and is then NAT-translated (by using Cloud NAT) to either manual or auto-allocated NAT IP addresses. This traffic includes both health check probes and user requests from the load balancer to the backends. For details, see Regional NEGs: Use Cloud NAT to egress.

Console

In the Google Cloud console, go to the Firewall policies page.
Go to Firewall policies
Click Create firewall rule.
On the Create a firewall rule page, supply the following information:
- Name: Provide a name for the rule. For this example, use fw-allow-health-checks.
- Network: Choose a VPC network.
- Priority: Enter a number for the priority. Lower numbers have higher priorities. Be sure that the firewall rule has a higher priority than other rules that might deny ingress traffic.
- Direction of traffic: Choose ingress.
- Action on match: Choose allow.
- Targets: Choose Specified target tags, and then enter tags in the Target tags text box. For this example, use allow-health-checks.
- Source filter: Choose IP ranges.
- Source IP ranges: 35.191.0.0/16,130.211.0.0/22
- Allowed protocols and ports: Use tcp and the port configured in your health check. TCP is the underlying protocol for all health check protocols.
- Click Create.
On each of your instances being load balanced, add the network tag so that this new ingress firewall rule applies to them. This example uses allow-health-checks for the network tag.

gcloud

Use the following gcloud command to create a firewall rule named fw-allow-health-checks that allows incoming TCP connections, from Google Cloud health check systems, to instances in your VPC network with the allow-health-checks tag. Replace NETWORK_NAME with the name of your VPC network and replace PORT with the ports used by your load balancer.
```
gcloud compute firewall-rules create fw-allow-health-checks \
    --network=NETWORK_NAME \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=35.191.0.0/16,130.211.0.0/22 \
    --target-tags=allow-health-checks \
    --rules=tcp:PORT
```
On each of your instances being load balanced, add the network tag so that this new ingress firewall rule applies to them. This example uses allow-health-checks for the network tag.

Refer to the gcloud firewall rules documentation and the API documentation for more details.

Firewall rules for external passthrough Network Load Balancers

The following example creates an ingress firewall rule for an external passthrough Network Load Balancer.

For external passthrough Network Load Balancers handling IPv4 traffic, you must allow health check probes from the following source IP address ranges:

For IPv4 traffic to the backends:

35.191.0.0/16
209.85.152.0/22
209.85.204.0/22

For IPv6 traffic to the backends:

2600:1901:8001::/48

These ranges apply to both types of external passthrough Network Load Balancers: target pool-based external passthrough Network Load Balancer that use legacy health checks, and backend service-based external passthrough Network Load Balancer that use non-legacy health checks.

Console

In the Google Cloud console, go to the Firewall policies page.
Go to Firewall policies
Click Create firewall rule.
On the Create a firewall rule page, supply the following information:
- Name: Provide a name for the rule. For this example, use fw-allow-network-lb-health-checks.
- Network: Choose a VPC network.
- Priority: Enter a number for the priority. Lower numbers have higher priorities. Be sure that the firewall rule has a higher priority than other rules that might deny ingress traffic.
- Direction of traffic: Choose ingress.
- Action on match: Choose allow.
- Targets: Choose Specified target tags, and then enter tags in the Target tags text box. For this example, use allow-network-lb-health-checks.
- Source filter: Choose IP ranges.
- Source IP ranges: 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22
- Allowed protocols and ports: Use tcp. TCP is the underlying protocol for HTTP and HTTPS.
- Click Create.
On each of your instances being load balanced, add the network tag so that this new ingress firewall rule applies to them. This example uses allow-network-lb-health-checks for the network tag.

gcloud

Use the following gcloud command to create a firewall rule named fw-allow-network-lb-health-checks that allows incoming TCP connections, from Google Cloud health check systems, to instances in your VPC network with the allow-network-lb-health-checks tag. Replace NETWORK_NAME with the name of your VPC network.
```
gcloud compute firewall-rules create fw-allow-network-lb-health-checks \
    --network=NETWORK_NAME \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=35.191.0.0/16,209.85.152.0/22,209.85.204.0/22 \
    --target-tags=allow-network-lb-health-checks \
    --rules=tcp
```
On each of your instances being load balanced, add the network tag so that this new ingress firewall rule applies to them. This example uses allow-network-lb-health-checks for the network tag.

Refer to the gcloud firewall rules documentation and the API documentation for more details.

Associating health checks with load balancers and Traffic Director

This section describes certain health check recommendations and the requirements that must be met before you associate a health check with a load balancer or Traffic Director.

Matching the protocol

It's best to use a health check (or legacy health check) whose protocol matches the protocol used by the load balancer's backend service or target pool. However, the health check protocols and load balancer protocols do not need to be the same. As examples:

For internal passthrough Network Load Balancers, you can only use TCP or UDP for the backend service's protocol. If you serve HTTP traffic from VMs behind an internal passthrough Network Load Balancer, it makes sense to employ a health check using the HTTP protocol.
A target pool-based external passthrough Network Load Balancer must use a legacy HTTP health check. It cannot use a legacy HTTPS health check or any non-legacy health check. If you use a target pool-based external passthrough Network Load Balancer to balance TCP traffic, you need to run an HTTP service on the VMs being load balanced so that they can respond to health check probes.

A backend service-based external passthrough Network Load Balancer can use non-legacy health checks. That is, you can use a health check whose protocol matches the protocol used by the external passthrough Network Load Balancer's backend service.
For backend services that use the gRPC protocol, use only gRPC or TCP health checks. Do not use HTTP(S) or HTTP/2 health checks.
For Traffic Director with internet NEGs (INTERNET_FQDN_PORT endpoints) or hybrid NEGs (NON_GCP_PRIVATE_IP_PORT endpoints), use one of HTTP, HTTPS, HTTP/2, or TCP health checks.
Certain Envoy-based load balancers that use hybrid NEG backends do not support gRPC health checks. For more information, see the Hybrid NEGs overview.

Health checks for backend services

This section describes how to associate a health check with a backend service for all types of load balancers.

This section assumes that you have already:

Created a load balancer.
Created a health check.
Configured the firewall rules for health checks. In case of a backend service-based external passthrough Network Load Balancer, see Firewall rules for external passthrough Network Load Balancers.

To associate a health check with a new internal passthrough Network Load Balancer, external proxy Network Load Balancer, external Application Load Balancer, or backend service-based external passthrough Network Load Balancer, refer to the setup guide for the respective load balancer.

Console

To associate a health check with an existing load balancer:

Go to the Load balancing page in the Google Cloud console.
Go to the Load balancing page
Click on a load balancer to view its details.
Click Edit , and then click Backend configuration.
Choose a health check from the Health check menu.
Click Update.

gcloud

To associate a health check with an existing backend service, follow these steps.

Identify the name and scope of the backend service. The external passthrough Network Load Balancers, internal passthrough Network Load Balancers, regional internal proxy Network Load Balancers, and external proxy Network Load Balancers have only one backend service per load balancer. The external Application Load Balancers and internal Application Load Balancers have one or more backend services associated with a single URL map.
- To list backend services for internal passthrough Network Load Balancers, run the following command, replacing REGION_LIST with a comma-delimited list of Google Cloud regions to query.
```
gcloud compute backend-services list \
    --filter="region:( REGION1 REGION2 ... ) AND loadBalancingScheme=INTERNAL"
```
- To list backend services for external passthrough Network Load Balancers, run the following command, replacing each REGION with the Google Cloud region to query.
```
gcloud compute backend-services list \
    --filter="region:( REGION1 REGION2 ... ) AND loadBalancingScheme=EXTERNAL"
```
- To list backend services for global external proxy Network Load Balancers, run the following command.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL" \
    --filter="protocol=TCP"
```
- To list backend services for regional external proxy Network Load Balancers, run the following command.
```
gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=EXTERNAL_MANAGED" \
    --filter="protocol=TCP"
```
- To list backend services for regional internal proxy Network Load Balancers, run the following command, replacing REGION_LIST with a comma-delimited list of Google Cloud regions to query.
```
gcloud beta compute backend-services list \
    --filter="region:( REGION1 REGION2 ... ) AND loadBalancingScheme=INTERNAL_MANAGED"
```
- To list backend services for external proxy Network Load Balancers using SSL, run the following command. Backend services for these load balancers are always global, regardless of the Network Service Tier.
```
gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL" \
    --filter="protocol=SSL"
```
- To identify backend services for an external Application Load Balancer, first identify a URL map, and then describe the map. URL maps and backend services for external Application Load Balancers and cross-region internal Application Load Balancers are always global, regardless of the Network Service Tier. Replace URL_MAP_NAME with the name of the URL map. The backend services used by the load balancer are listed in the response.
```
gcloud compute url-maps list \
    --global
```
```
gcloud compute url-maps describe URL_MAP_NAME \
    --global
```
- To identify backend services for either a regional external Application Load Balancer or a regional internal Application Load Balancer, first identify a URL map, and then describe the map. Both URL maps and backend services for these load balancers are regional. Replace REGION_LIST with a comma-delimited list of Google Cloud regions to query. Replace URL_MAP_NAME with the name of the URL map and REGION with its region. The backend services used by the load balancer are listed in the response.
```
gcloud compute url-maps list \
    --regions=REGION_LIST
```
```
gcloud compute url-maps describe URL_MAP_NAME \
    --region=REGION
```
Identify a health check. See Listing health checks.
Associate a health check with the backend service by using the compute backend-services update command. Each backend service must reference a single health check. In the following commands, replace BACKEND_SERVICE_NAME with the name of the backend service, HEALTH_CHECK_NAME with the name of the health check, and, if necessary REGION with the Google Cloud region of the backend service, the health check, or both.
- To change the health check for an internal passthrough Network Load Balancer: An internal passthrough Network Load Balancer's backend service is regional. It can reference a global or regional health check. The following example shows a regional health check reference. If you're using a global health check with your internal passthrough Network Load Balancer, use --global-health-checks instead of --health-checks-region.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
- To change the health check for a backend service-based external passthrough Network Load Balancer: An external passthrough Network Load Balancer's backend service is regional. It can reference a regional health check.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```
- To change the health check for a global external proxy Network Load Balancer, an external Application Load Balancer, or a cross-region internal Application Load Balancer: Both the backend service and health check are global for these load balancers. An external Application Load Balancer or a cross-region internal Application Load Balancer might reference more than one health check if it references more than one backend service.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --global \
    --health-checks HEALTH_CHECK_NAME \
    --global-health-checks
```
- To change the health check for either a regional external Application Load Balancer, a regional external proxy Network Load Balancer, a regional internal proxy Network Load Balancer, or a regional internal Application Load Balancer: Both the backend service and health check are regional. Some load balancers might reference more than one health check if they can reference more than one backend service.
```
gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION
```

API

You can list backend services with the backendServices.list API call.
View health checks.
To associate a health check with a backend service, use one of these API calls:
- backendServices.update
- backendServices.patch

Legacy health checks for target pool-based external passthrough Network Load Balancer

This section describes how to associate a legacy health check with a target pool-based external passthrough Network Load Balancer. This section assumes that you have already:

Created a target pool-based external passthrough Network Load Balancer.
Created a legacy health check.
Configured the firewall rules for external passthrough Network Load Balancers.

To associate a legacy health check with a new external passthrough Network Load Balancer, refer to Set up an external passthrough Network Load Balancer with a target pool. You must associate a legacy health check with its target pool when you create an external passthrough Network Load Balancer.

Console

To associate a health check with an existing target pool-based external passthrough Network Load Balancer:

Go to the Load balancing page in the Google Cloud console.
Go to the Load balancing page
Click on an external passthrough Network Load Balancer to view its details.
Click Edit , and then click Backend configuration.
Choose a legacy health check from the Health check menu. (Only eligible legacy health checks are shown.)
Click Update.

gcloud

To associate a health check with an existing target pool-based external passthrough Network Load Balancer:

Identify the target pool(s). An external passthrough Network Load Balancer has at least one target pool, and might have a secondary backup pool.
```
gcloud compute target-pools list
```
Identify a legacy health check using the HTTP protocol. View legacy health checks if necessary.
Associate the legacy health check with the target pool(s). In the following commands, replace TARGET_POOL_NAME with the name of the target pool, REGION with its region, and LEGACY_CHECK_NAME with the name of the legacy health check. The legacy health check must use the HTTP protocol.
- To remove a legacy HTTP health check from a target pool:
```
gcloud compute target-pools remove-health-checks TARGET_POOL_NAME \
    --region=REGION \
    --http-health-check LEGACY_CHECK_NAME
```
- To add a legacy HTTP health check to a target pool:
```
gcloud compute target-pools add-health-checks TARGET_POOL_NAME \
    --region=REGION \
    --http-health-check LEGACY_CHECK_NAME
```

API

You can list target pools with the targetPools.list API call.
View legacy health checks and identify a legacy HTTP health check.
To associate a legacy HTTP health check with a target pool use the API call targetPools.addHealthCheck.

Checking health check status

After you associate a health check with a backend service or a target pool, you can get the instantaneous health check state for the load balancer's backends.

Console

Go to the load balancing summary page.
Go to the Load balancing page
Click the name of a load balancer.
Under Backend, inspect the Healthy column. Health status is reported for each backend instance group or network endpoint group.

gcloud

For all load balancers except target pool-based external passthrough Network Load Balancers, identify the name and scope (global or regional) of the backend service. For a complete list of load balancers and scopes, see Backend services.

Use the compute backend-services get-health command, replacing NAME with the name of the backend service, and REGION with its region, if required.
- To get the instantaneous health state of a global backend service:
```
gcloud compute backend-services get-health GLOBAL_BACKEND_SERVICE_NAME \
    --global
```
- To get the instantaneous health state of a regional backend service:
```
gcloud compute backend-services get-health REGIONAL_BACKEND_SERVICE_NAME \
    --region=REGION
```
For target pool-based external passthrough Network Load Balancers, identify the name and region of the load balancer's target pool, and then use the compute target-pools get-health command, replacing NAME with the name of the target pool, and REGION with its region.
```
gcloud compute target-pools get-health TARGET_POOL_NAME \
    --region=REGION
```

API

For all load balancers except target pool-based external passthrough Network Load Balancers, identify the name and scope (global or regional) of the backend service. For a complete list of load balancers and scopes, see Backend services.
- To get the instantaneous health state of a global backend service, use backendServices.getHealth
- To get the instantaneous health state of a regional backend service, use regionBackendServices.getHealth
For target pool-based external passthrough Network Load Balancers, use targetPools.getHealth