Routing configuration Target type IP address type Protocol version Registered targets Target group attributes Routing algorithms Automatic Target Weights (ATW)Deregistration delay Slow start mode

Target groups for your Application Load Balancers

Target groups route requests to individual registered targets, such as EC2 instances, using the protocol and port number that you specify. You can register a target with multiple target groups. You can configure health checks on a per target group basis. Health checks are performed on all targets registered to a target group that is specified in a listener rule for your load balancer.

Each target group is used to route requests to one or more registered targets. When you create each listener rule, you specify a target group and conditions. When a rule condition is met, traffic is forwarded to the corresponding target group. 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. You can use each target group with only one load balancer. For more information, see Application 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.

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 support the following protocols and ports:

Protocols: HTTP, HTTPS
Ports: 1-65535

If a target group is configured with the HTTPS protocol or uses HTTPS health checks, the TLS connections to the targets use the security settings from the ELBSecurityPolicy-2016-08 policy. 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, and its targets are 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. Traffic that leaves AWS will not have these same protections, and additional steps may be needed to secure traffic further.

Target type

When you create a target group, you specify its target type, which determines the type of target you specify when registering targets with this target group. 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 IP addresses.
lambda: The target is a Lambda function.

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.

All of the supported CIDR blocks enable you to register the following targets with a target group:

Instances in a VPC that is peered to the load balancer VPC (same Region or different Region).
AWS resources that are addressable by IP address and port (for example, databases).
On-premises resources linked to AWS through AWS Direct Connect or a Site-to-Site VPN connection.

Note

For Application Load Balancers deployed within a Local Zone, the ip targets must be in the same Local Zone to receive traffic.

For more information, see What is AWS Local Zones?

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. 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. Each network interface can have its own security group.

If the target type of your target group is lambda, you can register a single Lambda function. When the load balancer receives a request for the Lambda function, it invokes the Lambda function. For more information, see Lambda functions as targets.

You can configure Amazon Elastic Container Service (Amazon ECS) as a target of your Application Load Balancer. For more information, see Creating an Application Load Balancer in the Amazon Elastic Container Service User Guide for AWS Fargate.

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.

Application Load Balancers support both IPv4 and IPv6 target groups. The default selection is IPv4.

Considerations

All IP addresses within a target group must have the same IP address type. For example, you can't register an IPv4 target with an IPv6 target group.
IPv6 target groups can only be used with dualstack load balancers.
IPv6 target groups support IP and Instance type targets.

Protocol version

By default, Application Load Balancers send requests to targets using HTTP/1.1. You can use the protocol version to send requests to targets using HTTP/2 or gRPC.

The following table summarizes the result for the combinations of request protocol and target group protocol version.

Request protocol	Protocol version	Result
HTTP/1.1	HTTP/1.1	Success
HTTP/2	HTTP/1.1	Success
gRPC	HTTP/1.1	Error
HTTP/1.1	HTTP/2	Error
HTTP/2	HTTP/2	Success
gRPC	HTTP/2	Success if targets support gRPC
HTTP/1.1	gRPC	Error
HTTP/2	gRPC	Success if a POST request
gRPC	gRPC	Success

Considerations for the gRPC protocol version

The only supported listener protocol is HTTPS.
The only supported action type for listener rules is forward.
The only supported target types are instance and ip.
The load balancer parses gRPC requests and routes the gRPC calls to the appropriate target groups based on the package, service, and method.
The load balancer supports unary, client-side streaming, server-side streaming, and bi-directional streaming.
You must provide a custom health check method with the format /package.service/method.
You must specify the gRPC status codes to use when checking for a successful response from a target.
You cannot use Lambda functions as targets.

Considerations for the HTTP/2 protocol version

The only supported listener protocol is HTTPS.
The only supported action type for listener rules is forward.
The only supported target types are instance and ip.
The load balancer supports streaming from clients. The load balancer does not support streaming to the targets.

Registered targets

Your load balancer serves as a single point of contact for clients and distributes incoming traffic across its healthy registered targets. 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 requests to a newly registered target as soon as the registration process completes and the target passes the initial health checks.

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

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.

Limits

You cannot register the IP addresses of another Application Load Balancer in the same VPC. If the other Application Load Balancer is in a VPC that is peered to the load balancer VPC, you can register its IP addresses.
You cannot register instances by instance ID if they are in a VPC that is peered to the load balancer VPC (same Region or different Region). You can register these instances by IP address.

