Edit target group attributes for your Network Load Balancer
After you create a target group for your Network Load Balancer, you can edit its target group attributes.
Target group attributes
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 and TCP_UDP 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_UDP): 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 Amazon PrivateLink. The source IP address of the Amazon PrivateLink traffic is always the private IP address of the Network Load Balancer.
-
Client IP preservation is not supported when a target group contains Amazon 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-Forrequest 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.
-
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.
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.
If you enable the target group attribute for connection termination, connections to deregistered targets are closed shortly after the end of the deregistration timeout.
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.
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_UDP: 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, 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.
| Field | Length (in octets) | Description |
|---|---|---|
|
Type |
1 |
PP2_TYPE_AWS (0xEA) |
|
Length |
2 |
The length of value |
|
Value |
1 |
PP2_SUBTYPE_AWS_VPCE_ID (0x01) |
| variable (value length minus 1) | The ID of the endpoint |
For an example that parses TLV type 0xEA, see 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
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.
-
Sticky sessions are not supported for TLS listeners.
Cross-zone load balancing for target groups
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, bit 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 in the Amazon 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
instanceorip. If the target group type isalb, 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.
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.
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.