Application Load Balancers - Elastic Load Balancing
AWS services or capabilities described in AWS documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with AWS services in China.

Application Load Balancers

A load balancer serves as the single point of contact for clients. Clients send requests to the load balancer, and the load balancer sends them to targets, such as EC2 instances. To configure your load balancer, you create target groups, and then register targets with your target groups. You also create listeners to check for connection requests from clients, and listener rules to route requests from clients to the targets in one or more target groups.

For more information, see How Elastic Load Balancing works in the Elastic Load Balancing User Guide.

Subnets for your load balancer

When you create an Application Load Balancer, you must specify one of the following types of subnets: Availability Zone, Local Zone, or Outpost.

Availability Zones

You must select at least two Availability Zone subnets. The following restrictions apply:

  • 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 8 free IP addresses per subnet. Your load balancer uses these IP addresses to establish connections with the targets. Depending on your traffic profile, the load balancer can scale higher and consume up to a maximum of 100 IP addresses distributed across all enabled subnets.

Local Zones

You can specify a one or more Local Zone subnets. The following restrictions apply:

  • You cannot use AWS WAF with the load balancer.

  • You cannot use a Lambda function as a target.

Outposts

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 instances on the Outpost for the load balancer nodes. The supported instances are shown in the table below. Initially, the instances are large instances. The load balancer scales as needed, from large to xlarge, xlarge to 2xlarge, and 2xlarge to 4xlarge. If you need additional capacity, the load balancer adds 4xlarge instances. 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 Personal 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 available: Lambda functions as targets, AWS WAF integration, sticky sessions, authentication support, and integration with AWS Global Accelerator.

An Application Load Balancer can be deployed on c5/c5d, m5/m5d, or r5/r5d instances on an Outpost. The following table shows the size and EBS volume per instance type that the load balancer can use on an Outpost:

Instance type and size EBS volume (GB)
c5/c5d
large 50
xlarge 50
2xlarge 50
4xlarge 100
m5/m5d
large 50
xlarge 50
2xlarge 100
4xlarge 100
r5/r5d
large 50
xlarge 100
2xlarge 100
4xlarge 100

Load balancer security groups

A security group acts as a firewall that controls the traffic allowed to and from your load balancer. You can choose the ports and protocols to allow for both inbound and outbound traffic.

The rules for the security groups that are associated with your load balancer must allow traffic in both directions on both the listener and the health check ports. Whenever you add a listener to a load balancer or update the health check port for a target group, you must review your security group rules to ensure that they allow traffic on the new port in both directions. For more information, see Recommended rules.

Load balancer state

A load balancer can be in one of the following states:

provisioning

The load balancer is being set up.

active

The load balancer is fully set up and ready to route traffic.

active_impaired

The load balancer is routing traffic but does not have the resources it needs to scale.

failed

The load balancer could not be set up.

Load balancer attributes

The following are the load balancer attributes:

access_logs.s3.enabled

Indicates whether access logs stored in Amazon S3 are enabled. The default is false.

access_logs.s3.bucket

The name of the Amazon S3 bucket for the access logs. This attribute is required if access logs are enabled. For more information, see Bucket permissions.

access_logs.s3.prefix

The prefix for the location in the Amazon S3 bucket.

deletion_protection.enabled

Indicates whether deletion protection is enabled. The default is false.

idle_timeout.timeout_seconds

The idle timeout value, in seconds. The default is 60 seconds.

routing.http.desync_mitigation_mode

Determines how the load balancer handles requests that might pose a security risk to your application. The possible values are monitor, defensive, and strictest. The default is defensive.

routing.http.drop_invalid_header_fields.enabled

Indicates whether HTTP headers with header fields that are not valid are removed by the load balancer (true), or routed to targets (false). The default is false. Elastic Load Balancing requires that message header names conform to the regular expression ^[A-z][-A-z0-9]*$, which describes all registered internet message headers. Each name starts with a letter, followed by zero or more alphanumeric characters or hyphens.

routing.http2.enabled

Indicates whether HTTP/2 is enabled. The default is true.

waf.fail_open.enabled

Indicates whether to allow a WAF-enabled load balancer to route requests to targets if it is unable to forward the request to AWS WAF. The value is true or false. The default is false.

IP address type

You can set the types of IP addresses that clients can use with your internet-facing load balancer. Clients must use IPv4 addresses with internal load balancers.

The following are the IP address types:

ipv4

Clients must connect to the load balancer using IPv4 addresses (for example, 192.0.2.1)

dualstack

Clients can connect to the load balancer using both IPv4 addresses (for example, 192.0.2.1) and IPv6 addresses (for example, 2001:0db8:85a3:0:0:8a2e:0370:7334).

When you enable dual-stack mode for the load balancer, Elastic Load Balancing provides an AAAA DNS record for the load balancer. Clients that communicate with the load balancer using IPv4 addresses resolve the A DNS record. Clients that communicate with the load balancer using IPv6 addresses resolve the AAAA DNS record.

The load balancer communicates with targets using IPv4 addresses, regardless of how the client communicates with the load balancer. Therefore, the targets do not need IPv6 addresses.

For more information, see IP address types for your Application Load Balancer.

Connection idle timeout

For each request that a client makes through a load balancer, the load balancer maintains two connections. The front-end connection is between a client and the load balancer. The back-end connection is between the load balancer and a target. The load balancer has a configured idle timeout period that applies to its connections. If no data has been sent or received by the time that the idle timeout period elapses, the load balancer closes the connection. To ensure that lengthy operations such as file uploads have time to complete, send at least 1 byte of data before each idle timeout period elapses, and increase the length of the idle timeout period as needed.