Target group attributes

The following target group attributes are supported if the target group type is instance or ip:

deregistration_delay.timeout_seconds: The amount of time for Elastic Load Balancing to wait before deregistering a target. The range is 0–3600 seconds. The default value is 300 seconds.
load_balancing.algorithm.type: The load balancing algorithm determines how the load balancer selects targets when routing requests. The value is round_robin, least_outstanding_requests, or weighted_random. The default is round_robin.
load_balancing.algorithm.anomaly_mitigation: Only available when load_balancing.algorithm.type is weighted_random. Indicates whether anomaly mitigation is enabled. The value is on or off. The default is off.
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.
slow_start.duration_seconds: The time period, in seconds, during which the load balancer sends a newly registered target a linearly increasing share of the traffic to the target group. The range is 30–900 seconds (15 minutes). The default is 0 seconds (disabled).
stickiness.enabled: Indicates whether sticky sessions are enabled. The value is true or false. The default is false.
stickiness.app_cookie.cookie_name: The name of the application cookie. The application cookie name cannot have the following prefixes: AWSALB, AWSALBAPP, or AWSALBTG; they're reserved for use by the load balancer.
stickiness.app_cookie.duration_seconds: The application-based cookie expiration period, in seconds. After this period, the cookie is considered stale. The minimum value is 1 second and the maximum value is 7 days (604800 seconds). The default value is 1 day (86400 seconds).
stickiness.lb_cookie.duration_seconds: The duration-based cookie expiration period, in seconds. After this period, the cookie is considered stale. The minimum value is 1 second and the maximum value is 7 days (604800 seconds). The default value is 1 day (86400 seconds).
stickiness.type: The type of stickiness. The possible values are lb_cookie and app_cookie.
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 each target group independently contributes to DNS fail over. 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. he possible values are off, or an integer from 1 to the maximum number of targets. When off, DNS fail away is disabled, meaning each target group independently contributes to DNS fail over. The default is 1.
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 range is 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.

The following target group attribute is supported if the target group type is lambda:

lambda.multi_value_headers.enabled: Indicates whether the request and response headers exchanged between the load balancer and the Lambda function include arrays of values or strings. The possible values are true or false. The default value is false. For more information, see Multi-value headers.

Routing algorithms

A routing algorithm is the method used by the load balancer when determining which targets will receive requests. The round robin routing algorithm is used by default to route requests at the target group level. The least outstanding requests and weighted random routing algorithms are also available based on the needs of your application. A target group can only have one active routing algorithm at a time, however the routing algorithm can be updated whenever needed.

If you enable sticky sessions, the selected routing algorithm with be used for the initial target selection. Future requests from the same client will continue to be forwarded to the same target, bypassing the slected routing algorithm.

Round robin

The round robin routing algorithm routes requests evenly across healthy targets in the target group, in a sequential order.
This algorithm is commonly used when the requests being received are similar in complexity , the registered targets are similar in processing capability, or if you need to distribute requests equally among targets.

Least outstanding requests

The least outstanding requests routing algorithm routes requests to the targets with the lowest number of in progress requests.
This algorithm is commonly used when the requests being received vary in complexity, the registered targets vary in processing capability.
When a load balancer that supports HTTP/2 is using targets that only support HTTP/1.1, it converts the request to multiple HTTP/1.1 requests. In this configuration the least outstanding requests algorithm will treat each HTTP/2 request as multiple requests.
When using WebSockets, the target is selected using the least outstanding requests algorithm. Once selected, the load balancer creates a connection to the target and sends all messages over this connection.
The least outstanding requests routing algorithm can not be used with slow start mode.

Weighted random

The weighted random routing algorithm routes requests evenly across healthy targets in the target group, in a random order.
This algorithm supports Automatic Target Weights (ATW) anomaly mitigation.
The weighted random routing algorithm can not be used with slow start mode.

Modify the routing algorithm of a target group

You can modify the routing algorithm for your target group at any time.

New EC2 experience

To modify the routing algorithm using the new console

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
On the navigation pane, under Load Balancing, choose Target Groups.
Choose the name of the target group to open its details page.
On the target groups detail page, on the Attributes tab, choose Edit.
On the Edit target group attributes page, in the Traffic configuration section, under Load balancing algorithm, choose Round robin, Least outstanding requests, or Weighted random.
Choose Save changes.

