Google Cloud (Google Cloud) provides health checking mechanisms that determine whether VM instances respond properly to traffic. This document describes how to create and use health checks for load balancers.
This page assumes that you are familiar with Health Check Concepts and that you have an understanding of Google Cloud firewall rules.
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.
Most load balancers use non-legacy health checks, but Network Load Balancing requires that you use legacy health checks. Refer to Selecting a health check on the Health Checks Concepts 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.
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 Cloud Console.
You can also create a health check independently of load balancer configuration
in the 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 Cloud Console,
the gcloud
command-line tool, or the REST APIs. After reviewing the
background information in this section, continue to
Creating and modifying health checks
for instructions.
Network load balancers must use legacy health checks, which you can create or
select when you complete the network load balancer's backend configuration
in the Cloud Console. To create a legacy health check independently,
you must use either the gcloud
command-line tool or the REST APIs. Refer to
legacy health checks for more information.
Flags used by all health checks
The following flags are common to all health checks, regardless of protocol:
gcloud compute health-checks create PROTOCOL HEALTH_CHECK_NAME \ --description=DESCRIPTION \ --check-interval=CHECK_INTERVAL \ --timeout=TIMEOUT \ --healthy-threshold=HEALTHY_THRESHOLD \ --unhealthy-threshold=UNHEALTHY_THRESHOLD \ ...additional flags
Where:
- PROTOCOL defines the protocol used for the health check. Valid
options are
http
,https
,http2
,ssl
, andtcp
. - HEALTH_CHECK_NAME is the name of the health check. Within a given project, each health check must have a unique name.
- 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
. - ...additional flags are other flags for specifying ports and options specific to the PROTOCOL. These flags are discussed in the following sections.
Port specification flags
In addition to a protocol, you must specify a port for a health check. The way you specify the port depends on the type of load balancer and the type of backends used by its backend service. The following table shows port specification options for valid load balancer and backend combinations. As used in the table, the term instance group refers to unmanaged instance groups, managed zonal instance groups, or managed regional instance groups.
Health checks can only use one type of port specification.
Load balancer | Backend type | Port specification |
---|---|---|
Internal TCP/UDP Load Balancing | Instance Groups | Use one of these options1: • --port : Specify a port by number, from 1 to
65535 • --port-name : Specify any named port exported by an instance
groupYou cannot use the --use-serving-port flag for a health
check associated with an internal load balancer because backend services
for internal load balancers lack a port specification of any kind.
|
Internal HTTP(S) Load Balancing TCP Proxy Load Balancing SSL Proxy Load Balancing HTTP(S) Load Balancing |
Network Endpoint Groups | Use one of these options1: • --port : Specify a port by number, from 1 to
65535 • --use-serving-port 2
: Use the port specified by each endpoint in the network endpoint
group. |
Instance Groups | Use one of these options1: • --port : Specify a port by number, from 1 to
65535 • --port-name : Specify any named port exported by an instance
group• --use-serving-port 2
: Use the same instance group named port that the backend service
is configured to use.
|
- If
--use-serving-port
is specified, neither--port
nor--port-name
can be specified. - If both
--port
and--port-name
are specified,--port
prevails. - If none of the three is specified, the default is:
--port=80
gcloud
commands if you need --use-serving-port
:
Optional 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 a 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 hc-http-port-80 \ --description="Simple HTTP port 80 health check" \ --check-interval=5s \ --timeout=5s \ --healthy-threshold=2 \ --unhealthy-threshold=2 \ --port=80 \ --host=HOST \ --proxy-header=PROXY_HEADER \ --request-path=REQUEST_PATH \ --response=RESPONSE
- The protocol can be
http
(in this example),https
, orhttp2
. - 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
orPROXY_V1
. If omitted, Google Cloud usesNONE
. The value ofPROXY_V1
adds the headerPROXY 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.
Optional 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 \ --description="Health check: TCP 3268" \ --check-interval=5s \ --timeout=5s \ --healthy-threshold=2 \ --unhealthy-threshold=2 \ --port=3268 \ --proxy-header=PROXY_HEADER \ --request=REQUEST_STRING \ --response=RESPONSE_STRING
- The protocol can be
tcp
(in this example) orssl
. - PROXY_HEADER must be one of
NONE
orPROXY_V1
. If omitted, Google Cloud usesNONE
. The value ofPROXY_V1
adds the headerPROXY 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.
Creating and modifying health checks
You cannot convert a health check to a legacy health check, or vice versa, by modifying it.
Console
The Cloud Console lists both health checks and legacy health checks. You can edit existing health checks and legacy health checks; however, you cannot create a legacy health check on the health checks page in the Cloud Console.
To create a health check:
- 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.
- Protocol: Choose a health check protocol.
- Port: Provide 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. Refer to optional flags for HTTP, HTTPS, and HTTP/2 health checks for more information.
- Request and Response: For TCP and SSL protcols, you can specify an ASCII text string to send and expected text response string. Refer to optional flags for SSL and TCP health checks for more information.
- Check interval: Defines the amount of time from the start of one probe to the start of the next one.
- Timeout: Defines the amount of time that Google Cloud will wait for a response to a probe. Its value must be less than or equal to the check interval.
- Healthy threshold: Defines the number of sequential probes that must succeed for the VM instance to be considered healthy.
- Unhealthy threshold: Defines the number of sequential probes that must fail for the VM instance to be considered unhealthy.
- Click Create.
To edit a health check:
- 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.
- If you need to modify the health check, click Edit, then:
- Make changes to the parameters as necessary.
- Click Save.
gcloud
Use the following
gcloud
commands to list health checks:gcloud compute health-checks list
Identify a health check, then describe it using the appropriate
gcloud
command, replacing HEALTH_CHECK_NAME with its name.gcloud compute health-checks describe HEALTH_CHECK_NAME
To modify the health check, use the appropriate
gcloud
command, replacing HEALTH_CHECK_NAME with its name. Except for the health check name and protocol, you can modify any of the common flags, the port specification flags, and optional flags. When you modify an existing health check with thegcloud compute health-checks update
command, preconfigured settings are preserved for flags that you omit. The following command modifies an example health check by changing its check interval, timeout, and request path:gcloud compute health-checks update http hc-http-port-80 \ --check-interval=20s \ --timeout=15s \ --request-path="/health"
API
You can list health checks with the healthChecks.list API call.
If you know the name of a health check, you can get its configuration details with the healthChecks.get API call.
If you need to modify a health check, use these API calls:
Legacy health checks
Creating legacy health checks
This section describes how to create legacy health checks which are required by network load balancers.
Console
Although the Cloud Console's health checks page lists both health checks and legacy health checks, you cannot create a legacy health check on the Cloud Console. You can only create a legacy health check using the Cloud Console's network load balancer page.
gcloud
Use the following gcloud
command to create a legacy health check for a
network load balancer:
gcloud compute LEGACY_CHECK_TYPE create LEGACY_HEALTH_CHECK_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
Where:
- LEGACY_CHECK_TYPE is
http-health-checks
for a legacy HTTP health check orhttps-health-checks
for a legacy HTTPS health check. If you are creating the legacy health check for a network load balancer, you must usehttp-health-checks
. - LEGACY_HEALTH_CHECK_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
You can create a legacy health check using this API call for a network load balancer:
Viewing and modifying legacy health checks
Console
The Cloud Console lists both health checks and legacy health checks on the health checks page. To edit an existing legacy health check:
- 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.
- If you need to modify the health check, click Edit, then:
- Make changes to the parameters as necessary.
- Click Save.
gcloud
Use the following
gcloud
commands to list legacy health checks for network load balancers.gcloud compute http-health-checks list
Identify a legacy health check, then describe it using the appropriate
gcloud
command, replacing LEGACY_HEALTH_CHECK_NAME with its name.gcloud compute http-health-checks describe LEGACY_HEALTH_CHECK_NAME
If you need to modify a legacy health check, use the appropriate
gcloud
command, replacing LEGACY_HEALTH_CHECK_NAME with its name. When modifying a health check withgcloud
, existing settings for the flags you omit are preserved.gcloud compute http-health-checks update LEGACY_HEALTH_CHECK_NAME \ ...other options
Where the ...other options are the options for creating a legacy health check.
API
Use the following API call to list legacy health checks for network load balancers.
If you know the name of a legacy health check, you can get its configuration details with this API call:
If you need to modify a legacy health check, use these API calls:
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.
Rules for health checks
The following example creates an ingress firewall rule for the following load balancers:
- Internal TCP/UDP Load Balancing (health checks)
- Internal HTTP(S) Load Balancing (health checks)
- TCP Proxy Load Balancing (health checks)
- SSL Proxy Load Balancing (health checks)
- HTTP(S) Load Balancing (health checks and legacy health checks)
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
For Internal HTTP(S) Load Balancing only, the source IP range is all the IP addresses in the proxy-only subnet.
If you need to create rules for Network Load Balancing, refer to the next section, Rules for Network Load Balancing.
Console
- Go to the Firewall rules page in the Google Cloud Console.
Go to the Firewall rules page - 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, 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
. TCP is the underlying protocol for all health check protocols. - Click Create.
- Name: Provide a name for the rule. For this example, use
- 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 namedfw-allow-health-checks
that allows incoming connections to instances in your network with theallow-health-checks
tag. Replace NETWORK_NAME with the name of your network.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
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, which requires a legacy health check. The source IP ranges for legacy health checks for Network Load Balancing are:
35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
Console
- Go to the Firewall rules page in the Google Cloud Console.
Go to the Firewall rules page - 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, 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.
- Name: Provide a name for the rule. For this example, use
- 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 namedfw-allow-network-lb-health-checks
that allows incoming connections to instances in your network with theallow-network-lb-health-checks
tag. Replace NETWORK_NAME with the name of your 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 with load balancers
Protocols and load balancers
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
orUDP
for the backend service's protocol. If you serve HTTP traffic from VMs behind an internal load balancer, it makes sense to employ a health check using the HTTP protocol.A legacy health check is limited to the HTTP protocol. If you use a 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.
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 Balancing
- Internal HTTP(S) Load Balancing
- TCP Proxy Load Balancing
- SSL Proxy Load Balancing
- HTTP(S) Load Balancing
This section assumes that you have already:
- Created an internal, TCP Proxy, SSL Proxy, or HTTP(S) load balancer.
- Created a health check.
- Configured the firewall rules for health checks.
To associate a health check with a new internal, TCP Proxy, SSL Proxy, or HTTP(S) load balancer, refer to the setup guide for the respective load balancer.
Console
To associate a health check with an existing internal, TCP Proxy, SSL Proxy, or HTTP(S) 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, then click Backend configuration.
- Choose a health check from the Health check menu.
- Click Update.
gcloud
To associate a health check with an existing internal, TCP Proxy, SSL Proxy, or HTTP(S) load balancer:
Identify the backend service or services used by the load balancer. Internal, TCP Proxy, and SSL Proxy load balancers have only one backend service for the whole load balancer. HTTP(S) load balancers have one or more backend services associated with their URL map.
To list backend services for internal TCP/UDP load balancers, run the following command. Identify the name and region of the backend service.
gcloud compute backend-services list \ --filter="loadBalancingScheme=INTERNAL"
To list backend services for internal HTTP(S) load balancers, run the following command. Identify the name and region of the backend service.
gcloud compute backend-services list \ --filter="loadBalancingScheme=INTERNAL_MANAGED"
To list backend services for TCP Proxy load balancers:
gcloud compute backend-services list \ --filter="loadBalancingScheme=EXTERNAL" \ --filter="protocol=TCP"
To list backend services for SSL Proxy load balancers:
gcloud compute backend-services list \ --filter="loadBalancingScheme=EXTERNAL" \ --filter="protocol=SSL"
To identify backend services for HTTP(S) load balancing, identify the URL map, then describe it, replacing URL_MAP_NAME with the name of the URL map. The backend service(s) it uses are listed in the
pathMatchers
section of the response.gcloud compute url-maps list gcloud compute url-maps describe URL_MAP_NAME
Identify a health check. View health checks if necessary.
Associate the health check with the backend service. In the following commands, replace BACKEND_SERVICE_NAME with the name of the backend service and HEALTH_CHECK_NAME with the name of the health check. These commands replace all health checks associated with the backend service. In most cases, you'll have just one health check associated with the backend service.
To change the health check for a backend service for an internal load balancer, use the following command. Backend services for internal load balancers are regional, so you must specify the REGION in addition to its name.
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --region REGION \ --health-checks HEALTH_CHECK_NAME
To change the health check for a backend service for TCP Proxy, SSL Proxy, and HTTP(S) load balancers:
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --global \ --health-checks HEALTH_CHECK_NAME
API
You can list backend services with the backendServices.list API call.
To associate a health check with a backend service use one of these API calls:
Legacy health checks for 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 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. You must associate a legacy health check with its target pool when you create a new network load balancer.
Console
To associate a health check with an existing network load balancer:
- Go to the Load balancing page in the Google Cloud Console.
Go to the Load balancing page - Click on a network load balancer to view its details.
- Click Edit, 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 network load balancer:
Identify the target pool(s). Network load balancers have 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_HEALTH_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_HEALTH_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_HEALTH_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.
Troubleshooting health checks by blocking IP address ranges
Under certain circumstances, it's useful to purposefully fail health checks. You might need to force a particular VM to fail health checks as part of a troubleshooting activity, or you might want to have it fail health checks as part of its shutdown procedure.
You can force a health check or legacy health check to fail by temporarily
blocking access to the health check IP ranges. This example shows you how to
fail health checks using the iptables
firewall software running on a Linux VM.
To cause a VM to fail health check and legacy health check probes, connect to it
and run an iptables
command like the following example, replacing
HEALTH_CHECK_PORT with the appropriate TCP port number. If you need a
VM to purposefully fail probes as it is shutting down, you can add iptables
commands like these to a shutdown script
followed by an appropriate delay based on the health check's check interval and
unhealthy threshold.
$ sudo iptables -I INPUT 1 -m state --state NEW \ -s 35.191.0.0/16 -p tcp --destination-port HEALTH_CHECK_PORT \ -j REJECT --reject-with tcp-reset $ sudo iptables -I INPUT 1 -m state --state NEW \ -s 130.211.0.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \ -j REJECT --reject-with tcp-reset $ sudo iptables -I INPUT 1 -m state --state NEW \ -s 209.85.152.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \ -j REJECT --reject-with tcp-reset $ sudo iptables -I INPUT 1 -m state --state NEW \ -s 209.85.204.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \ -j REJECT --reject-with tcp-reset
To remove the iptables
rules, run the following commands, replacing
HEALTH_CHECK_PORT with the health check's TCP port.
$ sudo iptables -D INPUT -m state --state NEW \ -s 35.191.0.0/16 -p tcp --destination-port HEALTH_CHECK_PORT \ -j REJECT --reject-with tcp-reset $ sudo iptables -D INPUT -m state --state NEW \ -s 130.211.0.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \ -j REJECT --reject-with tcp-reset $ sudo iptables -D INPUT -m state --state NEW \ -s 209.85.152.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \ -j REJECT --reject-with tcp-reset $ sudo iptables -D INPUT -m state --state NEW \ -s 209.85.204.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \ -j REJECT --reject-with tcp-reset