For back-end connections, we recommend that you enable the HTTP keep-alive option for your EC2 instances. You can enable HTTP keep-alive in the web server settings for your EC2 instances. If you enable HTTP keep-alive, the load balancer can reuse back-end connections until the keep-alive timeout expires. We also recommend that you configure the idle timeout of your application to be larger than the idle timeout configured for the load balancer.

By default, Elastic Load Balancing sets the idle timeout value for your load balancer to 60 seconds. Use the following procedure to set a different idle timeout value.

To update the idle timeout value using the console

  1. Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/.

  2. On the navigation pane, under LOAD BALANCING, choose Load Balancers.

  3. Select the load balancer.

  4. On the Description tab, choose Edit attributes.

  5. On the Edit load balancer attributes page, enter a value for Idle timeout, in seconds. The valid range is 1-4000.

  6. Choose Save.

To update the idle timeout value using the AWS CLI

Use the modify-load-balancer-attributes command with the idle_timeout.timeout_seconds attribute.

Deletion protection

To prevent your load balancer from being deleted accidentally, you can enable deletion protection. By default, deletion protection is disabled for your load balancer.

If you enable deletion protection for your load balancer, you must disable it before you can delete the load balancer.

To enable deletion protection using the console

  1. Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/.

  2. On the navigation pane, under LOAD BALANCING, choose Load Balancers.

  3. Select the load balancer.

  4. On the Description tab, choose Edit attributes.

  5. On the Edit load balancer attributes page, select Enable for Delete Protection, and then choose Save.

  6. Choose Save.

To disable deletion protection using the console

  1. Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/.

  2. On the navigation pane, under LOAD BALANCING, choose Load Balancers.

  3. Select the load balancer.

  4. On the Description tab, choose Edit attributes.

  5. On the Edit load balancer attributes page, clear Enable for Delete Protection, and then choose Save.

  6. Choose Save.

To enable or disable deletion protection using the AWS CLI

Use the modify-load-balancer-attributes command with the deletion_protection.enabled attribute.

Desync mitigation mode

Desync mitigation mode protects your application from issues due to HTTP Desync. The load balancer classifies each request based on its threat level, allows safe requests, and then mitigates risk as specified by the mitigation mode that you specify. The desync mitigation modes are monitor, defensive, and strictest. The default is the defensive mode, which provides durable mitigation against HTTP desync while maintaining the availability of your application. You can switch to strictest mode to ensure that your application receives only requests that comply with RFC 7230.

The http_desync_guardian library analyzes HTTP requests to prevent HTTP Desync attacks. For more information, see HTTP Desync Guardian on github.

Classifications

The classifications are as follows. For more information, see Classification reasons.

  • Compliant — Request complies with RFC 7230 and poses no known security threats.

  • Acceptable — Request does not comply with RFC 7230 but poses no known security threats.

  • Ambiguous — Request does not comply with RFC 7230 but poses a risk, as various web servers and proxies could handle it differently.

  • Severe — Request poses a high security risk. The load balancer blocks the request, serves a 400 response to the client, and closes the client connection.

If a request does not comply with RFC 7230, the load balancer increments the DesyncMitigationMode_NonCompliant_Request_Count metric. For more information, see Application Load Balancer metrics.

Modes

The following table describes how Application Load Balancers treat requests based on mode and classification.

Classification Monitor mode Defensive mode Strictest mode
Compliant Allowed Allowed Allowed
Acceptable Allowed Allowed Blocked
Ambiguous Allowed Allowed¹ Blocked
Severe Allowed Blocked Blocked

¹ Routes the requests but closes the client and target connections. You might incur additional charges if your load balancer receives a large number of Ambiguous requests in Defensive mode. This is because the increased number of new connections per second contributes to the Load Balancer Capacity Units (LCU) used per hour. You can use the NewConnectionCount metric to compare how your load balancer establishes new connections in Monitor mode and Defensive mode.

To update desync mitigation mode using the console

  1. Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/.

  2. On the navigation pane, under LOAD BALANCING, choose Load Balancers.

  3. Select the load balancer.

  4. On the Description tab, choose Edit attributes.

  5. For Desync mitigation mode, choose Monitor, Defensive, or Strictest.

  6. Choose Save.

To update desync mitigation mode using the AWS CLI

Use the modify-load-balancer-attributes command with the routing.http.desync_mitigation_mode attribute set to monitor, defensive, or strictest.

Application Load Balancers and AWS WAF

You can use AWS WAF with your Application Load Balancer to allow or block requests based on the rules in a web access control list (web ACL). For more information, see Working with web ACLs in the AWS WAF Developer Guide.

To check whether your load balancer integrates with AWS WAF, select your load balancer in the AWS Management Console and choose the Integrated services tab.

By default, if the load balancer cannot get a response from AWS WAF, it returns an HTTP 500 error and does not forward the request. If you need your load balancer to forward requests to targets even if it is unable to contact AWS WAF, you can enable the WAF fail open attribute.

To enable WAF fail open using the console

  1. Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/.

  2. On the navigation pane, under LOAD BALANCING, choose Load Balancers.

  3. Select the load balancer.

  4. On the Description tab, choose Edit attributes.

  5. For WAF fail open, choose Enable.

  6. Choose Save.

To enable WAF fail open using the AWS CLI

Use the modify-load-balancer-attributes command with the waf.fail_open.enabled attribute set to true.