Google cloud loadbalancer health checks cause a load on servers

I have configured a load balancer https on google cloud with a health check having following parameters:

healthcheck :

Interval : 30 seconds
Timeout : 15 seconds
Healthy threshold:  1 success
Unhealthy threshold : 2 consecutive failures

I have noticed that the health check cause a lot of requests and the server scale to 6VM without a real traffic from user. Is the health check cause an internal traffic wich slow the server?

Possible causes of unhealhy or failing heath check:

• Firewall rules are blocking access for source IP ranges for health checks
• Instance is not listening on the destination port
• Guest Environment is not installed

1. Confirm Firewall Rules are allowing the source IP ranges for health checks to connect to instances: Rules for health checks
2. Ensure you can telnet to port used for health checking from another instance in the same network:
   telnet <instance-ip> <dst-port>
3. Ensure TCP segments from IP ranges for health checks are reaching the instance:
   tcpdump -i any -ttn 'host <ilb-ip> and (net 130.211.0.0/22 or net 35.191.0.0/16)'
4. Ensure the Guest Environment is installed so the NIC is configured to listen on the ILB IP address: Validating the guest environment

Kindly refer on link below:
What makes a good autohealing health check
Importance of firewall rules

With these settings, the health check behaves as follows:

Interval : 30 seconds
Timeout : 15 seconds
Healthy threshold:  1 success
Unhealthy threshold : 2 consecutive failures

1. Multiple redundant systems are simultaneously configured with the health check parameters. Interval and timeout settings are applied to each system.

2. Each health check prober does the following:

2a. Initiates an HTTP connection from one of the source IP addresses to the backend instance every 30 seconds.

2b. Waits up to fifteen seconds for an HTTP 200 (OK) response code.

3. A backend is considered unhealthy when at least one health check probe system does the following:

3a. Does not receive an HTTP 200 (OK) response code for one probes. For example, the connection might be refused, or there might be a connection or socket timeout.

3b. Receives two consecutive responses that don't match the protocol-specific success criteria.

4. A backend is considered healthy when at least one health check probe system receives one responses that match the protocol-specific success criteria.

In this example, each prober initiates a connection every 30 seconds. Thirty seconds elapses between a prober's connection attempts regardless of the duration of the timeout (whether or not the connection timed out). In other words, the timeout must always be less than or equal to the interval, and the timeout never increases the interval.*

In this example, each prober's timing looks like the following, in seconds:

t=0: Start probe A.

t=15: Stop probe A.

t=30: Start probe B.

t=45: Stop probe B.

t=60: Start probe C.

t=75: Stop probe C.

Health checks determine if backends respond to traffic.

I suggest you change these values to :

Timeout : 5 seconds

Healthy threshold: 2 success