Creating 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:

• Google Cloud firewall rules
• Health checks overview
• Backend services overview

Note: This page describes how to create a specific load balancer component before or after you've already created a load balancer. Working with specific components is useful for advanced configurations and necessary for some configuration options. Before using the information on this page, know the type of Google Cloud load balancer that you need.

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 Network Load Balancing requires 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

Note: The Google Cloud console lists both health checks and legacy health checks on its health checks page.

1. Go to the Health checks page in the Google Cloud console.
   Go to the Health checks page
2. 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.

Note: You must use legacy HTTP health checks for target pool based-network load balancers. You can select or create a legacy health check when you complete the network load balancer's configuration in the Google Cloud console. Instead of this section, see legacy health checks. Backend service-based network load balancers use the non-legacy health checks described in this section.

Console

1. Go to the Health checks page in the Google Cloud console.
   Go to the Health checks page
2. Click Create a health check.
3. 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.
4. 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 HTTP(S) load balancers and internal HTTP(S) load balancers use global health checks (--global). Internal HTTP(S) 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.

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

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

gcloud

1. Identify the name and scope of the health check. For instructions, see Listing health checks.

2. 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

1. Identify the name and scope of the health check. See Listing health checks for instructions.

2. 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, managed zonal instance groups, or managed regional instance groups.

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

Product	Backend type	Port specification options
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 a network load balancer because backend services for network load balancers lack a port specification.
Internal TCP/UDP 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 TCP/UDP load balancer because backend services for internal TCP/UDP load balancers lack a port specification.
Internal HTTP(S) load balancer External TCP proxy load balancer Internal regional TCP proxy load balancer (Preview) External SSL proxy load balancer Global external HTTP(S) load balancer Regional external HTTP(S) 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.

Important: Google Cloud gRPC health checks don't support authentication and encryption (TLS). This means that VMs can pass gRPC health checks but trigger HTTP 502s when a load balancer sends requests to those VMs. As a workaround, consider using TCP-based health checks for gRPC VMs that are behind a load balancer.

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 HTTP(S) load balancer and the global external HTTP(S) load balancer (classic) 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 network load balancers require legacy HTTP health checks to determine the health of instances in the target pool. A target pool-based network load balancer can only use a legacy HTTP health check, not a legacy HTTPS health check. Backend service-based network load balancers use non-legacy health checks.

Listing legacy health checks

Console

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

gcloud

1. 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
   

2. 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

1. To list legacy health checks:

   • Use httpHealthChecks.list to list legacy HTTP health checks.

   • Use httpsHealthChecks.list to list legacy HTTPS health checks.

2. 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 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 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

Modifying legacy health checks

Console

1. Go to the Health checks page in the Google Cloud console.
   Go to the Health checks page
2. Click on a health check to view its details.
3. 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:

• Internal TCP/UDP load balancer
• Internal HTTP(S) load balancer
• External TCP proxy load balancer
• Internal regional TCP proxy load balancer (Preview)
• External SSL proxy load balancer
• Global external HTTP(S) load balancer
• Regional external HTTP(S) load balancer

For these load balancers, the source IP ranges for health checks (including legacy health checks if used for HTTP(S) Load Balancing) are:

• 35.191.0.0/16
• 130.211.0.0/22

If you need to create rules for Network Load Balancing, refer to the next section, Rules for Network Load Balancing.

Console

1. Go to the Firewall page in the Google Cloud console.
   Go to the Firewall page
2. Click Create firewall rule.
3. 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.
4. 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

1. 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

2. 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.

Rules for Network Load Balancing

The following example creates an ingress firewall rule for Network Load Balancing.

For 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 network load balancers: target pool-based network load balancer that use legacy health checks, and backend service-based network load balancer that use non-legacy health checks.

Note: Target pool-based network load balancers might proxy health checks through the metadata server. In this case, health check packet sources match the IP address of the metadata server: 169.254.169.254. You don't have to create firewall rules to permit traffic from the metadata server. Packets from the metadata server are always allowed.

Console

1. Go to the Firewall page in the Google Cloud console.
   Go to the Firewall page
2. Click Create firewall rule.
3. 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.
4. 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

1. 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

2. 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 TCP/UDP Load Balancing, you can only use TCP or UDP for the backend service's protocol. If you serve HTTP traffic from VMs behind an internal TCP/UDP load balancer, it makes sense to employ a health check using the HTTP protocol.

• A target pool-based 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 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 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 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.

Health checks for backend services

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

