Health checks for your target groups
You register your targets with one or more target groups. The load balancer starts routing requests to a newly registered target as soon as the registration process completes. It can take a few minutes for the registration process to complete and health checks to start.
Network Load Balancers use active and passive health checks to determine whether a target is available to handle requests. By default, each load balancer node routes requests only to the healthy targets in its Availability Zone. If you enable cross-zone load balancing, each load balancer node routes requests to the healthy targets in all enabled Availability Zones. For more information, see Cross-zone load balancing.
With passive health checks, the load balancer observes how targets respond to connections. Passive health checks enable the load balancer to detect an unhealthy target before it is reported as unhealthy by the active health checks. You cannot disable, configure, or monitor passive health checks. Passive health checks are not supported for UDP traffic, and target groups with stickiness turned on. For more information, see Sticky sessions.
If a target becomes unhealthy, the load balancer sends a TCP RST for packets received on the client connections associated with the target, unless the unhealthy target triggers the load balancer to fail open.
If target groups don't have a healthy target in an enabled Availability Zone, we remove the IP address for the corresponding subnet from DNS so that requests cannot be routed to targets in that Availability Zone. 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.
If a target group is configured with HTTPS health checks, its registered targets fail health checks if they support only TLS 1.3. These targets must support an earlier version of TLS, such as TLS 1.2.
For HTTP or HTTPS health check requests, the host header contains the IP address of the load balancer node and the listener port, not the IP address of the target and the health check port.
If you add a TLS listener to your Network Load Balancer, we perform a listener connectivity test. As TLS termination also terminates a TCP connection, a new TCP connection is established between your load balancer and your targets. Therefore, you might see the TCP connections for this test sent from your load balancer to the targets that are registered with your TLS listener. You can identify these TCP connections because they have the source IP address of your Network Load Balancer and the connections do not contain data packets.
For a UDP service, target availability can be tested using non-UDP health checks on your target group. You can use any available health check (TCP, HTTP, or HTTPS), and any port on your target to verify the availability of a UDP service. If the service receiving the health check fails, your target is considered unavailable. To improve the accuracy of health checks for a UDP service, configure the service listening to the health check port to track the status of your UDP service and fail the health check if the service is unavailable.
Health check settings
You configure active health checks for the targets in a target group using the following settings. 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 | Default |
|---|---|---|
|
HealthCheckProtocol |
The protocol the load balancer uses when performing health checks
on targets. The possible protocols are HTTP, HTTPS, and TCP. The
default is the TCP protocol. If the target type is |
TCP |
|
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. |
Port on which each target receives traffic from the load balancer. |
|
HealthCheckPath |
[HTTP/HTTPS health checks] The health check path that is the destination on the targets for health checks. The default is /. |
/ |
|
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 values are 6 seconds for HTTP and 10 seconds for TCP and HTTPS health checks. |
6 seconds for HTTP health checks and 10 seconds for TCP and HTTPS health checks. |
|
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. ImportantHealth checks for a Network Load Balancer are distributed and use a consensus mechanism to determine target health. Therefore, targets receive more than the configured number of health checks. To reduce the impact to your targets if you are using HTTP health checks, use a simpler destination on the targets, such as a static HTML file, or switch to TCP health checks. |
30 seconds |
|
HealthyThresholdCount |
The number of consecutive successful health checks required before considering an unhealthy target healthy. The range is 2–10. The default is 5. |
5 |
|
UnhealthyThresholdCount |
The number of consecutive failed health checks required before considering a target unhealthy. The range is 2–10. The default is 2. |
2 |
|
Matcher |
[HTTP/HTTPS health checks] The HTTP codes to use when checking for a successful response from a target. The range is 200 to 599. The default is 200-399. |
200-399 |
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.
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, failed the health check, or the target is in stopped state. Related reason code: |
|
The target is deregistering and connection draining is in process. Related reason code:
|
|
The target did not respond to health checks or failed the health checks and enters a grace period. The target supports existing connections and will not accept any new connections during this grace period. Related reason code:
|
|
Target health is unavailable. Related reason code: |
|
The target is not registered with a target group, the target group is not used in a listener rule, or the target is in an Availability Zone that is not enabled. Related reason codes: |
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 in a tooltip. Note that reason codes that begin with Elb
originate on the load balancer side and reason codes that begin with Target
originate on the target side.
| 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 |
|
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 |
Check the health of your targets
You can check the health status of the targets registered with your target groups.
To check the health of your targets using the Amazon CLI
Use the describe-target-health command. The output of this command contains the
target health state. It includes a reason code if the status is any value other than
Healthy.
To receive email notifications about unhealthy targets
Use CloudWatch alarms to trigger a Lambda function to send details about unhealthy
targets. For step-by-step instructions, see the following blog post: Identifying unhealthy targets of your load balancer
Modify the health check settings of a target group
You can modify the health check settings for your target group at any time.
To modify health check settings for a target group using the Amazon CLI
Use the modify-target-group command.