Application Load Balancers

Considerations

• Your load balancer is most effective when you ensure that each enabled zone has at least one registered target.

• If you register targets in a zone but do not enable the zone, these registered targets do not receive traffic from the load balancer.

• If you enable multiple zones for your load balancer, the zones must be of the same type. For example, you can't enable both an Availability Zone and a Local Zone.

• You can specify a subnet that was shared with you.

• Elastic Load Balancing creates network interfaces in the subnets where you configured your load balancer. These network interfaces are reserved so that the load balancer can complete maintenance actions even when the subnet is running low on available IP addresses. They have the description "ENI reserved by ELB for subnet".

• Each subnet must be from a different Availability Zone.

• To ensure that your load balancer can scale properly, verify that each Availability Zone subnet for your load balancer has a CIDR block with at least a /27 bitmask (for example, 10.0.0.0/27) and at least eight free IP addresses per subnet. These eight IP addresses are required to allow the load balancer to scale out if needed. Your load balancer uses these IP addresses to establish connections with the targets. Without them your Application Load Balancer could experience difficulties with node replacement attempts, causing it to enter a failed state.

  Note: If an Application Load Balancers subnet runs out of usable IP addresses while attempting to scale, the Application Load Balancer will run with insufficient capacity. During this time, old nodes continue to serve traffic, but the stalled scaling attempt might cause 5xx errors or timeouts when attempting to establish a connection.

You can specify Local Zone subnets. The following features are not supported with local zone subnets:

• Lambda functions as targets

• Mutual TLS authentication

• AWS WAF integration

You can specify a single Outpost subnet. The following restrictions apply:

• You must have installed and configured an Outpost in your on-premises data center. You must have a reliable network connection between your Outpost and its AWS Region. For more information, see the AWS Outposts User Guide.

• The load balancer requires two large instances on the Outpost for the load balancer nodes. The supported instance types are shown in the following table. The load balancer scales as needed, resizing the nodes one size at a time (from large to xlarge, then xlarge to 2xlarge, and then 2xlarge to 4xlarge). After scaling the nodes to the largest instance size, if you need additional capacity, the load balancer adds 4xlarge instances as load balancer nodes. If you do not have sufficient instance capacity or available IP addresses to scale the load balancer, the load balancer reports an event to the AWS Health Dashboard and the load balancer state is active_impaired.

• You can register targets by instance ID or IP address. If you register targets in the AWS Region for the Outpost, they are not used.

• The following features are not supported:

  • AWS Global Accelerator integration

  • Lambda functions as targets

  • Mutual TLS authentication

  • Sticky sessions

  • User authentication

  • AWS WAF integration

  • Target optimizer

  • Health check logs

  • Connection logs

  • Capacity unit reservation

  • JWT verification

  • Automated target weights

  • FIPS security policies