• Internal TCP/UDP load balancer
• Internal HTTP(S) load balancer
• External TCP proxy load balancer
• Internal regional TCP proxy load balancer (Preview)
• External SSL proxy load balancer
• External HTTP(S) load balancer
• Backend service-based network load balancer

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 network load balancer, see Firewall rules for Network Load Balancing.

To associate a health check with a new internal TCP/UDP load balancer, external TCP proxy load balancer, external SSL proxy load balancer, external HTTP(S) load balancer, or backend service-based network load balancer, refer to the setup guide for the respective load balancer.

Console

To associate a health check with an existing load balancer:

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

gcloud

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

1. Identify the name and scope of the backend service. A network load balancer, internal TCP/UDP load balancer, internal regional TCP proxy load balancer, external TCP proxy load balancer and external SSL proxy load balancer have only one backend service per load balancer. The external HTTP(S) load balancers and internal HTTP(S) load balancers have one or more backend services associated with a single URL map.

   • To list backend services for internal TCP/UDP 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 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 external TCP proxy load balancers, run the following command. Backend services for external TCP proxy load balancers are always global, regardless of the Network Service Tier.

     gcloud compute backend-services list \
         --global \
         --filter="loadBalancingScheme=EXTERNAL" \
         --filter="protocol=TCP"
     

   • To list backend services for internal regional TCP proxy 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 SSL proxy load balancers, run the following command. Backend services for external SSL proxy 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 a external HTTP(S) load balancer, first identify a URL map, and then describe the map. URL maps and backend services for external HTTP(S) load balancer are always global, regardless of the Network Service Tier. Replace URL_MAP_NAME with the name of the URL map. The backend service(s) 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 HTTP(S) load balancer or an internal HTTP(S) load balancer, first identify a URL map, and then describe the map. URL maps and backend services for internal HTTP(S) 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 service(s) 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
     

2. Identify a health check. See Listing health checks.

3. 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 TCP/UDP load balancer: An internal TCP/UDP 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 TCP/UDP 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 an internal regional TCP proxy load balancer: Both the backend service and the health check are regional.

     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 network load balancer: A 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 an external TCP proxy load balancer, an external SSL proxy load balancer, or an external HTTP(S) load balancer: Both the backend service and health check are global for these load balancers. An external HTTP(S) 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 HTTP(S) load balancer or an internal HTTP(S) load balancer: Both the backend service and health check are regional. An internal HTTP(S) 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 \
         --region=REGION \
         --health-checks=HEALTH_CHECK_NAME \
         --health-checks-region=REGION
     

API

1. You can list backend services with the backendServices.list API call.

2. View health checks.

3. 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 Network Load Balancing

This section describes how to associate a legacy health check with a target pool for Network Load Balancing. This section assumes that you have already:

• Created a target pool-based network load balancer.
• Created a legacy health check.
• Configured the firewall rules for Network Load Balancing.

To associate a legacy health check with a new network load balancer, refer to Setting Up Network Load Balancing with a target pool. You must associate a legacy health check with its target pool when you create a network load balancer.

Console

To associate a health check with an existing target pool-based network load balancer:

1. Go to the Load balancing page in the Google Cloud console.
   Go to the Load balancing page
2. Click on a network load balancer to view its details.
3. Click Edit , and then click Backend configuration.
4. Choose a legacy health check from the Health check menu. (Only eligible legacy health checks are shown.)
5. Click Update.

gcloud

To associate a health check with an existing target pool-based network load balancer:

1. Identify the target pool(s). A network load balancer has at least one target pool, and might have a secondary backup pool.

   gcloud compute target-pools list
   

2. Identify a legacy health check using the HTTP protocol. View legacy health checks if necessary.

3. 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

1. You can list target pools with the targetPools.list API call.

2. View legacy health checks and identify a legacy HTTP health check.

3. 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

1. Go to the load balancing summary page.
   Go to the Load balancing page
2. Click the name of a load balancer.
3. 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 network load balancers, identify the name and scope of the backend service. Backend service-based network load balancers, internal TCP/UDP load balancers, regional external HTTP(S) load balancers and internal HTTP(S) load balancers use regional backend services. The external TCP proxy load balancer, external SSL proxy load balancer, and external HTTP(S) load balancer use global 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 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 network load balancers, identify the name and scope of the backend service. Backend service-based network load balancers, internal TCP/UDP load balancers, regional external HTTP(S) load balancers and internal HTTP(S) load balancers use regional backend services. The external TCP proxy load balancer, external SSL proxy load balancer, and external HTTP(S) load balancer use global 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 network load balancers, use targetPools.getHealth