Health checks for Application Load Balancer target groups
Your Application Load Balancer periodically sends requests to its registered targets to test their status. These tests are called health checks.
Each load balancer node routes requests only to the healthy targets in the enabled Availability Zones for the load balancer. Each load balancer node checks the health of each target, using the health check settings for the target groups with which the target is registered. After your target is registered, it must pass one health check to be considered healthy. After each health check is completed, the load balancer node closes the connection that was established for the health check.
If a target group contains only unhealthy registered targets, the load balancer routes requests to all those targets, regardless of their health status. This means that if all targets fail health checks at the same time in all enabled Availability Zones, the load balancer fails open. The effect of the fail-open is to allow traffic to all targets in all enabled Availability Zones, regardless of their health status, based on the load balancing algorithm.
Health checks do not support WebSockets.
Health check settings
You configure health checks for the targets in a target group as described in the following table. The setting names used in the table are the names used in the API. The load balancer sends a health check request to each registered target every HealthCheckIntervalSeconds seconds, using the specified port, protocol, and health check path. Each health check request is independent and the result lasts for the entire interval. The time that it takes for the target to respond does not affect the interval for the next health check request. If the health checks exceed UnhealthyThresholdCount consecutive failures, the load balancer takes the target out of service. When the health checks exceed HealthyThresholdCount consecutive successes, the load balancer puts the target back in service.
| Setting | Description |
|---|---|
HealthCheckProtocol |
The protocol the load balancer uses when performing health checks on targets. For Application Load Balancers the possible protocols are HTTP and HTTPS. The default is the HTTP protocol. These protocols use the HTTP GET method to send health check requests. |
HealthCheckPort |
The port the load balancer uses when performing health checks on targets. The default is to use the port on which each target receives traffic from the load balancer. |
HealthCheckPath |
The destination for health checks on the targets. If the protocol version is HTTP/1.1 or HTTP/2, specify a valid URI (/path?query). The default is /. If the protocol version is gRPC, specify the path of a custom
health check method with the format
|
HealthCheckTimeoutSeconds |
The amount of time, in seconds, during which no response from a
target means a failed health check. The range is 2–120
seconds. The default is 5 seconds if the target type is
|
HealthCheckIntervalSeconds |
The approximate amount of time, in seconds, between health checks
of an individual target. The range is 5–300 seconds. The
default is 30 seconds if the target type is |
HealthyThresholdCount |
The number of consecutive successful health checks required before considering an unhealthy target healthy. The range is 2–10. The default is 5. |
UnhealthyThresholdCount |
The number of consecutive failed health checks required before considering a target unhealthy. The range is 2–10. The default is 2. |
Matcher |
The codes to use when checking for a successful response from a target. These are called Success codes in the console. If the protocol version is HTTP/1.1 or HTTP/2, the possible values are from 200 to 499. You can specify multiple values (for example, "200,202") or a range of values (for example, "200-299"). The default value is 200. If the protocol version is gRPC, the possible values are from 0 to 99. You can specify multiple values (for example, "0,1") or a range of values (for example, "0-5"). The default value is 12. |
Target health status
Before the load balancer sends a health check request to a target, you must register
it with a target group, specify its target group in a listener rule, and ensure that the
Availability Zone of the target is enabled for the load balancer. Before a target can
receive requests from the load balancer, it must pass the initial health checks. After a
target passes the initial health checks, its status is Healthy.
The following table describes the possible values for the health status of a registered target.
| Value | Description |
|---|---|
|
The load balancer is in the process of registering the target or performing the initial health checks on the target. Related reason codes: |
|
The target is healthy. Related reason codes: None |
|
The target did not respond to a health check or failed the health check. Related reason codes: |
|
The target is not registered with a target group, the target group is not used in a listener rule, the target is in an Availability Zone that is not enabled, or the target is in the stopped or terminated state. Related reason codes: |
|
The target is deregistering and connection draining is in process. Related reason code:
|
|
Health checks are disabled for the target group. Related reason code:
|
Health check reason codes
If the status of a target is any value other than Healthy, the API
returns a reason code and a description of the issue, and the console displays the same
description. Reason codes that begin with Elb originate on the load
balancer side and reason codes that begin with Target originate on the
target side. For more information about possible causes for health check failures, see
Troubleshooting.
| Reason code | Description |
|---|---|
|
Initial health checks in progress |
|
Health checks failed due to an internal error |
|
Target registration is in progress |
|
Target deregistration is in progress |
|
Health checks failed |
|
Health checks are disabled |
|
Target is in the stopped state Target is in the terminated state Target is in the terminated or stopped state Target is in an invalid state |
|
The IP address cannot be used as a target, as it is in use by a load balancer |
|
Target group is not configured to receive traffic from the load balancer Target is in an Availability Zone that is not enabled for the load balancer |
|
Target is not registered to the target group |
|
Health checks failed with these codes: [code] |
|
Request timed out |