Old EC2 experience

To modify the routing algorithm using the old console

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
On the navigation pane, under LOAD BALANCING, choose Target Groups.
Select the target group.
On the Description tab, choose Edit attributes.
On the Edit attributes page, for Load balancing algorithm, choose Round robin or Least outstanding requests, and then choose Save.

To modify the routing algorithm using the AWS CLI

Use the modify-target-group-attributes command with the load_balancing.algorithm.type attribute.

Automatic Target Weights (ATW)

Automatic Target Weights (ATW) constantly monitors the targets running your applications, detecting significant performance deviations, known as anomalies. ATW provides the ability to dynamically adjust the amount of traffic routed to targets, through real time data anomaly detection.

Automatic Target Weights (ATW) performs anomaly detection on every Application Load Balancer in your account automatically. When anomalous targets are identified, ATW can automatically attempt to stabilize them by reducing the amount of traffic they're routed, known as anomaly mitigation. ATW continuously optimizes traffic distribubtion to maximize per-target success rates while minimizing target group failure rates.

Considerations:

Anomaly detection currently monitors HTTP 5xx response codes coming from, and connection failures to, your targets. Anomaly detection is always on and cannot be turned off.
ATW is not supported when using Lambda as a target.

Anomaly detection

ATW anomaly detection monitors for any targets that are displaying a significant deviation in behavior from other targets in their target group. These deviations, called anomalies, are determined by comparing the percent errors of one target with the percent errors of other targets in the target group. These errors can be both connection errors and HTTP error codes. Targets reporting significantly higher than their peers are then considered anomalous.

Anomaly detection requires a minimum of three healthy targets in the target group. When a target is registered to a target group it has to first pass the health checks to start receiving traffic. Once the target is receiving target, ATW begins monitoring the target and continuously publishes the anomaly result. For targets without anomalies, the anomaly result is normal. For targets with anomalies, the anomaly result is anomalous.

ATW anomaly detection works independently from target group health checks. A target can be passing all target group health checks, but still be marked anomalous due to an elevated error rate. Targets becoming anomalous does not affect their target group health check status.

Anomaly detection status

ATW continuously publishes the status of the anomaly detections it performs on targets. You can view the current status at any time using the AWS Management Console or AWS CLI.

To view anomaly detection status using the console:

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
On the navigation pane, under Load Balancing, choose Target Groups.
Choose the name of the target group to open its details page.
On the target groups detail page, choose the Targets tab.
Within the Registered targets table, you can view each targets anomaly status in the Anomaly detection result column.

If no anomalies were detected, the result is normal.

If anomalies were detected, the result is anomalous.

To view anomaly detection results using the AWS CLI

Use the describe-target-health command with the Include.member.N attribute value set to AnomalyDetection.

Anomaly mitigation

Important

The anomaly mitigation function of ATW is only available when using the Weighted random routing algorithm.

ATW anomaly mitigation routes traffic away from anomalous targets automatically, giving them an opportunity to recover.

During mitigation:

ATW periodically adjusts the amount of traffic routed to anomalous targets. Currently, the period is every five seconds.
ATW reduces the amount of traffic routed to anomalous targets to the minimum amount required to perform anomaly mitigation.
Targets which are no longer detected as anomalous will gradually have more traffic routed to them until they reach parity with other normal targets in the target group.

Turn on ATW anomaly mitigation

You can turn on anomaly mitigation at any time.

To turn on anomaly mitigation:

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
On the navigation pane, under Load Balancing, choose Target Groups.
Choose the name of the target group to open its details page.
On the target groups detail page, on the Attributes tab, choose Edit.
On the Edit target group attributes page, in the Traffic configuration section, under Load balancing algorithm, ensure Weighted random is selected.

Note: When the weighted random algorithm is initially selected, anomaly detection is on by default.
Under Anomaly mitigation, ensure Turn on anomaly mitigation is selected.
Choose Save changes.

To turn on anomaly mitigation using the AWS CLI

Use the modify-target-group-attributes command with the load_balancing.algorithm.anomaly_mitigation attribute.

Anomaly mitigation status

