

# Target groups for your Gateway Load Balancers
<a name="target-groups"></a>

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 that's specified in the listener rule. You can create different target groups for different types of requests.

You define health check settings for your Gateway 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 Gateway Load Balancer continually monitors the health of all targets registered with the target group that are in an Availability Zone enabled for the Gateway Load Balancer. The Gateway Load Balancer routes requests to the registered targets that are healthy. For more information, see [Health checks for Gateway Load Balancer target groups](health-checks.md).

**Topics**
+ [

## Routing configuration
](#target-group-routing-configuration)
+ [

## Target type
](#target-type)
+ [

## Registered targets
](#registered-targets)
+ [

## Target group attributes
](#target-group-attributes)
+ [Create a target group](create-target-group.md)
+ [Configure health checks](health-checks.md)
+ [Edit target group attributes](edit-target-group-attributes.md)
+ [Register targets](target-group-register-targets.md)
+ [Tag a target group](target-group-tags.md)
+ [Delete a target group](delete-target-group.md)

## Routing configuration
<a name="target-group-routing-configuration"></a>

Target groups for Gateway Load Balancers support the following protocol and port:
+ **Protocol**: GENEVE
+ **Port**: 6081

The Gateway Load Balancer encapsulates the original packets using GENEVE. The GENEVE header uses a Type-Length-Value (TLV) format to store information, using Option Class 0x0108. Appliances must decapsulate the TLV pairs to process the original packets. For more information, see the following blog post: [Integrate your appliance with a Gateway Load Balancers](https://aws.amazon.com/blogs/networking-and-content-delivery/integrate-your-custom-logic-or-appliance-with-aws-gateway-load-balancer/).

## Target type
<a name="target-type"></a>

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 cannot 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.

When the target type is `ip`, you can specify IP addresses from one of the following CIDR blocks:
+ The subnets of the VPC for the target group
+ 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.

## Registered targets
<a name="registered-targets"></a>

Your Gateway 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 Gateway Load Balancer. You can register each target with one or more target groups.

If demand increases, you can register additional targets with one or more target groups in order to handle the demand. The Gateway Load Balancer starts routing traffic to a newly registered target as soon as the registration process completes.

If demand decreases, or 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 Gateway 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.

## Target group attributes
<a name="target-group-attributes"></a>

You can use the following attributes with target groups:

`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.

`stickiness.enabled`  
Indicates whether configurable flow stickiness is enabled for the target group. The possible values are `true` or `false`. The default is false. When the attribute is set to `false`, 5\$1tuple is used. 

`stickiness.type`  
Indicates the type of the flow stickiness. The possible values for target groups associated to Gateway Load Balancers are:  
+ `source_ip_dest_ip`
+ `source_ip_dest_ip_proto`

`target_failover.on_deregistration`  
Indicates how the Gateway Load Balancer handles existing flows when a target is deregistered. The possible values are `rebalance` and `no_rebalance`. The default is `no_rebalance`. The two attributes (`target_failover.on_deregistration` and `target_failover.on_unhealthy`) can't be set independently. The value you set for both attributes must be the same. 

`target_failover.on_unhealthy`  
Indicates how the Gateway Load Balancer handles existing flows when a target is unhealthy. The possible values are `rebalance` and `no_rebalance`. The default is `no_rebalance`. The two attributes (`target_failover.on_deregistration` and `target_failover.on_unhealthy`) cannot be set independently. The value you set for both attributes must be the same. 

For more information, see [Edit target group attributes](edit-target-group-attributes.md).

# Create a target group for your Gateway Load Balancer
<a name="create-target-group"></a>

You register targets for your Gateway Load Balancer using a 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 [Listeners](gateway-listeners.md).

You can add or remove targets from your target group at any time. For more information, see [Register targets](target-group-register-targets.md). You can also modify the health check settings for your target group. For more information, see [Modify health check settings](health-checks.md#modify-health-check-settings).

**To create a target group 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, under **Load Balancing**, choose **Target Groups**.

1. Choose **Create target group**.

1. **Basic configuration**

   1. For **Choose a target type**, select **Instances** to specify targets by instance ID, or select **IP addresses** to specify targets by IP address.

   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. Verify that **Protocol** is `GENEVE` and **Port** is `6081`. No other protocols or ports are supported.

   1. For **VPC**, select the virtual private cloud (VPC) with the security appliance instances to include in your target group.

1. (Optional) For **Health checks**, modify the settings and advanced settings as needed. 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 [Health checks for Gateway Load Balancer target groups](health-checks.md).

1. (Optional) Expand **Tags** and add the tags that you need.

1. Choose **Next**.

1. For **Register targets** add one or more targets as follows:
   + If the target type is **Instances**, select one or more instances, enter one or more ports, and then choose **Include as pending below**.
   + If the target type is **IP addresses**, select the network, enter the IP address and ports, and then choose **Include as pending below**.

1. Choose **Create target group**.

**To create a target group using the AWS CLI**  
Use the [create-target-group](https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-target-group.html) command to create the target group, the [add-tags](https://docs.aws.amazon.com/cli/latest/reference/elbv2/add-tags.html) command to tag your target group, and the [register-targets](https://docs.aws.amazon.com/cli/latest/reference/elbv2/register-targets.html) command to add targets.

# Health checks for Gateway Load Balancer target groups
<a name="health-checks"></a>

You register your targets with one or more target groups. Your Gateway Load Balancer starts routing requests to a newly registered target as soon as the registration process completes. It can take a few minutes for the registration process to complete and for health checks to start.

The Gateway Load Balancer periodically sends a request to each registered target to check its status. After each health check is complete, the Gateway Load Balancer closes the connection that was established for the health check.

## Health check settings
<a name="health-check-settings"></a>

You configure active health checks for the targets in a target group by using the following settings. If the health checks exceed the specified number of **UnhealthyThresholdCount** consecutive failures, the Gateway Load Balancer takes the target out of service. When the health checks exceed the specified number of **HealthyThresholdCount** consecutive successes, the Gateway Load Balancer puts the target back in service.


| Setting | Description | 
| --- | --- | 
| **HealthCheckProtocol** |  The protocol that the load balancer uses when performing health checks on targets. The possible protocols are HTTP, HTTPS, and TCP. The default is TCP.  | 
| **HealthCheckPort** |  The port that Gateway Load Balancer uses when performing health checks on targets. The range is 1 to 65535. The default is 80.  | 
| **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 to 120. The default is 5.  | 
| **HealthCheckIntervalSeconds** |  The approximate amount of time, in seconds, between health checks of an individual target. The range is 5 to 300. The default is 10 seconds. This value must be greater than or equal to **HealthCheckTimeoutSeconds**.  Health checks for Gateway Load Balancers are distributed and use a consensus mechanism to determine target health. Therefore, you should expect target appliances to receive several health checks within the configured time interval.   | 
| **HealthyThresholdCount** |  The number of consecutive successful health checks required before considering an unhealthy target healthy. The range is 2 to 10. The default is 5.  | 
| **UnhealthyThresholdCount** |  The number of consecutive failed health checks required before considering a target unhealthy. The range is 2 to 10. The default is 2.  | 
| **Matcher** |  [HTTP/HTTPS health checks] The HTTP codes to use when checking for a successful response from a target. This value must be 200-399.  | 

## Target health status
<a name="target-health-states"></a>

Before the Gateway 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 Gateway Load Balancer.

The following table describes the possible values for the health status of a registered target.


| Value | Description | 
| --- | --- | 
| `initial` |  The Gateway 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 or failed the health check. Related reason code: `Target.FailedHealthChecks`  | 
| `unused` |  The target is not registered with a target group, the target group is not used in a listener rule, the target is in an Availability Zone that is not enabled, or the target is in the stopped or terminated state. Related reason codes: `Target.NotRegistered` \$1 `Target.NotInUse` \$1 `Target.InvalidState` \$1 `Target.IpUnusable`  | 
| `draining` |  The target is deregistering and connection draining is in process. Related reason code: `Target.DeregistrationInProgress`  | 
| `unavailable` |  Target health is unavailable. Related reason code: `Elb.InternalError`  | 

## Health check reason codes
<a name="target-health-reason-codes"></a>

If the status of a target is any value other than `Healthy`, the API returns a reason code and a description of the issue, and the console displays the same description. Reason codes that begin with `Elb` originate on the Gateway 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 Gateway Load Balancer Target is in an Availability Zone that is not enabled for the Gateway Load Balancer  | 
| `Target.NotRegistered` |  Target is not registered to the target group  | 

## Gateway Load Balancer target failure scenarios
<a name="failure-scenarios"></a>

**Existing flows**: By default, existing flows go to the same target unless the flow times out or is reset, regardless of the health and registration status of the target. This approach facilitates connection draining, and accommodates 3rd party firewalls that are sometimes unable to respond to health checks due to high CPU usage. For more information, see [Target failover](edit-target-group-attributes.md#target-failover).

**New flows**: New flows are sent to a healthy target. When a load balancing decision for a flow has been made, the Gateway Load Balancer will send the flow to the same target even if that target becomes unhealthy, or other targets become healthy.

When all targets are unhealthy, the Gateway Load Balancer picks a target at random and forwards traffic to it for the life of the flow, until it is either reset or has timed out. Because traffic is being forwarded to an unhealthy target, traffic is dropped until that target becomes healthy again.

**TLS 1.3**: 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.

**Cross-zone load balancing**: By default, load balancing across Availability Zones is disabled. If load balancing across zones is enabled, each Gateway Load Balancer is able to see all targets in all Availability Zones, and they are all treated the same, regardless of their zone. 

Load balancing and health check decisions are always independent among zones. Even when load balancing across zones is enabled, the behavior for existing flows and new flows is the same as described above. For more information, see [Cross-zone load balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing) in the *Elastic Load Balancing User Guide*.

## Check the health of your targets
<a name="check-target-health"></a>

You can check the health status of the targets registered with your target groups.

**To check the health of your targets 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, under **Load Balancing**, choose **Target Groups**.

1. Choose the name of the target group to open its details page.

1. On the **Targets** tab, the **Status** column indicates the status of each target.

1. If the target status is any value other than `Healthy`, the **Status details** column contains more information.

**To check the health of your targets using the AWS CLI**  
Use the [describe-target-health](https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-target-health.html) command. The output of this command contains the target health state. It includes a reason code if the status is any value other than `Healthy`.

**To receive email notifications about unhealthy targets**  
Use CloudWatch alarms to trigger a Lambda function to send details about unhealthy targets. For step-by-step instructions, see the following blog post: [Identifying unhealthy targets of your load balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/identifying-unhealthy-targets-of-elastic-load-balancer/).

## Modify health check settings
<a name="modify-health-check-settings"></a>

You can modify some of the health check settings for your target group.

**To modify health check settings for a target group 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, under **Load Balancing**, choose **Target Groups**.

1. Choose the name of the target group to open its details page.

1. On the **Group details** tab, in the **Health check settings** section, choose **Edit**.

1. On the **Edit health check settings** page, modify the settings as needed, and then choose **Save changes**.

**To modify health check settings for a target group using the AWS CLI**  
Use the [modify-target-group](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group.html) command.

# Edit target group attributes for your Gateway Load Balancer
<a name="edit-target-group-attributes"></a>

After you create a target group for your Gateway Load Balancer, you can edit its target group attributes.

**Topics**
+ [

## Target failover
](#target-failover)
+ [

## Deregistration delay
](#deregistration-delay)
+ [

## Flow stickiness
](#flow-stickiness)

## Target failover
<a name="target-failover"></a>

With target failover, you specify how the Gateway Load Balancer handles existing traffic flows after a target becomes unhealthy or when the target is deregistered. By default, the Gateway Load Balancer continues to send existing flows to the same target, even if the target has failed or is deregistered. You can manage these flows by either rehashing them (`rebalance`) or leaving them at the default state (`no_rebalance`). 

**No rebalance**:  
The Gateway Load Balancer continues to send existing flows to failed or drained targets. If the Gateway Load Balancer cannot reach the target, the traffic is dropped.  
However, new flows are sent to healthy targets. This is the default behavior.

**Rebalance**:  
The Gateway Load Balancer rehashes existing flows and sends them to healthy targets after the deregistration delay timeout.   
For deregistered targets, the minimum time to failover will depend on the deregistration delay. The target is not marked as deregistered until deregistration delay is completed.  
For unhealthy targets, the minimum time to failover will depend on the target group health check configuration (interval times threshold). This is the minimum time before which a target is flagged as unhealthy. After this time, the Gateway Load Balancer can take several minutes due to additional propagation time and TCP retransmission backoff before it reroutes new flows to healthy targets. 

**To update the target failover attribute using the console**

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 **Group details** page, in the **Attributes** section, choose **Edit**.

1. On the **Edit attributes** page, change the value of **Target failover** as needed.

1. Choose **Save changes**.

**To update the target failover attribute using the AWS CLI**  
Use the [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) command, with the following key value pairs: 
+ Key=`target_failover.on_deregistration` and Value= `no_rebalance` (default) or `rebalance`
+ Key=`target_failover.on_unhealthy` and Value= `no_rebalance` (default) or `rebalance`

**Note**  
Both attributes (`target_failover.on_deregistration` and `target_failover.on_unhealthy`) must have the same value. 

## Deregistration delay
<a name="deregistration-delay"></a>

When you deregister a target, the Gateway Load Balancer manages flows to that target as follows: 

**New flows**  
The Gateway Load Balancer stops sending new flows.

**Existing flows**  
The Gateway Load Balancer handles existing flows based on the protocol:  
+ **TCP**: Existing flows are closed if they are idle for more than 350 seconds.
+ **Other protocols**: Existing flows are closed if they are idle for more than 120 seconds.

To help drain existing flows, you can enable flow rebalancing for your target group. For more information, see [Target failover](#target-failover).

A deregistered target shows that it is `draining` until the timeout expires. After the deregistration delay timeout expires, the target transitions to an `unused` state.

**To update the deregistration delay attribute using the console**

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 **Group details** page, in the **Attributes** section, choose **Edit**.

1. On the **Edit attributes** page, change the value of **Deregistration delay** as needed.

1. Choose **Save changes**.

**To update the deregistration delay attribute using the AWS CLI**  
Use the [modify-target-group-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html) command.

## Flow stickiness
<a name="flow-stickiness"></a>

By default, the Gateway Load Balancer maintains stickiness of flows to a specific target appliance using 5-tuple (for TCP/UDP flows). 5-tuple includes source IP, source port, destination IP, destination port, and transport protocol. You can use the stickiness type attribute to modify the default (5-tuple) and choose either 3-tuple (source IP, destination IP, and transport protocol) or 2-tuple (source IP and destination IP).

**Flow stickiness considerations**
+ Flow stickiness is configured and applied at the target group level, and it applies to all traffic that goes to the target group.
+ 2-tuple and 3-tuple flow stickiness are not supported when AWS Transit Gateway appliance mode is turned on. To use appliance mode on your AWS Transit Gateway, use 5-tuple flow stickiness on your Gateway Load Balancer
+ Flow stickiness can lead to uneven distribution of connections and flows, which can impact the availability of the target. It is recommended that you terminate or drain all existing flows before modifying the stickiness type of the target group.

**To update the flow stickiness attribute using the console**

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 **Group details** page, in the **Attributes** section, choose **Edit**.

1. On the **Edit attributes** page, change the value of **Flow stickiness** as needed.

1. Choose **Save changes**.

**To update the flow stickiness attribute using the AWS CLI**  
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` and `stickiness.type` target group attributes.

# Register targets for your Gateway Load Balancer
<a name="target-group-register-targets"></a>

When your target is ready to handle requests, you register it with one or more target groups. You can register targets by instance ID or by IP address. The Gateway Load Balancer starts routing requests to the target as soon as the registration process completes and the target passes 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 Gateway Load Balancer target groups](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 Gateway 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.

**Topics**
+ [

## Considerations
](#register-target-groups-considerations)
+ [

## Target security groups
](#target-security-groups)
+ [

## Network ACLs
](#network-acls)
+ [

## Register targets by instance ID
](#register-instances)
+ [

## Register targets by IP address
](#register-ip-addresses)
+ [

## Deregister targets
](#deregister-targets)

## Considerations
<a name="register-target-groups-considerations"></a>
+ Each target group must have at least one registered target in each Availability Zone that is enabled for the Gateway Load Balancer.
+ The target type of your target group determines how you register targets with that target group. For more information, see [Target type](target-groups.md#target-type).
+ You can't register targets across an inter-Region VPC peering.
+ You can't register instances by instance ID across an intra-Region VPC peering, but you can register them by IP address.

## Target security groups
<a name="target-security-groups"></a>

When you register EC2 instances as targets, you must ensure that the security groups for these instances allow inbound and outbound traffic on port 6081.

Gateway Load Balancers do not have associated security groups. Therefore, the security groups for your targets must use IP addresses to allow traffic from the load balancer.

## Network ACLs
<a name="network-acls"></a>

When you register EC2 instances as targets, you must ensure that the network access control lists (ACL) for the subnets for your instances allow traffic on port 6081. The default network ACL for a VPC allows all inbound and outbound traffic. If you create custom network ACLs, verify that they allow the appropriate traffic.

## Register targets by instance ID
<a name="register-instances"></a>

An instance must be in the `running` state when you register it.

**To register targets by instance ID using the console**

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, choose **Register targets**.

1. Select the instances, and then choose **Include as pending below**.

1. When you are finished adding instances, choose **Register pending targets**.

**To register targets by instance ID using the AWS CLI**  
Use the [register-targets](https://docs.aws.amazon.com/cli/latest/reference/elbv2/register-targets.html) command with the IDs of the instances.

## Register targets by IP address
<a name="register-ip-addresses"></a>

An IP address that you register must be from one of the following CIDR blocks:
+ The subnets of the VPC for the target group
+ 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)

**To register targets by IP address using the console**

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. Chose the name of the target group to open its details page.

1. On the **Targets** tab, choose **Register targets**.

1. Choose the network, IP addresses, and ports, and then choose **Include as pending below**.

1. When you are finished specifying addresses, choose **Register pending targets**.

**To register targets by IP address using the AWS CLI**  
Use the [register-targets](https://docs.aws.amazon.com/cli/latest/reference/elbv2/register-targets.html) command with the IP addresses of the targets.

## Deregister targets
<a name="deregister-targets"></a>

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).

**To deregister targets using the console**

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. Select the targets and then choose **Deregister**.

**To deregister targets using the AWS CLI**  
Use the [deregister-targets](https://docs.aws.amazon.com/cli/latest/reference/elbv2/deregister-targets.html) command to remove targets.

# Tag a target group for your Gateway Load Balancer
<a name="target-group-tags"></a>

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. 

**To update the tags for a target group using the console**

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. When you have finished updating tags, choose **Save changes**.

**To update the tags for a target group using the AWS CLI**  
Use the [add-tags](https://docs.aws.amazon.com/cli/latest/reference/elbv2/add-tags.html) and [remove-tags](https://docs.aws.amazon.com/cli/latest/reference/elbv2/remove-tags.html) commands.

# Delete a target group for your Gateway Load Balancer
<a name="delete-target-group"></a>

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.

**To delete a target group 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, under **Load Balancing**, choose **Target Groups**.

1. Select the target group and choose **Actions**, **Delete**.

1. When prompted for confirmation, choose **Yes, delete**.

**To delete a target group using the AWS CLI**  
Use the [delete-target-group](https://docs.aws.amazon.com/cli/latest/reference/elbv2/delete-target-group.html) command.