Target Groups for Your Network Load Balancers

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.

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 Your Target Groups.

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_UDP

Ports: 1-65535

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 | TCP_UDP

instance | ip

HTTP | HTTPS | TCP

TLS

TCP | TLS

instance | ip

HTTP | HTTPS | TCP

UDP

UDP | TCP_UDP

instance

HTTP | HTTPS | TCP

TCP_UDP

TCP_UDP

instance

HTTP | HTTPS | 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 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)

100.64.0.0/10 (RFC 6598)

172.16.0.0/12 (RFC 1918)

192.168.0.0/16 (RFC 1918)

Important

You can't specify publicly routable IP addresses.

These supported CIDR blocks enable you to register the following with a target group:
ClassicLink instances, AWS resources that are addressable by IP address and port (for
example,
databases), and on-premises resources linked to AWS through AWS Direct Connect or
a software VPN connection.

When the target type is ip, the load balancer can support 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.
If you get port allocation errors, add more targets to the target group.

If the target group protocol is UDP or TCP_UDP, the target type must be instance.

Network Load Balancers do not support the lambda target type, only Application Load Balancers support
the lambda target type. For more information, see Lambda Functions as Targets
in the User Guide for Application Load Balancers.

Request Routing and IP Addresses

If you specify targets using an instance ID, traffic is routed to instances using
the
primary private IP address 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.

Source IP Preservation

If you specify targets using an instance ID, the source IP addresses of the clients
are preserved and provided to your applications.

If you specify targets by IP address, the source IP addresses are the private IP
addresses of the load balancer nodes. If you need the IP addresses of the clients,
enable Proxy Protocol and get the client IP addresses from the Proxy Protocol header.

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. You can register
each EC2 instance or IP address with the same target group multiple times using
different ports, which enables the load balancer to route requests to
microservices.

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.

If demand on your application 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 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 in the Amazon EC2 Auto Scaling User Guide.

Requirements

You cannot register instances by instance ID if they have the following instance types:
C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3, and T1. You can register
instances of these types by IP address.

You cannot register instances by instance ID if they are in a VPC that is peered to
the
load balancer VPC. 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.

Target Group Attributes

The following are the target group attributes:

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.

Deregistration Delay

When you deregister an instance, the load balancer stops creating new connections
to the instance. The load balancer uses connection draining to ensure that in-flight
traffic completes on the existing connections. If the deregistered instance stays
healthy and an existing connection is not idle, the load balancer can continue to
send traffic to the instance. To ensure that existing connections are closed, you
can ensure that the instance is unhealthy before you deregister it, or you can
periodically close client connections.

The initial state of a deregistering target is draining. 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.

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. The load balancer prepends a proxy protocol header to the TCP
data. It does not discard or overwrite any existing data, including any 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 your Network Load Balancer.

If you specify targets by IP address, 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 clients, enable Proxy Protocol and
get the client IP addresses from the Proxy Protocol header.

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.

VPC Endpoint Services

For traffic coming from service consumers through a VPC endpoint service, 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.

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.

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.

Sticky sessions are not supported with TLS listeners and TLS target groups.