Whenever ATW is performing mitigation on a target, you can view the current status at any time using the AWS Management Console or AWS CLI.

To view anomaly mitigation status using the console:

Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
On the navigation pane, under Load Balancing, choose Target Groups.
Choose the name of the target group to open its details page.
On the target groups detail page, choose the Targets tab.
Within the Registered targets table, you can view each targets anomaly mitigation status in the Mitigation in effect column.

If mitigation is not in progress, the status is yes.

If mitigation is in progress, the status is no.

To view anomaly mitigation status using the AWS CLI

Use the describe-target-health command with the Include.member.N attribute value set to AnomalyDetection.

Deregistration delay

Elastic Load Balancing stops sending requests to targets that are deregistering. By default, Elastic Load Balancing waits 300 seconds before completing the deregistration process, which can help in-flight requests to the target to complete. To change the amount of time that Elastic Load Balancing waits, update the deregistration delay value.

The initial state of a deregistering target is draining. After the deregistration delay elapses, the deregistration process completes and the state of the target is unused. If the target is part of an Auto Scaling group, it can be terminated and replaced.

If a deregistering target has no in-flight requests and no active connections, Elastic Load Balancing immediately completes the deregistration process, without waiting for the deregistration delay to elapse. However, even though target deregistration is complete, the status of the target is displayed as draining until the deregistration delay timeout expires. After the timeout expires, the target transitions to an unused state.

If a deregistering target terminates the connection before the deregistration delay elapses, the client receives a 500-level error response.

To update the deregistration delay value using the AWS CLI

Use the modify-target-group-attributes command with the deregistration_delay.timeout_seconds attribute.

Slow start mode

By default, a target starts to receive its full share of requests as soon as it is registered with a target group and passes an initial health check. Using slow start mode gives targets time to warm up before the load balancer sends them a full share of requests.

After you enable slow start for a target group, its targets enter slow start mode when they are considered healthy by the target group. A target in slow start mode exits slow start mode when the configured slow start duration period elapses or the target becomes unhealthy. The load balancer linearly increases the number of requests that it can send to a target in slow start mode. After a healthy target exits slow start mode, the load balancer can send it a full share of requests.

Considerations

When you enable slow start for a target group, the healthy targets registered with the target group do not enter slow start mode.
When you enable slow start for an empty target group and then register targets using a single registration operation, these targets do not enter slow start mode. Newly registered targets enter slow start mode only when there is at least one healthy target that is not in slow start mode.
If you deregister a target in slow start mode, the target exits slow start mode. If you register the same target again, it enters slow start mode when it is considered healthy by the target group.
If a target in slow start mode becomes unhealthy, the target exits slow start mode. When the target becomes healthy, it enters slow start mode again.
You cannot enable slow start mode when using the least outstanding requests or weighted random routing algorithms.

To update the slow start duration value using the AWS CLI

Use the modify-target-group-attributes command with the slow_start.duration_seconds attribute.

Warning Javascript is disabled or is unavailable in your browser.

To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Document Conventions

Delete a listener

Create a target group

Target groups for your Application Load Balancers

Contents

Routing configuration

Target type

Important

Note

IP address type

Considerations

Protocol version

Considerations for the gRPC protocol version

Considerations for the HTTP/2 protocol version

Registered targets

Limits

Target group attributes

Routing algorithms

Round robin

Least outstanding requests

Weighted random

Modify the routing algorithm of a target group

To modify the routing algorithm using the new console

To modify the routing algorithm using the old console

To modify the routing algorithm using the AWS CLI

Automatic Target Weights (ATW)

Considerations:

Anomaly detection

Anomaly detection status

To view anomaly detection status using the console:

To view anomaly detection results using the AWS CLI

Anomaly mitigation

Important

During mitigation:

Turn on ATW anomaly mitigation

To turn on anomaly mitigation:

To turn on anomaly mitigation using the AWS CLI

Anomaly mitigation status

To view anomaly mitigation status using the console:

To view anomaly mitigation status using the AWS CLI

Deregistration delay

To update the deregistration delay value using the new EC2 experience

To update the deregistration delay value using the old EC2 experience

To update the deregistration delay value using the AWS CLI

Slow start mode

Considerations

To update the slow start duration value using the new EC2 experience

To update the slow start duration value using the old EC2 experience

To update the slow start duration value using the AWS CLI