# Target groups for your Network Load Balancers Target groups Each *target group* is used to route requests to one or more registered targets. When you create a listener, you specify a target group for its default action. Traffic is forwarded to the target group specified in the listener rule. You can create different target groups for different types of requests. For example, create one target group for general requests and other target groups for requests to the microservices for your application. For more information, see [Network Load Balancer components](introduction.md#network-load-balancer-components). You define health check settings for your load balancer on a per target group basis. Each target group uses the default health check settings, unless you override them when you create the target group or modify them later on. After you specify a target group in a rule for a listener, the load balancer continually monitors the health of all targets registered with the target group that are in an Availability Zone enabled for the load balancer. The load balancer routes requests to the registered targets that are healthy. For more information, see [Health checks for Network Load Balancer target groups](target-group-health-checks.md). **Topics** + [ ## Routing configuration ](#target-group-routing-configuration) + [ ## Target type ](#target-type) + [ ## IP address type ](#target-group-ip-address-type) + [ ## Registered targets ](#registered-targets) + [ ## Target group attributes ](#target-group-attributes) + [ ## Target group health ](#target-group-health) + [Create a target group](create-target-group.md) + [Update health settings](modify-target-group-health-settings.md) + [Configure health checks](target-group-health-checks.md) + [Edit target group attributes](edit-target-group-attributes.md) + [Register targets](target-group-register-targets.md) + [Use Application Load Balancers as targets](application-load-balancer-target.md) + [Tag a target group](target-group-tags.md) + [Delete a target group](delete-target-group.md) ## Routing configuration By default, a load balancer routes requests to its targets using the protocol and port number that you specified when you created the target group. Alternatively, you can override the port used for routing traffic to a target when you register it with the target group. Target groups for Network Load Balancers support the following protocols and ports: + **Protocols**: TCP, TLS, UDP, TCP\$1UDP, QUIC, TCP\$1QUIC + **Ports**: 1-65535 If a target group is configured with the TLS protocol, the load balancer establishes TLS connections with the targets using certificates that you install on the targets. The load balancer does not validate these certificates. Therefore, you can use self-signed certificates or certificates that have expired. Because the load balancer is in a virtual private cloud (VPC), traffic between the load balancer and the targets is authenticated at the packet level, so it is not at risk of man-in-the-middle attacks or spoofing even if the certificates on the targets are not valid. The following table summarizes the supported combinations of listener protocol and target group settings. | Listener protocol | Target group protocol | Target group type | Health check protocol | | --- | --- | --- | --- | | TCP | TCP \$1 TCP\$1UDP \$1 TCP\$1QUIC | instance \$1 ip | HTTP \$1 HTTPS \$1 TCP | | TCP | TCP | alb | HTTP \$1 HTTPS | | TLS | TCP \$1 TLS | instance \$1 ip | HTTP \$1 HTTPS \$1 TCP | | UDP | UDP \$1 TCP\$1UDP | instance \$1 ip | HTTP \$1 HTTPS \$1 TCP | | TCP\$1UDP | TCP\$1UDP | instance \$1 ip | HTTP \$1 HTTPS \$1 TCP | | QUIC | QUIC \$1 TCP\$1QUIC | instance \$1 ip | HTTP \$1 HTTPS \$1 TCP | | TCP\$1QUIC | TCP\$1QUIC | instance \$1 ip | HTTP \$1 HTTPS \$1 TCP | ## Target type When you create a target group, you specify its target type, which determines how you specify its targets. After you create a target group, you can't change its target type. The following are the possible target types: `instance` The targets are specified by instance ID. `ip` The targets are specified by IP address. `alb` The target is an Application Load Balancer. When the target type is `ip`, you can specify IP addresses from one of the following CIDR blocks: + The subnets of the target group VPC + 10.0.0.0/8 ([RFC 1918](https://tools.ietf.org/html/rfc1918)) + 100.64.0.0/10 ([RFC 6598](https://tools.ietf.org/html/rfc6598)) + 172.16.0.0/12 (RFC 1918) + 192.168.0.0/16 (RFC 1918) **Important** You can't specify publicly routable IP addresses. All of the supported CIDR blocks enable you to register the following targets with a target group: + AWS resources that are addressable by IP address and port (for example, databases). + On-premises resources linked to AWS through Direct Connect or a Site-to-Site VPN connection. When client IP preservation is disabled for your target groups, the load balancer can support about 55,000 connections per minute for each combination of Network Load Balancer IP address and unique target (IP address and port). If you exceed these connections, there is an increased chance of port allocation errors. If you get port allocation errors, add more targets to the target group. When launching a Network Load Balancer in a shared VPC (as a participant), you can only register targets in subnets that have been shared with you. When the target type is `alb`, you can register a single Application Load Balancer as a target. For more information, see [Use an Application Load Balancer as a target of a Network Load Balancer](application-load-balancer-target.md). Network Load Balancers do not support the `lambda` target type. Application Load Balancers are the only load balancers that support the `lambda` target type. For more information, see [Lambda functions as targets](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html) in the *User Guide for Application Load Balancers*. If you have microservices on instances that are registered with a Network Load Balancer, you can't use the load balancer to provide communication between them unless the load balancer is internet-facing or the instances are registered by IP address. For more information, see [Connections time out for requests from a target to its load balancer](load-balancer-troubleshooting.md#loopback-timeout). ### Request routing and IP addresses If you specify targets using an instance ID, traffic is routed to instances using the primary private IP address that is specified in the primary network interface for the instance. The load balancer rewrites the destination IP address from the data packet before forwarding it to the target instance. If you specify targets using IP addresses, you can route traffic to an instance using any private IP address from one or more network interfaces. This enables multiple applications on an instance to use the same port. Note that each network interface can have its own security group. The load balancer rewrites the destination IP address before forwarding it to the target. For more information about allowing traffic to your instances, see [Target security groups](target-group-register-targets.md#target-security-groups). ### On premises resources as targets On premises resources linked through Direct Connect or a Site-to-Site VPN connection can serve as a target, when the target type is `ip`. ![\[Connect a Network Load Balancer with on-premises servers using AWS Direct Connect or AWS Site-to-Site VPN.\]](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/images/nlb-on-prem-resources.png) When using on premises resources, the IP addresses of these targets must still come from one of the following CIDR blocks: + 10.0.0.0/8 ([RFC 1918](https://tools.ietf.org/html/rfc1918)) + 100.64.0.0/10 ([RFC 6598](https://tools.ietf.org/html/rfc6598)) + 172.16.0.0/12 (RFC 1918) + 192.168.0.0/16 (RFC 1918) For more information about Direct Connect, see [What is Direct Connect?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/) For more information about AWS Site-to-Site VPN, see [What is AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/) ## IP address type When creating a new target group, you can select the IP address type of your target group. This controls the IP version used to communicate with targets and check their health status. Target groups for your Network Load Balancers support the following IP address types: **`ipv4`** The load balancer communicates with targets using IPv4. **`ipv6`** The load balancer communicates with targets using IPv6. **Considerations** + The load balancer communicates with targets based on the IP address type of the target group. The targets of an IPv4 target group must accept IPv4 traffic from the load balancer and the targets of an IPv6 target group must accept IPv6 traffic from the load balancer. + You can't use an IPv6 target group with an `ipv4` load balancer. + You can't use an IPv4 target group with a UDP listener for a `dualstack` load balancer. + You can't register an Application Load Balancer with an IPv6 target group. + You can't use an IPv6 target group with QUIC or TCP\$1QUIC protocols. ## Registered targets Your load balancer serves as a single point of contact for clients and distributes incoming traffic across its healthy registered targets. Each target group must have at least one registered target in each Availability Zone that is enabled for the load balancer. You can register each target with one or more target groups. If demand on your application increases, you can register additional targets with one or more target groups in order to handle the demand. The load balancer starts routing traffic to a newly registered target as soon as the registration process completes and the target passes the first initial health check, irrespective of the configured threshold. If demand on your application decreases, or if you need to service your targets, you can deregister targets from your target groups. Deregistering a target removes it from your target group, but does not affect the target otherwise. The load balancer stops routing traffic to a target as soon as it is deregistered. The target enters the `draining` state until in-flight requests have completed. You can register the target with the target group again when you are ready for it to resume receiving traffic. If you are registering targets by instance ID, you can use your load balancer with an Auto Scaling group. After you attach a target group to an Auto Scaling group, Auto Scaling registers your targets with the target group for you when it launches them. For more information, see [Attaching a load balancer to your Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html) in the *Amazon EC2 Auto Scaling User Guide*. **Requirements and considerations** + You can't register instances by instance ID if they use one of the following instance types: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3, or T1. + When registering targets by instance ID for a IPv6 target group, the targets must have an assigned primary IPv6 address. To learn more, see [ IPv6 addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing) in the *Amazon EC2 User Guide* + When registering targets by instance ID, instances must be in the same VPC as the Network Load Balancer. You can't register instances by instance ID if they are in an VPC that is peered to the load balancer VPC (same Region or different Region). You can register these instances by IP address. + If you register a target by IP address and the IP address is in the same VPC as the load balancer, the load balancer verifies that it is from a subnet that it can reach. + The load balancer routes traffic to targets only in Availability Zones that are enabled. Targets in zones that are not enabled are unused. + For UDP, TCP\$1UDP, QUIC, and TCP\$1QUIC target groups, do not register instances by IP address if they reside outside of the load balancer VPC or if they use one of the following instance types: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3, or T1. Targets that reside outside the load balancer VPC or use an unsupported instance type might be able to receive traffic from the load balancer but then be unable to respond. ## Target group attributes You can configure a target group by editing its attributes. For more information, see [Edit target group attributes](edit-target-group-attributes.md). The following target group attributes are supported. You can modify these attributes only if the target group type is `instance` or `ip`. If the target group type is `alb`, these attributes always use their default values. `deregistration_delay.timeout_seconds` The amount of time for Elastic Load Balancing to wait before changing the state of a deregistering target from `draining` to `unused`. The range is 0-3600 seconds. The default value is 300 seconds. For QUIC traffic, the value is always 300 seconds. `deregistration_delay.connection_termination.enabled` Indicates whether the load balancer terminates connections at the end of the deregistration timeout. The value is `true` or `false`. For new UDP/TCP\$1UDP target groups the default is `true`. Otherwise, the default is `false`. This attribute does not apply to QUIC traffic. `load_balancing.cross_zone.enabled` Indicates whether cross zone load balancing is enabled. The value is `true`, `false` or `use_load_balancer_configuration`. The default is `use_load_balancer_configuration`. `preserve_client_ip.enabled` Indicates whether client IP preservation is enabled. The value is `true` or `false`. The default is disabled if the target group type is IP address and the target group protocol is TCP or TLS. Otherwise, the default is enabled. Client IP preservation can't be disabled for UDP, TCP\$1UDP, QUIC, and TCP\$1QUIC target groups. `proxy_protocol_v2.enabled` Indicates whether proxy protocol version 2 is enabled. By default, proxy protocol is disabled. `stickiness.enabled` Indicates whether sticky sessions are enabled. The value is `true` or `false`. The default is `false`. This attribute does not apply to QUIC traffic. `stickiness.type` The type of stickiness. The possible value is `source_ip`. `target_group_health.dns_failover.minimum_healthy_targets.count` The minimum number of targets that must be healthy. If the number of healthy targets is below this value, mark the zone as unhealthy in DNS, so that traffic is routed only to healthy zones. The possible values are `off` or an integer from 1 to the maximum number of targets. When `off`, DNS fail away is disabled, meaning that even if all targets in the target group are unhealthy, the zone is not removed from DNS. The default is 1. `target_group_health.dns_failover.minimum_healthy_targets.percentage` The minimum percentage of targets that must be healthy. If the percentage of healthy targets is below this value, mark the zone as unhealthy in DNS, so that traffic is routed only to healthy zones. The possible values are `off` or an integer from 1 to 100. When `off`, DNS fail away is disabled, meaning that even if all targets in the target group are unhealthy, the zone is not removed from DNS. The default is `off`. `target_group_health.unhealthy_state_routing.minimum_healthy_targets.count` The minimum number of targets that must be healthy. If the number of healthy targets is below this value, send traffic to all targets, including unhealthy targets. The possible values are 1 to the maximum number of targets. The default is 1. `target_group_health.unhealthy_state_routing.minimum_healthy_targets.percentage` The minimum percentage of targets that must be healthy. If the percentage of healthy targets is below this value, send traffic to all targets, including unhealthy targets. The possible values are `off` or an integer from 1 to 100. The default is `off`. `target_health_state.unhealthy.connection_termination.enabled` Indicates whether the load balancer terminates connections to unhealthy targets. The value is `true` or `false`. The default is `true`. `target_health_state.unhealthy.draining_interval_seconds` The amount of time for Elastic Load Balancing to wait before changing the state of an unhealthy target from `unhealthy.draining` to `unhealthy`. The range is 0-360000 seconds. The default value is 0 seconds. **Note:** This attribute can only be configured when `target_health_state.unhealthy.connection_termination.enabled` is `false`. ## Target group health By default, a target group is considered healthy as long as it has at least one healthy target. If you have a large fleet, having only one healthy target serving traffic is not sufficient. Instead, you can specify a minimum count or percentage of targets that must be healthy, and what actions the load balancer takes when the healthy targets fall below the specified threshold. This improves the availability of your application. **Topics** + [ ### Unhealthy state actions ](#unhealthy-state-actions) + [ ### Requirements and considerations ](#target-group-health-considerations) + [ ### Example ](#target-group-health-examples) + [ ### Using Route 53 DNS failover for your load balancer ](#r53-dns-failover) ### Unhealthy state actions You can configure healthy thresholds for the following actions: + **DNS failover** – When the healthy targets in a zone fall below the threshold, we mark the IP addresses of the load balancer node for the zone as unhealthy in DNS. Therefore, when clients resolve the load balancer DNS name, the traffic is routed only to healthy zones. + **Routing failover** – When the healthy targets in a zone fall below the threshold, the load balancer sends traffic to all targets that are available to the load balancer node, including unhealthy targets. This increases the chances that a client connection succeeds, especially when targets temporarily fail to pass health checks, and reduces the risk of overloading the healthy targets. ### Requirements and considerations + If you specify both types of thresholds for an action (count and percentage), the load balancer takes the action when either threshold is breached. + If you specify thresholds for both actions, the threshold for DNS failover must be greater than or equal to the threshold for routing failover, so that DNS failover occurs either with or before routing failover. + If you specify the threshold as a percentage, we calculate the value dynamically, based on the total number of targets that are registered with the target groups. + The total number of targets is based on whether cross-zone load balancing is off or on. If cross-zone load balancing is off, each node sends traffic only to the targets in its own zone, which means that the thresholds apply to the number of targets in each enabled zone separately. If cross-zone load balancing is on, each node sends traffic to all targets in all enabled zones, which means that the specified thresholds apply to the total number targets in all enabled zones. For more information, see [Cross-zone load balancing](edit-target-group-attributes.md#target-group-cross-zone). + When DNS failover occurs, it impacts all target groups associated with the load balancer. Ensure that you have enough capacity in your remaining zones to handle this additional traffic, especially if cross-zone load balancing is off. + With DNS failover, we remove the IP addresses of the unhealthy zones from the DNS hostname for the load balancer. However, the local client DNS cache might contain these IP addresses until the time-to-live (TTL) in the DNS record expires (60 seconds). + With DNS failover, if there are multiple target groups attached to a Network Load Balancer and one target group is unhealthy in a zone, DNS failover occurs, even if another target group is healthy in that zone. + With DNS failover, if all load balancer zones are considered unhealthy, the load balancer sends traffic to all zones, including the unhealthy zones. + There are factors other than whether there are enough healthy targets that might lead to DNS failover, such as the health of the zone. ### Example The following example demonstrates how target group health settings are applied. **Scenario** + A load balancer that supports two Availability Zones, A and B + Each Availability Zone contains 10 registered targets + The target group has the following target group health settings: + DNS failover - 50% + Routing failover - 50% + Six targets fail in Availability Zone B ![\[A load balancer enabled for two zones. AZ A has 10 healthy targets and AZ B has 4 healthy targets and 6 unhealthy targets.\]](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/images/tg-health-example.png) **If cross-zone load balancing is off** + The load balancer node in each Availability Zone can send traffic only to the 10 targets in its Availability Zone. + There are 10 healthy targets in Availability Zone A, which meets the required percentage of healthy targets. The load balancer continues to distribute traffic between the 10 healthy targets. + There are only 4 healthy targets in Availability Zone B, which is 40% of the targets for the load balancer node in Availability Zone B. Because this is less than the required percentage of healthy targets, the load balancer takes the following actions: + DNS failover - Availability Zone B is marked as unhealthy in DNS. Because clients can't resolve the load balancer name to the load balancer node in Availability Zone B, and Availability Zone A is healthy, clients send new connections to Availability Zone A. + Routing failover - When new connections are sent explicitly to Availability Zone B, the load balancer distributes traffic to all targets in Availability Zone B, including the unhealthy targets. This prevents outages among the remaining healthy targets. **If cross-zone load balancing is on** + Each load balancer node can send traffic to all 20 registered targets across both Availability Zones. + There are 10 healthy targets in Availability Zone A and 4 healthy targets in Availability Zone B, for a total of 14 healthy targets. This is 70% of the targets for the load balancer nodes in both Availability Zones, which meets the required percentage of healthy targets. + The load balancer distributes traffic between the 14 healthy targets in both Availability Zones. ### Using Route 53 DNS failover for your load balancer If you use Route 53 to route DNS queries to your load balancer, you can also configure DNS failover for your load balancer using Route 53. In a failover configuration, Route 53 checks the health of the target group targets for the load balancer to determine whether they are available. If there are no healthy targets registered with the load balancer, or if the load balancer itself is unhealthy, Route 53 routes traffic to another available resource, such as a healthy load balancer or a static website in Amazon S3. For example, suppose that you have a web application for `www.example.com`, and you want redundant instances running behind two load balancers residing in different Regions. You want the traffic to be primarily routed to the load balancer in one Region, and you want to use the load balancer in the other Region as a backup during failures. If you configure DNS failover, you can specify your primary and secondary (backup) load balancers. Route 53 directs traffic to the primary load balancer if it is available, or to the secondary load balancer otherwise. **How evaluate target health works** + If evaluate target health is set to `Yes` on an alias record for a Network Load Balancer, Route 53 evaluates the health of the resource specified by the `alias target` value. Route 53 uses the target group health checks. + If all target groups attached to a Network Load Balancer are healthy, Route 53 marks the alias record as healthy. If you configured a threshold for a target group and it meets its threshold, it passes health checks. Otherwise, if a target group contains at least one healthy target, it passes health checks. If health checks pass, Route 53 returns records according to your routing policy. If a failover routing policy is used, Route 53 returns the primary record. + If all target groups attached to a Network Load Balancer are unhealthy, the alias record fails the Route 53 health check (fail-open). If using evaluate target health, this causes the failover routing policy to redirect traffic to the secondary resource. + If all of the target groups in a Network Load Balancer are empty (no targets), Route 53 considers the record unhealthy (fail-open). If using evaluate target health, this causes the failover routing policy to redirect traffic to the secondary resource. For more information, see [Using load balancer target group health thresholds to improve availability](https://aws.amazon.com/blogs/networking-and-content-delivery/using-load-balancer-target-group-health-thresholds-to-improve-availability/) in the AWS Blog and [Configuring DNS failover](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) in the *Amazon Route 53 Developer Guide*. # Create a target group for your Network Load Balancer Create a target group You register targets for your Network Load Balancer with a target group. By default, the load balancer sends requests to registered targets using the port and protocol that you specified for the target group. You can override this port when you register each target with the target group. To route traffic to the targets in a target group, create a listener and specify the target group in the default action for the listener. For more information, see [Default actions](load-balancer-listeners.md#default-actions). You can specify the same target group in multiple listeners, but these listeners must belong to the same Network Load Balancer. To use a target group with a load balancer, you must verify that the target group is not in use by a listener for any other load balancer. You can add or remove targets from your target group at any time. For more information, see [Register targets for your Network Load Balancer](target-group-register-targets.md). You can also modify the health check settings for your target group. For more information, see [Update the health check settings of a Network Load Balancer target group](modify-health-check-settings.md). **Requirements** + After you create a target group, you can't change its target type or its IP address type. + All targets in a target group must have the same IP address type as the target group: IPv4 or IPv6. + You must use an IPv6 target group with a dualstack load balancer. + You can't use an IPv4 target group with a UDP listener for a `dualstack` load balancer. + You can't use an IPv6 target group with QUIC or TCP\$1QUIC protocols. ------ #### [ Console ] **To create a target group** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, choose **Target Groups**. 1. Choose **Create target group**. 1. For the **Basic configuration** pane, do the following: 1. For **Choose a target type**, select **Instances** to register targets by instance ID, **IP addresses** to register targets by IP address, or **Application Load Balancer** to register an Application Load Balancer as a target. 1. For **Target group name**, enter a name for the target group. This name must be unique per Region per account, can have a maximum of 32 characters, must contain only alphanumeric characters or hyphens, and must not begin or end with a hyphen. 1. For **Protocol**, choose a protocol as follows: + If the listener protocol is TCP, choose **TCP** or **TCP\$1UDP**. + If the listener protocol is TLS, choose **TCP** or **TLS**. + If the listener protocol is UDP, choose **UDP** or **TCP\$1UDP**. + If the listener protocol is TCP\$1UDP, choose **TCP\$1UDP**. + If the listener protocol is QUIC, choose **QUIC**. + If the listener protocol is TCP\$1QUIC, choose **TCP\$1QUIC**. + If the target type is **Application Load Balancer**, the protocol must be TCP. 1. For **Port**, modify the default value as needed. If the target type is **Application Load Balancer**, the port must match the listener port of the Application Load Balancer. 1. For **IP address type**, choose **IPv4** or **IPv6**. This option is available only if the target type is **Instances** or **IP addresses**. 1. For **VPC**, select the virtual private cloud (VPC) with the targets to register. 1. For the **Health checks** pane, modify the default settings as needed. For **Advanced health check settings**, choose the health check port, count, timeout, interval, and specify success codes. If health checks consecutively exceed the **Unhealthy threshold** count, the load balancer takes the target out of service. If health checks consecutively exceed the **Healthy threshold** count, the load balancer puts the target back in service. For more information, see [](target-group-health-checks.md). 1. (Optional) To add a tag, expand **Tags**, choose **Add tag**, and enter a tag key and a tag value. 1. Choose **Next**. 1. (Optional) Register targets. The target type of the target group determines the information that you provide. If you aren't ready to register targets now, you can register them later. + **Instances** – Select the EC2 instances, enter the ports, and choose **Include as pending below**. + **IP addresses** – Choose the VPC that contains the IP addresses or **Other private IP addresses**, enter the IP addresses and ports, and choose **Include as pending below**. + **Application Load Balancer** – Select the Application Load Balancer. For more information, see [Use Application Load Balancers as targets](application-load-balancer-target.md). 1. Choose **Create target group**. ------ #### [ AWS CLI ] **To create a target group** Use the [create-target-group](https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-target-group.html) command. The following example creates a target group with the TCP protocol, targets registered by IP address, one tag, and default health check settings. ``` aws elbv2 create-target-group \ --name my-target-group \ --protocol TCP \ --port 80 \ --target-type ip \ --vpc-id vpc-1234567890abcdef0 \ --tags Key=department,Value=123 ``` **To register targets** Use the [register-targets](https://docs.aws.amazon.com/cli/latest/reference/elbv2/register-targets.html) command to register targets with the target group. For examples, see [Register targets](target-group-register-targets.md#register-targets). ------ #### [ CloudFormation ] **To create a target group** Define a resource of type [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html). The following example creates a target group with the TCP protocol, targets registered by IP address, one tag, default health check settings, and two registered targets. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: ip VpcId: !Ref myVPC Tags: - Key: 'department' Value: '123' Targets: - Id: 10.0.50.10 Port: 80 - Id: 10.0.50.20 Port: 80 ``` ------ # Update the target group health settings for your Network Load Balancer Update health settings By default, Network Load Balancers monitor the health of targets and route requests to healthy targets. However, if the load balancer doesn't have enough healthy targets, it automatically sends traffic to all registered targets (fail open). You can modify the target group health settings for your target group to define the thresholds for DNS failover and routing failover. For more information, see [Target group health](load-balancer-target-groups.md#target-group-health). ------ #### [ Console ] **To update the target group health settings** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. On the **Attributes** tab, choose **Edit**. 1. Expand **Target group health requirements**. 1. For **Configuration type**, we recommend that you choose **Unified configuration**, which sets the same threshold for both DNS failover and routing failover. 1. For **Healthy state requirements**, do one of the following: + Choose **Minimum healthy target count**, and then enter a number from 1 to the maximum number of targets for your target group. + Choose **Minimum healthy target percentage**, and then enter a number from 1 to 100. 1. The informational text indicates whether cross-zone load balancing is enabled for the target group. If cross-zone load balancing is disabled, you can enable it to ensure that you have enough capacity. Under **Target selection configuration**, update **Cross-zone load balancing**. The following text indicates that cross-zone load balancing is disabled: ``` Healthy state requirements apply to each zone independently. ``` The following text indicates that cross-zone load balancing is enabled: ``` Healthy state requirements apply to the total targets across all applicable zones. ``` 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update the target group health settings** Use the [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) command. The following example sets the healthy threshold for both unhealthy state actions to 50%. ``` aws elbv2 modify-target-group-attributes \ --target-group-arn target-group-arn \ --attributes \ "Key=target_group_health.dns_failover.minimum_healthy_targets.percentage,Value=50" \ "Key=target_group_health.unhealthy_state_routing.minimum_healthy_targets.percentage,Value=50" ``` ------ #### [ CloudFormation ] **To modify target group health settings** Update the [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) resource. The following example sets the healthy threshold for both unhealthy state actions to 50%. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: ip VpcId: !Ref myVPC TargetGroupAttributes: - Key: "target_group_health.dns_failover.minimum_healthy_targets.percentage" Value: "50" - Key: "target_group_health.unhealthy_state_routing.minimum_healthy_targets.percentage" Value: "50" ``` ------ # Health checks for Network Load Balancer target groups Configure health checks 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 and the targets pass the initial health checks. 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](network-load-balancers.md#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](edit-target-group-attributes.md#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. Network Load Balancers will also fail open when you have an empty target group. 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 UDP and QUIC services, 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 your service. If the service receiving the health check fails, your target is considered unavailable. To improve the accuracy of health checks for your service, configure the service listening to the health check port to track the status of your UDP or QUIC service and fail the health check if the service is unavailable. For more information, see [Target group health](load-balancer-target-groups.md#target-group-health). **Topics** + [ ## Health check settings ](#health-check-settings) + [ ## Target health status ](#target-health-states) + [ ## Health check reason codes ](#target-health-reason-codes) + [Check target health](check-target-health.md) + [Update health check settings](modify-health-check-settings.md) ## 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 `alb`, the supported health check protocols are HTTP and HTTPS. | 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. Health 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 | | --- | --- | | `initial` | The load balancer is in the process of registering the target or performing the initial health checks on the target. Related reason codes: `Elb.RegistrationInProgress` \$1 `Elb.InitialHealthChecking` | | `healthy` | The target is healthy. Related reason codes: None | | `unhealthy` | The target did not respond to a health check, failed the health check, or the target is in stopped state. Related reason code: `Target.FailedHealthChecks` | | `draining` | The target is deregistering and connection draining is in process. Related reason code: `Target.DeregistrationInProgress` | | `unhealthy.draining` | 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.FailedHealthChecks` | | `unavailable` | Target health is unavailable. Related reason code: `Elb.InternalError` | | `unused` | 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: `Target.NotRegistered` \$1 `Target.NotInUse` \$1 `Target.InvalidState` \$1 `Target.IpUnusable` | ## 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 | | --- | --- | | `Elb.InitialHealthChecking` | Initial health checks in progress | | `Elb.InternalError` | Health checks failed due to an internal error | | `Elb.RegistrationInProgress` | Target registration is in progress | | `Target.DeregistrationInProgress` | Target deregistration is in progress | | `Target.FailedHealthChecks` | Health checks failed | | `Target.InvalidState` | 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 | | `Target.IpUnusable` | The IP address cannot be used as a target, as it is in use by a load balancer | | `Target.NotInUse` | 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.NotRegistered` | Target is not registered to the target group | # Check the health of your Network Load Balancer targets Check target health You can check the health status of the targets registered with your target groups. For help with health check failures, see [Troubleshooting: A registered target is not in service](load-balancer-troubleshooting.md#target-not-in-service). ------ #### [ Console ] **To check the health of your targets** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. The **Details** tab displays the total number of targets, plus the number of targets for each health status. 1. On the **Targets** tab, the **Health status** column indicates the status of each target. 1. If the status of a target is any value other than `Healthy`, the **Health status details** column contains more information. **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](https://aws.amazon.com/blogs/networking-and-content-delivery/identifying-unhealthy-targets-of-elastic-load-balancer/). ------ #### [ AWS CLI ] **To check the health of your targets** Use the [describe-target-health](https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-target-health.html) command. This example filters the output to include only targets that are not healthy. For targets that are not healthy, the output includes a reason code. ``` aws elbv2 describe-target-health \ --target-group-arn target-group-arn \ --query "TargetHealthDescriptions[?TargetHealth.State!='healthy'].[Target.Id,TargetHealth.State,TargetHealth.Reason]" \ --output table ``` The following is example output. ``` ---------------------------------------------- | DescribeTargetHealth | +--------------+---------+-------------------+ | 172.31.0.57 | unused | Target.NotInUse | | 172.31.0.50 | unused | Target.NotInUse | +--------------+---------+-------------------+ ``` ------ ## Target states and reason codes The following list shows the possible reason codes for each target state. **Target state is healthy** A reason code is not provided. **Target state is initial** + `Elb.RegistrationInProgress` - The target is in the process of being registered with the load balancer. + `Elb.InitialHealthChecking` - The load balancer is still sending the target the minimum number of health checks required to determine its health status. **Target state is unhealthy** + `Target.FailedHealthChecks` - The load balancer received an error while establishing a connection to the target or the target response was malformed. **Target state is unused** + `Target.NotRegistered` - The target is not registered with the target group. + `Target.NotInUse` - The target group is not used by any load balancer or the target is in an Availability Zone that is not enabled for its load balancer. + `Target.InvalidState` - The target is in the stopped or terminated state. + `Target.IpUnusable` - The target IP address is reserved for use by a load balancer. **Target state is draining** + `Target.DeregistrationInProgress` - The target is in the process of being deregistered and the deregistration delay period has not expired. **Target state is unavailable** + `Elb.InternalError` - Target health is unavailable due to an internal error. # Update the health check settings of a Network Load Balancer target group Update health check settings You can update the health check settings for your target group at any time. For the list of health check settings, see [Health check settings](target-group-health-checks.md#health-check-settings). ------ #### [ Console ] **To update the health check settings** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. On the **Health checks** tab, choose **Edit**. 1. On the **Edit health check settings** page, modify the settings as needed. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update the health check settings** Use the [modify-target-group](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group.html) command. The following example updates the **HealthyThresholdCount** and **HealthCheckTimeoutSeconds** settings. ``` aws elbv2 modify-target-group \ --target-group-arn target-group-arn \ --healthy-threshold-count 3 \ --health-check-timeout-seconds 20 ``` ------ #### [ CloudFormation ] **To update the health check settings** Update the [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) resource to include the updated health check settings. The following example updates the **HealthyThresholdCount** and **HealthCheckTimeoutSeconds** settings. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: instance VpcId: !Ref myVPC HealthyThresholdCount: 3 HealthCheckTimeoutSeconds: 20 ``` ------ # Edit target group attributes for your Network Load Balancer Edit target group attributes After you create a target group for your Network Load Balancer, you can edit its target group attributes. **Topics** + [ ## Client IP preservation ](#client-ip-preservation) + [ ## Deregistration delay ](#deregistration-delay) + [ ## Proxy protocol ](#proxy-protocol) + [ ## Sticky sessions ](#sticky-sessions) + [Cross-zone load balancing](#target-group-cross-zone) + [ ## Connection termination for unhealthy targets ](#unhealthy-target-connection-termination) + [ ## Unhealthy draining interval ](#unhealthy-draining-interval) ## Client IP preservation Network Load Balancers can preserve the source IP addresses of clients when routing requests to backend targets. When you disable client IP preservation, the source IP address is the private IP address of the Network Load Balancer. By default, client IP preservation is enabled (and can't be disabled) for instance and IP type target groups with UDP, TCP\$1UDP, QUIC, and TCP\$1QUIC protocols. However, you can enable or disable client IP preservation for TCP and TLS target groups using the `preserve_client_ip.enabled` target group attribute. **Default settings** + Instance type target groups: Enabled + IP type target groups (UDP, TCP\$1UDP, QUIC, TCP\$1QUIC): Enabled + IP type target groups (TCP, TLS): Disabled **When client IP preservation is enabled** The following table describes the IP addresses that targets receive when client IP preservation is enabled. | Targets | IPv4 client requests | IPv6 client requests | | --- | --- | --- | | Instance type (IPv4) | Client IPv4 address | Load balancer IPv4 address | | IP type (IPv4) | Client IPv4 address | Load balancer IPv4 address | | IP type (IPv6) | Load balancer IPv6 address | Client IPv6 address | **When client IP preservation is disabled** The following table describes the IP addresses that targets receive when client IP preservation is disabled. | Targets | IPv4 client requests | IPv6 client requests | | --- | --- | --- | | Instance type (IPv4) | Load balancer IPv4 address | Load balancer IPv4 address | | IP type (IPv4) | Load balancer IPv4 address | Load balancer IPv4 address | | IP type (IPv6) | Load balancer IPv6 address | Load balancer IPv6 address | **Requirements and considerations** + Client IP preservation changes take effect only for new TCP connections. + When client IP preservation is enabled, the traffic must flow directly from the Network Load Balancer to the target. The target must be located in the same VPC as the load balancer or in a peered VPC in the same Region. + Client IP preservation is not supported when targets are reached through a transit gateway. + Client IP preservation is not supported when using a Gateway Load Balancer endpoint to inspect traffic between the Network Load Balancer and the target (instance or IP address), even if the target is in the same VPC as the Network Load Balancer. + The following instance types do not support client IP preservation: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3, and T1. We recommend that you register these instance types as IP addresses with client IP preservation disabled. + Client IP preservation has no effect on inbound traffic from AWS PrivateLink. The source IP address of the AWS PrivateLink traffic is always the private IP address of the Network Load Balancer. + Client IP preservation is not supported when a target group contains AWS PrivateLink network interfaces, or the network interface of another Network Load Balancer. This causes a loss of communication to those targets. + Client IP preservation has no effect on traffic converted from IPv6 to IPv4. The source IP address of this type of traffic is always the private IP address of the Network Load Balancer. + When you specify targets by Application Load Balancer type, the client IP of all incoming traffic is preserved by the Network Load Balancer and is sent to the Application Load Balancer. The Application Load Balancer then appends the client IP to the `X-Forwarded-For` request header before sending it to the target. + NAT loopback, also known as hairpinning, is not supported when client IP preservation is enabled. This occurs when using internal Network Load Balancers, and the target registered behind a Network Load Balancer creates connections to the same Network Load Balancer. The connection can be routed to the target which is attempting to create the connection, leading to connection errors. We recommend not connecting to a Network Load Balancer from targets behind same Network Load Balancer, alternatively you can also prevent this type of connection error by disabling client IP preservation. If you need the client IP address, you can use retrieve it using Proxy Protocol v2. For more information, see [Proxy protocol](#proxy-protocol). + When client IP preservation is disabled, a Network Load Balancer supports 55,000 simultaneous connections or about 55,000 connections per minute to each unique target (IP address and port). If you exceed these connections, there is an increased chance of port allocation errors, resulting in failures to establish new connections. For more information, see [Port allocation errors for backend flows](load-balancer-troubleshooting.md#port-allocation-errors-privatelink). ------ #### [ Console ] **To modify client IP preservation** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. On the **Attributes** tab, choose **Edit** and find the **Traffic configuration** pane. 1. To enable client IP preservation, turn on **Preserve client IP addresses**. To disable client IP preservation, turn off **Preserve client IP addresses**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To enable client IP preservation** Use the [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) command with the `preserve_client_ip.enabled` attribute. ``` aws elbv2 modify-target-group-attributes \ --target-group-arn target-group-arn \ --attributes "Key=preserve_client_ip.enabled,Value=true" ``` ------ #### [ CloudFormation ] **To enable client IP preservation** Update the [AWS::ElasticLoadBalancingV2::TargetGroup ](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) resource to include the `preserve_client_ip.enabled` attribute. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: ip VpcId: !Ref myVPC TargetGroupAttributes: - Key: "preserve_client_ip.enabled" Value: "true" ``` ------ ## Deregistration delay When a target is deregistered, the load balancer stops creating new connections to the target. The load balancer uses connection draining to ensure that in-flight traffic completes on the existing connections. If the deregistered target stays healthy and an existing connection is not idle, the load balancer can continue to send traffic to the target. To ensure that existing connections are closed, you can do one of the following: enable the target group attribute for connection termination, ensure that the instance is unhealthy before you deregister it, or periodically close client connections. The initial state of a deregistering target is `draining`, during which the target will stop receiving new connections. However, the target may still receive connections due to configuration propagation delay. By default, the load balancer changes the state of a deregistering target to `unused` after 300 seconds. To change the amount of time that the load balancer waits before changing the state of a deregistering target to `unused`, update the deregistration delay value. We recommend that you specify a value of at least 120 seconds to ensure that requests are completed. For QUIC traffic the value is always 300 seconds, and can't be adjusted. If you enable the target group attribute for connection termination, connections to deregistered targets are closed shortly after the end of the deregistration timeout. ------ #### [ Console ] **To modify the deregistration delay attributes** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. On the **Attributes** tab, choose **Edit**. 1. To change the deregistration timeout, enter a new value for **Deregistration delay**. To ensure that existing connections are closed after you deregister targets, select **Terminate connections on deregistration**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To modify the deregistration delay attributes** Use the [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) command with the `deregistration_delay.timeout_seconds` and `deregistration_delay.connection_termination.enabled` attributes. ``` aws elbv2 modify-target-group-attributes \ --target-group-arn target-group-arn \ --attributes \ "Key=deregistration_delay.timeout_seconds,Value=60" \ "Key=deregistration_delay.connection_termination.enabled,Value=true" ``` ------ #### [ CloudFormation ] **To modify the deregistration delay attributes** Update the [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) resource to include the `deregistration_delay.timeout_seconds` and `deregistration_delay.connection_termination.enabled` attributes. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: ip VpcId: !Ref myVPC TargetGroupAttributes: - Key: "deregistration_delay.timeout_seconds" Value: "60" - Key: "deregistration_delay.connection_termination.enabled" Value: "true" ``` ------ ## Proxy protocol Network Load Balancers use proxy protocol version 2 to send additional connection information such as the source and destination. Proxy protocol version 2 provides a binary encoding of the proxy protocol header. With TCP listeners, the load balancer prepends a proxy protocol header to the TCP data. It does not discard or overwrite any existing data, including any incoming proxy protocol headers sent by the client or any other proxies, load balancers, or servers in the network path. Therefore, it is possible to receive more than one proxy protocol header. Also, if there is another network path to your targets outside of your Network Load Balancer, the first proxy protocol header might not be the one from the load balancer. TLS listeners do not support incoming connections with proxy protocol headers sent by the client or any other proxies. QUIC traffic does not support proxy protocol version 2. If you specify targets by IP address, the source IP addresses provided to your applications depend on the protocol of the target group as follows: + TCP and TLS: By default, client IP preservation is disabled, and the source IP addresses provided to your applications are the private IP addresses of the load balancer nodes. To preserve the client's IP address, ensure that the target is located within the same VPC or a peered VPC and enable client IP preservation. If you need the IP address of the client and these conditions are not met, enable the proxy protocol and get the client IP address from the proxy protocol header. + UDP and TCP\$1UDP: The source IP addresses are the IP addresses of the clients, as client IP preservation is enabled by default for these protocols and cannot be disabled. If you specify targets by instance ID, the source IP addresses provided to your applications are the client IP addresses. However, if you prefer, you can enable proxy protocol and get the client IP addresses from the proxy protocol header. ### Health check connections After you enable proxy protocol, the proxy protocol header is also included in health check connections from the load balancer. However, with health check connections, the client connection information is not sent in the proxy protocol header. Targets can fail health checks if they can't parse the proxy protocol header. For example, they might return the following error: HTTP 400: Bad request. ### VPC endpoint services For traffic coming from service consumers through a [VPC endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html), the source IP addresses provided to your applications are the private IP addresses of the load balancer nodes. If your applications need the IP addresses of the service consumers, enable proxy protocol and get them from the proxy protocol header. The proxy protocol header also includes the ID of the endpoint. This information is encoded using a custom Type-Length-Value (TLV) vector as follows. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/edit-target-group-attributes.html) For an example that parses TLV type 0xEA, see [https://github.com/aws/elastic-load-balancing-tools/tree/master/proprot](https://github.com/aws/elastic-load-balancing-tools/tree/master/proprot). ### Enable proxy protocol Before you enable proxy protocol on a target group, make sure that your applications expect and can parse the proxy protocol v2 header, otherwise, they might fail. For more information, see [PROXY protocol versions 1 and 2](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). ------ #### [ Console ] **To enable proxy protocol version 2** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name the target group to open its details page. 1. On the **Attributes** tab, choose **Edit**. 1. On the **Edit attributes** page, select **Proxy protocol v2**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To enable proxy protocol version 2** Use the [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) command with the `proxy_protocol_v2.enabled` attribute. ``` aws elbv2 modify-target-group-attributes \ --target-group-arn target-group-arn \ --attributes "Key=proxy_protocol_v2.enabled,Value=true" ``` ------ #### [ CloudFormation ] **To enable proxy protocol version 2** Update the [AWS::ElasticLoadBalancingV2::TargetGroup ](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) resource to include the `proxy_protocol_v2.enabled` attribute. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: ip VpcId: !Ref myVPC TargetGroupAttributes: - Key: "proxy_protocol_v2.enabled" Value: "true" ``` ------ ## Sticky sessions Sticky sessions are a mechanism to route client traffic to the same target in a target group. This is useful for servers that maintain state information in order to provide a continuous experience to clients. **Considerations** + Using sticky sessions can lead to an uneven distribution of connections and flows, which might impact the availability of your targets. For example, all clients behind the same NAT device have the same source IP address. Therefore, all traffic from these clients is routed to the same target. + The load balancer might reset the sticky sessions for a target group if the health state of any of its targets changes or if you register or deregister targets with the target group. + When the stickiness attribute is turned on for a target group, passive health checks are not supported. For more information, see [ Health checks for your target groups](target-group-health-checks.md). + Sticky sessions are not supported for TLS or QUIC listeners. ------ #### [ Console ] **To enable sticky sessions** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. On the **Attributes** tab, choose **Edit**. 1. Under **Target selection configuration**, turn on **Stickiness**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To enable sticky sessions** Use the [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) command with the `stickiness.enabled` attribute. ``` aws elbv2 modify-target-group-attributes \ --target-group-arn target-group-arn \ --attributes "Key=stickiness.enabled,Value=true" ``` ------ #### [ CloudFormation ] **To enable sticky sessions** Update the [AWS::ElasticLoadBalancingV2::TargetGroup ](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) resource to include the `stickiness.enabled` attribute. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: ip VpcId: !Ref myVPC TargetGroupAttributes: - Key: "stickiness.enabled" Value: "true" ``` ------ ## Cross-zone load balancing for target groups Cross-zone load balancing The nodes for your load balancer distribute requests from clients to registered targets. When cross-zone load balancing is on, each load balancer node distributes traffic across the registered targets in all registered Availability Zones. When cross-zone load balancing is off, each load balancer node distributes traffic across only the registered targets in its Availability Zone. This could be used if zonal failure domains are preferred over regional, ensuring that a healthy zone isn't impacted by an unhealthy zone, or for overall latency improvements. With Network Load Balancers, cross-zone load balancing is disabled by default at the load balancer level, but you can enable it at any time. For target groups, the default is to use the load balancer setting, but you can override the default by explicitly enabling or disabling cross-zone load balancing at the target group level. **Considerations** + When enabling cross-zone load balancing for a Network Load Balancer, EC2 data transfer charges apply. For more information, see [Understanding data transfer charges](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html) in the *AWS Data Exports User Guide* + The target group setting determines the load balancing behavior for the target group. For example, if cross-zone load balancing is enabled at the load balancer level and disabled at the target group level, traffic sent to the target group is not routed across Availability Zones. + When cross-zone load balancing is disabled, ensure that you have enough target capacity in each of the load balancer Availability Zones, so that each zone can serve its associated workload. + When cross-zone load balancing is disabled, ensure that all target groups participate in the same Availability Zones. An empty Availability Zone is considered unhealthy. + You can enable or disable cross-zone load balancing at the target group level if the target group type is `instance` or `ip`. If the target group type is `alb`, the target group always inherits the cross-zone load balancing setting from the load balancer. For more information about enabling cross-zone load balancing at the load balancer level, see [Cross-zone load balancing](edit-load-balancer-attributes.md#load-balancer-cross-zone). ------ #### [ Console ] **To enable cross-zone load balancing for a target group** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, select **Target Groups**. 1. Select the name of the target group to open its details page. 1. On the **Attributes** tab, choose **Edit**. 1. On the **Edit target group attributes** page, select **On** for **Cross-zone load balancing**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To enable cross-zone load balancing for a target group** Use the [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) command with the `load_balancing.cross_zone.enabled` attribute. ``` aws elbv2 modify-target-group-attributes \ --target-group-arn target-group-arn \ --attributes "Key=load_balancing.cross_zone.enabled,Value=true" ``` ------ #### [ CloudFormation ] **To enable cross-zone load balancing for a target group** Update the [AWS::ElasticLoadBalancingV2::TargetGroup ](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) resource to include the `load_balancing.cross_zone.enabled` attribute. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: ip VpcId: !Ref myVPC TargetGroupAttributes: - Key: "load_balancing.cross_zone.enabled" Value: "true" ``` ------ ## Connection termination for unhealthy targets Connection termination is enabled by default. When the target of a Network Load Balancer fails the configured health checks and is deemed unhealthy, the load balancer terminates established connections and stops routing new connections to the target. With connection termination disabled the target is still considered unhealthy and won't receive new connections, but established connections are kept active, allowing them to gracefully close. Connection termination for unhealthy targets is configured at the target group level. ------ #### [ Console ] **To modify the connection termination attribute** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. On the **Attributes** tab, choose **Edit**. 1. Under **Target unhealthy state management**, choose whether **Terminate connections when targets become unhealthy** is enabled or disabled. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To disable the connection termination attribute** Use the [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) command with the `target_health_state.unhealthy.connection_termination.enabled` attribute. ``` aws elbv2 modify-target-group-attributes \ --target-group-arn target-group-arn \ --attributes "Key=target_health_state.unhealthy.connection_termination.enabled,Value=false" ``` ------ #### [ CloudFormation ] **To disable the connection termination attribute** Update the [AWS::ElasticLoadBalancingV2::TargetGroup ](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) resource to include the `target_health_state.unhealthy.connection_termination.enabled` attribute. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: ip VpcId: !Ref myVPC TargetGroupAttributes: - Key: "target_health_state.unhealthy.connection_termination.enabled" Value: "false" ``` ------ ## Unhealthy draining interval Targets in the `unhealthy.draining` state are considered unhealthy, do not receive new connections, but retain established connections for the configured interval. The unhealthy connection interval determines the amount of time the target remains in the `unhealthy.draining` state before its state becomes `unhealthy`. If the target passes health checks during the unhealthy connection interval, its state becomes `healthy` again. If a deregistration is triggered, the targets state becomes `draining` and the deregistration delay timeout begins. **Requirement** Connection termination must be disabled before enabling unhealthy draining interval. ------ #### [ Console ] **To modify the unhealthy draining interval** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. On the **Attributes** tab, choose **Edit**. 1. Under **Target unhealthy state management**, make sure **Terminate connections when targets become unhealthy** is turned off. 1. Enter a value for **Unhealthy draining interval**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To modify the unhealthy draining interval** Use the [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) command with the `target_health_state.unhealthy.draining_interval_seconds` attribute. ``` aws elbv2 modify-target-group-attributes \ --target-group-arn target-group-arn \ --attributes "Key=target_health_state.unhealthy.draining_interval_seconds,Value=60" ``` ------ #### [ CloudFormation ] **To modify the unhealthy draining interval** Update the [AWS::ElasticLoadBalancingV2::TargetGroup ](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) resource to include the `target_health_state.unhealthy.draining_interval_seconds` attribute. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: ip VpcId: !Ref myVPC TargetGroupAttributes: - Key: "target_health_state.unhealthy.draining_interval_seconds" Value: "60" ``` ------ # Register targets for your Network Load Balancer Register targets When your target is ready to handle requests, you register it with one or more target groups. The target type of the target group determines how you register targets. For example, you can register instance IDs, IP addresses, or an Application Load Balancer. Your Network Load Balancer starts routing requests to targets as soon as the registration process completes and the targets pass the initial health checks. It can take a few minutes for the registration process to complete and health checks to start. For more information, see [Health checks for Network Load Balancer target groups](target-group-health-checks.md). If demand on your currently registered targets increases, you can register additional targets in order to handle the demand. If demand on your registered targets decreases, you can deregister targets from your target group. It can take a few minutes for the deregistration process to complete and for the load balancer to stop routing requests to the target. If demand increases subsequently, you can register targets that you deregistered with the target group again. If you need to service a target, you can deregister it and then register it again when servicing is complete. When you deregister a target, Elastic Load Balancing waits until in-flight requests have completed. This is known as *connection draining*. The status of a target is `draining` while connection draining is in progress. After deregistration is complete, status of the target changes to `unused`. For more information, see [Deregistration delay](edit-target-group-attributes.md#deregistration-delay). If you are registering targets by instance ID, you can use your load balancer with an Auto Scaling group. After you attach a target group to an Auto Scaling group and the group scales out, the instances launched by the Auto Scaling group are automatically registered with the target group. If you detach the load balancer from the Auto Scaling group, the instances are automatically deregistered from the target group. For more information, see [Attaching a load balancer to your Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html) in the *Amazon EC2 Auto Scaling User Guide*. **Topics** + [ ## Target security groups ](#target-security-groups) + [ ## Network ACLs ](#network-acls) + [ ## Shared subnets ](#register-targets-shared-subnets) + [ ## Register targets ](#register-targets) + [ ## Deregister targets ](#deregister-targets) ## Target security groups Before adding targets to your target group, configure the security groups associated with the targets to accept traffic from your Network Load Balancer. **Recommendations for target security groups if the load balancer has an associated security group** + **To allow client traffic**: Add a rule that references the security group associated with the load balancer. + **To allow PrivateLink traffic**: If you configured the load balancer to evaluate inbound rules for traffic sent through AWS PrivateLink, add a rule that accepts traffic from the load balancer security group on the traffic port. Otherwise, add a rule that accepts traffic from the load balancer private IP addresses on the traffic port. + **To accept load balancer health checks**: Add a rule that accepts health check traffic from the load balancer security groups on the health check port. **Recommendations for target security groups if the load balancer is not associated with a security group** + **To allow client traffic**: If your load balancer preserves client IP addresses, add a rule that accepts traffic from the IP addresses of approved clients on the traffic port. Otherwise, add a rule that accepts traffic from the load balancer private IP addresses on the traffic port. + **To allow PrivateLink traffic**: Add a rule that accepts traffic from the load balancer private IP addresses on the traffic port. + **To accept load balancer health checks**: Add a rule that accepts health check traffic from the load balancer private IP addresses on the health check port. **How client IP preservation works** Network Load Balancers don't preserve client IP addresses unless you set the `preserve_client_ip.enabled` attribute to `true`. Also, with dualstack Network Load Balancers, client IP address preservation does not work when translating IPv4 addresses to IPv6, or IPv6 to IPv4 addresses. Client IP address preservation only works when client and target IP addresses are both IPv4 or both IPv6. **To find the load balancer private IP addresses using the console** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, choose **Network Interfaces**. 1. In the search field, enter the name of your Network Load Balancer. There is one network interface per load balancer subnet. 1. On the **Details** tab for each network interface, copy the address from **Private IPv4 address**. For more information, see [Update the security groups for your Network Load Balancer](load-balancer-security-groups.md). ## Network ACLs When you register EC2 instances as targets, you must ensure that the network ACLs for the subnets for your instances allow traffic on both the listener port and the health check port. The default network access control list (ACL) for a VPC allows all inbound and outbound traffic. If you create custom network ACLs, verify that they allow the appropriate traffic. The network ACLs associated with the subnets for your instances must allow the following traffic for an internet-facing load balancer. **Recommended rules for instance subnets** | | | **Inbound** | | --- | | Source | Protocol | Port Range | Comment | | Client IP addresses | listener | target port | Allow client traffic (IP Preservation: ON) | | VPC CIDR | listener | target port | Allow client traffic (IP Preservation: OFF) | | VPC CIDR | health check | health check | Allow health check traffic | | **Outbound** | | --- | | Destination | Protocol | Port Range | Comment | | Client IP addresses | listener | 1024-65535 | Allow return traffic to client (IP Preservation: ON) | | VPC CIDR | listener | 1024-65535 | Allow return traffic to client (IP Preservation: OFF) | | VPC CIDR | health check | 1024-65535 | Allow health check traffic | The network ACLs associated with the subnets for your load balancer must allow the following traffic for an internet-facing load balancer. **Recommended rules for load balancer subnets** | | | **Inbound** | | --- | | Source | Protocol | Port Range | Comment | | Client IP addresses | listener | listener | Allow client traffic | | VPC CIDR | listener | 1024-65535 | Allow response from target | | VPC CIDR | health check | 1024-65535 | Allow health check traffic | | **Outbound** | | --- | | Destination | Protocol | Port Range | Comment | | Client IP addresses | listener | 1024-65535 | Allow responses to clients | | VPC CIDR | listener | target port | Allow requests to targets | | VPC CIDR | health check | health check | Allow health check to targets | For an internal load balancer, the network ACLs for the subnets for your instances and load balancer nodes must allow both inbound and outbound traffic to and from the VPC CIDR, on the listener port and ephemeral ports. ## Shared subnets Participants can create a Network Load Balancer in a shared VPC. Participants can't register a target that runs in a subnet that is not shared with them. Shared subnets for Network Load Balancers is supported in all AWS Regions, excluding: + Asia Pacific (Osaka) `ap-northeast-3` + Asia Pacific (Hong Kong) `ap-east-1` + Middle East (Bahrain) `me-south-1` + AWS China (Beijing) `cn-north-1` + AWS China (Ningxia) `cn-northwest-1` ## Register targets Each target group must have at least one registered target in each Availability Zone that is enabled for the load balancer. The target type of your target group determines which targets you can register. For more information, see [Target type](load-balancer-target-groups.md#target-type). Use the information below to register targets with a target group of type `instance` or `ip`. If the target type is `alb`, see [Use Application Load Balancers as targets](application-load-balancer-target.md). **Requirements and considerations** + An instance must be in the `running` state when you register it. + You can't register instances by instance ID if they use one of the following instance types: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3, or T1. + When registering targets by instance ID, instances must be in the same VPC as the Network Load Balancer. You can't register instances by instance ID if they are in an VPC that is peered to the load balancer VPC (same Region or different Region). You can register these instances by IP address. + When registering targets by instance ID for a IPv6 target group, the targets must have an assigned primary IPv6 address. To learn more, see [ IPv6 addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing) in the *Amazon EC2 User Guide* + When registering targets by IP address for an IPv4 target group, the IP addresses that you register must be from one of the following CIDR blocks: + The subnets of the target group VPC + 10.0.0.0/8 (RFC 1918) + 100.64.0.0/10 (RFC 6598) + 172.16.0.0/12 (RFC 1918) + 192.168.0.0/16 (RFC 1918) + When registering targets by IP address for an IPv6 target group, the IP addresses that you register must be within the VPC IPv6 CIDR block or within the IPv6 CIDR block of a peered VPC. + If you register a target by IP address and the IP address is in the same VPC as the load balancer, the load balancer verifies that it is from a subnet that it can reach. + For UDP, TCP\$1UDP, QUIC, and TCP\$1QUIC target groups, do not register instances by IP address if they reside outside of the load balancer VPC or if they use one of the following instance types: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3, or T1. Targets that reside outside the load balancer VPC or use an unsupported instance type might be able to receive traffic from the load balancer but then be unable to respond. **QUIC specific requirements and considerations** + All targets registered to a QUIC or TCP\$1QUIC target group must have a server ID specified. + Server IDs must be unique for all targets that exist within an Network Load Balancer listener. + QUIC server IDs are always 8 bytes. When registering the target, the server ID must be in the form `0x` followed by 16 hexadecimal characters. + Once a target is registered with a server ID, the ID is immuatable. To change a target server ID, it must be deregistered first and then registered with the new server ID. + A target identifier and port combination must have one server ID. Using a different server ID for the same IP or instance ID and port combination within the same VPC is not supported. + Avoid re-using the same server ID for a different target within 6 hours. ------ #### [ Console ] **To register targets** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. Choose the **Targets** tab. 1. Choose **Register targets**. 1. If the target type of the target group is `instance`, select available instances, override the default port if needed, and then choose **Include as pending below**. 1. If the target type of the target group is `ip`, for each IP address, select the network, enter the IP address and ports, and choose **Include as pending below**. 1. If the target type of the target group is `alb`, override the default port if needed and select the Application Load Balancer. For more information, see [Use Application Load Balancers as targets](application-load-balancer-target.md). 1. If the protocol of the target group is QUIC or TCP\$1QUIC, ensure a server ID is specified. 1. Choose **Register pending targets**. ------ #### [ AWS CLI ] **To register targets** Use the [register-targets](https://docs.aws.amazon.com/cli/latest/reference/elbv2/register-targets.html) command. The following example registers targets by instance ID. Because the port is not specified, the load balancer uses the target group port. ``` aws elbv2 register-targets \ --target-group-arn target-group-arn \ --targets Id=i-1234567890abcdef0 Id=i-0abcdef1234567890 ``` The following example registers targets by IP address. Because the port is not specified, the load balancer uses the target group port. ``` aws elbv2 register-targets \ --target-group-arn target-group-arn \ --targets Id=10.0.50.10 Id=10.0.50.20 ``` The following example registers an Application Load Balancer as a target. ``` aws elbv2 register-targets \ --target-group-arn target-group-arn \ --targets Id=application-load-balancer-arn ``` The following example registers targets into a QUIC or TCP\$1QUIC target group. ``` aws elbv2 register-targets \ --target-group-arn target-group-arn \ --targets Id=10.0.50.10,QuicServerId=0xa1b2c3d4e5f65890 Id=10.0.50.20,QuicServerId=0xa1b2c3d4e5f65999 ``` ------ #### [ CloudFormation ] **To register targets** Update the [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) resource to include the new targets. The following example registers two targets by instance ID. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: HTTP Port: 80 TargetType: instance VpcId: !Ref myVPC Targets: - Id: !GetAtt Instance1.InstanceId Port: 80 - Id: !GetAtt Instance2.InstanceId Port: 80 ``` The following example registers two targets by instance ID into a QUIC or TCP\$1QUIC protocol target group. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: HTTP Port: 80 TargetType: instance VpcId: !Ref myVPC Targets: - Id: !GetAtt Instance1.InstanceId Port: 80 QuicServerId: 0xa1b2c3d4e5f65999 - Id: !GetAtt Instance2.InstanceId Port: 80 QuicServerId: 0xa1b2c3d4e5f65000 ``` ------ ## Deregister targets If demand on your application decreases, or if you need to service your targets, you can deregister targets from your target groups. Deregistering a target removes it from your target group, but does not affect the target otherwise. The load balancer stops routing traffic to a target as soon as it is deregistered. The target enters the `draining` state until in-flight requests have completed. ------ #### [ Console ] **To deregister targets** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. On the **Targets** tab, select the targets to remove. 1. Choose **Deregister**. ------ #### [ AWS CLI ] **To deregister targets** Use the [deregister-targets](https://docs.aws.amazon.com/cli/latest/reference/elbv2/deregister-targets.html) command. The following example deregisters two targets that were registered by instance ID. ``` aws elbv2 deregister-targets \ --target-group-arn target-group-arn \ --targets Id=i-1234567890abcdef0 Id=i-0abcdef1234567890 ``` ------ # Use an Application Load Balancer as a target of a Network Load Balancer Use Application Load Balancers as targets You can create a target group with a single Application Load Balancer as the target, and configure your Network Load Balancer to forward traffic to it. In this scenario, the Application Load Balancer takes over the load balancing decision as soon as traffic reaches it. This configuration combines the features of both load balancers and offers the following advantages: + You can use the layer 7 request-based routing feature of the Application Load Balancer in combination with features that the Network Load Balancer supports, such as endpoint services (AWS PrivateLink) and static IP addresses. + You can use this configuration for applications that need a single endpoint for multi-protocols, such as media services using HTTP for signaling and RTP to stream content. You can use this feature with an internal or internet-facing Application Load Balancer as the target of an internal or internet-facing Network Load Balancer. **Considerations** + You can only register one Application Load Balancer per target group. + To associate an Application Load Balancer as a target of a Network Load Balancer, the load balancers must be in the same VPC within the same account. + You can associate an Application Load Balancer as a target of up to two Network Load Balancers. To do this, register the Application Load Balancer with a separate target group for each Network Load Balancer. + Each Application Load Balancer that you register with a Network Load Balancer decreases the maximum number of targets per Availability Zone per Network Load Balancer by 50. You can disable cross-zone load balancing in both load balancers to minimize latency and avoid Regional data transfer charges. For more information, see [Quotas for your Network Load Balancers](load-balancer-limits.md). + When the target group type is `alb`, you can't modify the target group attributes. These attributes always use their default values. + After you register an Application Load Balancer as a target, you can't delete the Application Load Balancer until you deregister it from all target groups. + The communication between a Network Load Balancer and an Application Load Balancer always uses IPv4. **Topics** + [ ## Prerequisite ](#application-load-balancer-target-prerequisite) + [ ## Step 1: Create a target group of type alb ](#register-application-load-balancer-target) + [ ## Step 2: Create a Network Load Balancer and configure routing ](#configure-application-load-balancer-target) + [ ## Step 3: (Optional) Create a VPC endpoint service ](#enable-privatelink) ## Prerequisite If you don't already have an Application Load Balancer to use as a target, create the load balancer, its listeners, and its target groups. For more information, see [Create an Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) in the *User Guide for Application Load Balancers*. ## Step 1: Create a target group of type alb Step 1: Create the target group Create a target group of type `alb`. You can register your Application Load Balancer as a target when you create the target group or later on. ------ #### [ Console ] **To create a target group for an Application Load Balancer as a target** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose **Create target group**. 1. In the **Basic configuration** pane, for **Choose a target type**, choose **Application Load Balancer**. 1. For **Target group name**, enter a name for the target group. 1. For **Protocol**, only TCP is allowed. Select the **Port** for your target group. The port for this target group must match the listener port of the Application Load Balancer. If you choose a different port for this target group, you can update the listener port on the Application Load Balancer to match it. 1. For **VPC**, select the virtual private cloud (VPC) for the target group. This must be the same VPC used by the Application Load Balancer. 1. For **Health checks**, choose HTTP or HTTPS as the **Health check protocol**. Health checks are sent to the Application Load Balancer and forwarded to its targets using the specified port, protocol, and ping path. Ensure that your Application Load Balancer can receive these health checks by having a listener with a port and protocol that matches the health check port and protocol. 1. (Optional) Expand **Tags**. For each tag, choose **Add new tag** and enter a tag key and a tag value. 1. Choose **Next**. 1. If you are ready to register the Application Load Balancer, choose **Register now**, override the default port if needed, and select the Application Load Balancer. The Application Load Balancer must have a listener on the same port as the target group. You can add or edit a listener on this load balancer to match the target group port, or return to the previous step and change the port for the target group. If you are not ready to register the Application Load Balancer as a target, choose **Register later** and register the target later on. For more information, see [Register targets](target-group-register-targets.md#register-targets). 1. Choose **Create target group**. ------ #### [ AWS CLI ] **To create a target group of type alb** Use the [create-target-group](https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-target-group.html) command. The protocol must be TCP and the port must match the listener port of the Application Load Balancer. ``` aws elbv2 create-target-group \ --name my-target-group \ --protocol TCP \ --port 80 \ --target-type alb \ --vpc-id vpc-1234567890abcdef0 \ --tags Key=department,Value=123 ``` ------ #### [ CloudFormation ] **To create a target group of type alb** Define a resource of type [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html). The protocol must be TCP and the port must match the listener port of the Application Load Balancer. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: alb VpcId: !Ref myVPC Tags: - Key: 'department' Value: '123' Targets: - Id: !Ref myApplicationLoadBalancer Port: 80 ``` ------ ## Step 2: Create a Network Load Balancer and configure routing Step 2: Create the Network Load Balancer When you create the Network Load Balancer, you can configure the default action to forward traffic to the Application Load Balancer. ------ #### [ Console ] **To create the Network Load Balancer** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**. 1. Choose **Create load balancer**. 1. Under **Network Load Balancer**, choose **Create**. 1. **Basic configuration** 1. For **Load balancer name**, enter a name for your Network Load Balancer. 1. For **Scheme**, choose **Internet-facing** or **Internal**. An internet-facing Network Load Balancer routes requests from clients to targets over the internet. An internal Network Load Balancer routes requests to targets using private IP addresses. 1. For **Load balancer IP address type**, choose **IPv4** if your clients use IPv4 addresses to communicate with the Network Load Balancer or **Dualstack** if your clients use both IPv4 and IPv6 addresses to communicate with the Network Load Balancer. 1. **Network mapping** 1. For **VPC**, select the same VPC that you used for your Application Load Balancer. With an internet-facing load balancer, only VPCs with an internet gateway are available for selection. 1. For **Availability Zones and subnets**, select at least one Availability Zones, and select one subnet per zone. We recommend that you select the same Availability Zones that are enabled for your Application Load Balancer. This optimizes availability, scaling, and performance. (Optional) To use static IP addresses, choose **Use an Elastic IP address** in the **IPv4 settings** for each Availability Zone. With static IP addresses you can add certain IP addresses to an allow list for firewalls, or you can hard code IP addresses with clients. 1. **Security groups** We preselect the default security group for the load balancer VPC. You can select additional security groups as needed. If you don't have a security group that meets your needs, choose **create a new security group** to create one now. For more information, see [Create a security group](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html) in the *Amazon VPC User Guide*. **Warning** If you don't associate any security groups with your Network Load Balancer now, you can't associate them later on. **Warning** To utilize QUIC or TCP\$1QUIC listeners, your Network Load Balancer must have no security groups. 1. **Listeners and routing** 1. The default is a listener that accepts TCP traffic on port 80. Only TCP listeners can forward traffic to an Application Load Balancer target group. You must keep **Protocol** as **TCP**, but you can modify **Port** as needed. With this configuration, you can use HTTPS listeners on the Application Load Balancer to terminate TLS traffic. 1. For **Default action**, select the target group that you created in the previous step. 1. (Optional) Choose **Add listener tag** and enter a tag key and a tag value. 1. **Load balancer tags** (Optional) Expand **Load balancer tags**. Choose **Add new tag** and enter a tag key and a tag value. For more information, see [Tags](load-balancer-tags.md). 1. **Summary** Review your configuration and choose **Create load balancer**. ------ #### [ AWS CLI ] **To create the Network Load Balancer** Use the [create-load-balancer](https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-load-balancer.html) command. We recommend that you use the same Availability Zones that are enabled for your Application Load Balancer. ``` aws elbv2 create-load-balancer \ --name my-load-balancer \ --type network \ --scheme internal \ --subnets subnet-1234567890abcdef0 subnet-0abcdef1234567890 \ --security-groups sg-1111222233334444 ``` **To add a TCP listener** Use the [create-listener](https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-load-balancer.html) command to add a TCP listener. Only TCP listeners can forward traffic to an Application Load Balancer. For the default action, use the target group that you created in the previous step. ``` aws elbv2 create-listener \ --load-balancer-arn load-balancer-arn \ --protocol TCP \ --port 80 \ --default-actions Type=forward,TargetGroupArn=target-group-arn ``` ------ #### [ CloudFormation ] **To create the Network Load Balancer** Define a resource of type [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) and a resource of type [AWS::ElasticLoadBalancingV2::Listener](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-listener.html). Only TCP listeners can forward traffic to an Application Load Balancer. For the default action, use the target group that you created in the previous step. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-load-balancer Type: network Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup myTCPListener: Type: 'AWS::ElasticLoadBalancingV2::Listener' Properties: LoadBalancerArn: !Ref myLoadBalancer Protocol: TCP Port: 80 DefaultActions: - Type: forward TargetGroupArn: !Ref myTargetGroup ``` ------ ## Step 3: (Optional) Create a VPC endpoint service Step 3: (Optional) Enable private connectivity To use the Network Load Balancer that you set up in the previous step as an endpoint for private connectivity, you can enable AWS PrivateLink. This establishes a private connection to your load balancer as an endpoint service. **To create a VPC endpoint service using your Network Load Balancer** 1. On the navigation pane, choose **Load Balancers**. 1. Select the name of the Network Load Balancer to open its details page. 1. On the **Integrations** tab, expand **VPC Endpoint Services (AWS PrivateLink)**. 1. Choose **Create endpoint services** to open the **Endpoint services** page. For the remaining steps, see [Create an endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html#create-endpoint-service-nlb) in the *AWS PrivateLink Guide*. # Tag a target group for your Network Load Balancer Tag a target group Tags help you to categorize your target groups in different ways, for example, by purpose, owner, or environment. You can add multiple tags to each target group. Tag keys must be unique for each target group. If you add a tag with a key that is already associated with the target group, it updates the value of that tag. When you are finished with a tag, you can remove it. **Restrictions** + Maximum number of tags per resource—50 + Maximum key length—127 Unicode characters + Maximum value length—255 Unicode characters + Tag keys and values are case sensitive. Allowed characters are letters, spaces, and numbers representable in UTF-8, plus the following special characters: \$1 - = . \$1 : / @. Do not use leading or trailing spaces. + Do not use the `aws:` prefix in your tag names or values because it is reserved for AWS use. You can't edit or delete tag names or values with this prefix. Tags with this prefix do not count against your tags per resource limit. ------ #### [ Console ] **To manage the tags for a target group** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Choose the name of the target group to open its details page. 1. On the **Tags** tab, choose **Manage tags** and do one or more of the following: 1. To update a tag, enter new values for **Key** and **Value**. 1. To add a tag, choose **Add tag** and enter values for **Key** and **Value**. 1. To delete a tag, choose **Remove** next to the tag. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To add tags** Use the [add-tags](https://docs.aws.amazon.com/cli/latest/reference/elbv2/add-tags.html) command. The following example adds two tags. ``` aws elbv2 add-tags \ --resource-arns target-group-arn \ --tags "Key=project,value=lima" "Key=department,Value=digital-media" ``` **To remove tags** Use the [remove-tags](https://docs.aws.amazon.com/cli/latest/reference/elbv2/remove-tags.html) command. The following example removes the tags with the specified keys. ``` aws elbv2 remove-tags \ --resource-arns target-group-arn \ --tag-keys project department ``` ------ #### [ CloudFormation ] **To add tags** Update the [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html) resource to include the `Tags` property. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: ip VpcId: !Ref myVPC Tags: - Key: 'project' Value: 'lima' - Key: 'department' Value: 'digital-media' ``` ------ # Delete a target group for your Network Load Balancer Delete a target group You can delete a target group if it is not referenced by the forward actions of any listener rules. Deleting a target group does not affect the targets registered with the target group. If you no longer need a registered EC2 instance, you can stop or terminate it. ------ #### [ Console ] **To delete a target group** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, under **Load Balancing**, choose **Target Groups**. 1. Select the target group and choose **Actions**, **Delete**. 1. Choose **Delete**. ------ #### [ AWS CLI ] **To delete a target group** Use the [delete-target-group](https://docs.aws.amazon.com/cli/latest/reference/elbv2/delete-target-group.html) command. ``` aws elbv2 delete-target-group \ --target-group-arn target-group-arn ``` ------