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.
Contents
- Subnets for your load balancer
- Load balancer security groups
- Load balancer state
- Load balancer attributes
- IP address type
- Load balancer resource map
- Load balancer connections
- Cross-zone load balancing
- Deletion protection
- Desync mitigation mode
- Host header preservation
- Amazon WAF
- Create a load balancer
- Update Availability Zones
- Update security groups
- Update the address type
- Update tags
- Delete a load balancer
- Zonal shift
Subnets for your load balancer
When you create an Application Load Balancer, you must enable the zones that contain your targets. To enable a zone, specify a subnet in the zone. Elastic Load Balancing creates a load balancer node in each zone that you specify.
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.
Application Load Balancers support the following types of subnets.
Availability Zone subnets
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 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 will continue to serve traffic, but the stalled scaling attempt may cause 5xx errors or timeouts when attempting to establish a connection.
Local Zone subnets
You can specify one or more Local Zone subnets. The following restrictions apply:
-
You cannot use Amazon WAF with the load balancer.
-
You cannot use a Lambda function as a target.
-
You cannot use sticky sessions or application stickiness.
Outpost subnets
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 Amazon Region. For more information, see the Amazon 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 (fromlarge
toxlarge
, thenxlarge
to2xlarge
, and then2xlarge
to4xlarge
). After scaling the nodes to the largest instance size, if you need additional capacity, the load balancer adds4xlarge
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 Amazon Health Dashboardand the load balancer state is active_impaired
. -
You can register targets by instance ID or IP address. If you register targets in the Amazon Region for the Outpost, they are not used.
-
The following features are not available: Lambda functions as targets, Amazon WAF integration, sticky sessions, authentication support, and integration with Amazon 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 Enable access logs.
access_logs.s3.prefix
-
The prefix for the location in the Amazon S3 bucket.
client_keep_alive.seconds
-
The client keepalive value, in seconds. The default is 3600 seconds.
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.
ipv6.deny_all_igw_traffic
-
Blocks internet gateway (IGW) access to the load balancer, preventing unintended access to your internal load balancer through an internet gateway. It is set to
false
for internet-facing load balancers andtrue
for internal load balancers. This attribute does not prevent non-IGW internet access (such as, through peering, Transit Gateway, Amazon Direct Connect, or Amazon VPN). 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
, andstrictest
. The default isdefensive
. 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 isfalse
. Elastic Load Balancing requires that valid HTTP header names conform to the regular expression[-A-Za-z0-9]+
, as described in the HTTP Field Name Registry. Each name consists of alphanumeric characters or hyphens. Selecttrue
if you want HTTP headers that do not conform to this pattern, to be removed from requests. routing.http.preserve_host_header.enabled
-
Indicates whether the Application Load Balancer should preserve the
Host
header in the HTTP request and send it to targets without any change. The possible values aretrue
andfalse
. The default isfalse
. routing.http.x_amzn_tls_version_and_cipher_suite.enabled
-
Indicates whether the two headers (
x-amzn-tls-version
andx-amzn-tls-cipher-suite
), which contain information about the negotiated TLS version and cipher suite, are added to the client request before sending it to the target. Thex-amzn-tls-version
header has information about the TLS protocol version negotiated with the client, and thex-amzn-tls-cipher-suite
header has information about the cipher suite negotiated with the client. Both headers are in OpenSSL format. The possible values for the attribute aretrue
andfalse
. The default isfalse
. routing.http.xff_client_port.enabled
-
Indicates whether the
X-Forwarded-For
header should preserve the source port that the client used to connect to the load balancer. The possible values aretrue
andfalse
. The default isfalse
. routing.http.xff_header_processing.mode
-
Enables you to modify, preserve, or remove the
X-Forward-For
header in the HTTP request before the Application Load Balancer sends the request to the target. The possible values areappend
,preserve
, andremove
. The default isappend
.-
If the value is
append
, the Application Load Balancer adds the client IP address (of the last hop) to theX-Forward-For
header in the HTTP request before it sends it to targets. -
If the value is
preserve
, the Application Load Balancer preserves theX-Forward-For
header in the HTTP request, and sends it to targets without any change. -
If the value is
remove
, the Application Load Balancer removes theX-Forward-For
header in the HTTP request before it sends it to targets.
-
routing.http2.enabled
-
Indicates whether HTTP/2 is enabled. The default is
true
. waf.fail_open.enabled
-
Indicates whether to allow a Amazon WAF-enabled load balancer to route requests to targets if it is unable to forward the request to Amazon WAF. The possible values are
true
andfalse
. The default isfalse
.
Note
The routing.http.drop_invalid_header_fields.enabled
attribute was
introduced to offer HTTP desync protection. The
routing.http.desync_mitigation_mode
attribute was added to provide
more comprehensive protection from HTTP desync for your applications. You aren't
required to use both attributes and may choose either, depending on your
application's requirements.
IP address type
You can set the types of IP addresses that clients can use to access your internet-facing and internal load balancers.
Application Load Balancers support the following 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).
Considerations
-
The load balancer communicates with targets based on the IP address type of the target group.
-
When you enable dualstack 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.
-
Access to your internal dualstack load balancers through the internet gateway is blocked to prevent unintended internet access. However, this does not prevent non-IGW internet access (such as, through peering, Transit Gateway, Amazon Direct Connect, or Amazon VPN).
-
dualstack-without-public-ipv4
-
Clients must connect to the load balancer using IPv6 addresses (for example, 2001:0db8:85a3:0:0:8a2e:0370:7334).
Considerations
-
Application Load Balancer authentication only supports IPv4 when connecting to an Identity Provider (IdP) or Amazon Cognito endpoint. Without a public IPv4 address the load balancer cannot complete the authentication process, resulting in HTTP 500 errors.
-
For more information about IP address types, see IP address types for your Application Load Balancer.
Application Load Balancer resource map
The Application Load Balancer resource map provides an interactive display of your load balancer's architecture, including its associated listeners, rules, target groups, and targets. The resource map also highlights the relationships and routing paths between all resources, producing a visual representation of your load balancer's configuration.
To view your Application Load Balancer's resource map using the console
Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/
. -
On the navigation pane, choose Load Balancers.
-
Select the load balancer.
-
Choose the Resource map tab to display the load balancer's resource map.
Resource map components
Map views
There are two views available in the Application Load Balancer resource map: Overview, and Unhealthy Target Map. Overview is selected by default and displays all of your load balancer's resources. Selecting the Unhealthy Target Map view will only display the unhealthy targets and the resources associated to them.
The Unhealthy Target Map view can be used to troubleshoot targets that are failing health checks. For more information, see Troubleshoot unhealthy targets using the resource map.
Resource groups
The Application Load Balancer resource map contains four resource groups, one for each resource type. The resource groups are Listeners, Rules, Target groups, and Targets.
Resource tiles
Each resource within a group has its own tile, which displays details about that specific resource.
-
Hovering over a resource tile highlights the relationships between it and other resources.
-
Selecting a resource tile highlights the relationships between it and other resources, and displays additional details about that resource.
-
rule conditions: The conditions for each rule.
-
target group health summary: The number of registered targets for each health status.
-
target health status The targets current health status and description.
Note
You can turn off Show resource details to hide additional details within the resource map.
-
-
Each resource tile contains a link that, when selected, navigates to that resource's details page.
-
Listeners ‐ Select the listeners protocol:port. For example,
HTTP:80
-
Rules ‐ Select the rules action. For example,
Forward to target group
-
Target groups ‐ Select the target group name. For example,
my-target-group
-
Targets ‐ Select the targets ID. For example,
i-1234567890abcdef0
-
Export the resource map
Selecting Export gives you the option of exporting the current view of your Application Load Balancer's resource map as a PDF.
Load balancer connections
When processing a request, the load balancer maintains two connections: one connection with the client and one connection with a target. The connection between the load balancer and the client is also referred to as the front-end connection. The connection between the load balancer and the target is also referred to as the back-end connection.
Connection idle timeout
The connection idle timeout is the period of time an existing client or target connection can remain inactive, with no data being sent or received, before 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. We also recommend that you configure the idle timeout of your application to be larger than the idle timeout configured for the load balancer. Otherwise, if the application closes the TCP connection to the load balancer ungracefully, the load balancer might send a request to the application before it receives the packet indicating that the connection is closed. If this is the case, then the load balancer sends an HTTP 502 Bad Gateway error to the client.
By default, Elastic Load Balancing sets the idle timeout value for your load balancer to 60 seconds, or 1 minute. Use the following procedure to set a different idle timeout value.
To update the connection idle timeout value using the console
Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/
. -
On the navigation pane, choose Load Balancers.
-
Select the load balancer.
-
On the Attributes tab, choose Edit.
-
Under Traffic configuration, enter a value for Connection idle timeout. The valid range is 1 through 4000 seconds.
-
Choose Save changes.
To update the idle timeout value using the Amazon CLI
Use the modify-load-balancer-attributes command with the
idle_timeout.timeout_seconds
attribute.
HTTP client keepalive duration
The HTTP client keepalive duration is the maximum length of time an Application Load Balancer will maintain a persistent HTTP connection to a client. After the configured HTTP client keepalive duration has elapsed, the Application Load Balancer accepts one request and returns a response that gracefully closes the connection.
The type of response sent by the load balancer depends on the HTTP version used by
the client connection. For clients connected using HTTP 1.x, the load balancer sends
an HTTP header containing the field Connection: close
. For clients
connected using HTTP/2, the load balancer sends a GOAWAY
frame.
By default, Application Load Balancers set the HTTP client keepalive duration value to 3600 seconds, or 1 hour. The HTTP client keepalive duration cannot be turned off or set below the minimum of 60 seconds, but you can increase the HTTP client keepalive duration to a maximum of 604800 seconds, or 7 days. The Application Load Balancer begins the HTTP client keepalive duration period when an HTTP connection to a client is initially established. The duration period continues to run when there's no traffic, and does not reset until a new connection is established.
Note
When switching the IP address type of your Application Load Balancer to dualstack-without-public-ipv4
the load balancer waits for all active connections to complete. To decease the amount of time it
takes to switch your Application Load Balancers IP address type, consider lowering the HTTP client keepalive duration.
The Application Load Balancer assigns the HTTP client keepalive duration once during the initial connection. When updating the HTTP client keepalive duration, this can result in simultaneous connections with different HTTP client keepalive duration values. Existing connections will retain the HTTP client keepalive duration value applied during its initial connection, while any new connections will receive the updated HTTP client keepalive duration value.
To update the client keepalive duration value using the console
Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/
. -
On the navigation pane, choose Load Balancers.
-
Select the load balancer.
-
On the Attributes tab, choose Edit.
-
Under Traffic configuration, enter a value for HTTP client keep alive duration. The valid range is 60 through 604800 seconds.
-
Choose Save changes.
To update the client keepalive duration value using the Amazon CLI
Use the modify-load-balancer-attributes command with the
client_keep_alive.seconds
attribute.
Cross-zone load balancing
With Application Load Balancers, cross-zone load balancing is on by default and cannot be changed at the load balancer level. For more information, see the Cross-zone load balancing section in the Elastic Load Balancing User Guide.
Turning off cross-zone load balancing is possible at the target group level. For more information, see Turn off cross-zone load balancing.
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
Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/
. -
On the navigation pane, choose Load Balancers.
-
Select the load balancer.
-
On the Attributes tab, choose Edit.
-
Under Configuration, turn on Deletion protection.
-
Choose Save changes.
To disable deletion protection using the console
Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/
. -
On the navigation pane, choose Load Balancers.
-
Select the load balancer.
-
On the Attributes tab, choose Edit.
-
Under Configuration page, turn off Deletion protection.
-
Choose Save changes.
To enable or disable deletion protection using the Amazon 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
Classifications
The classifications are as follows:
-
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.
The classification for each request is included in the load balancer access logs. If the request does not comply, the access logs include a classification reason code. For more information, see Classification reasons.
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
Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/
. -
On the navigation pane, choose Load Balancers.
-
Select the load balancer.
-
On the Attributes tab, choose Edit.
-
Under Packet handling, for Desync mitigation mode, choose Defensive, Strictest, or Monitor.
-
Choose Save changes.
To update desync mitigation mode using the Amazon CLI
Use the modify-load-balancer-attributes command with the
routing.http.desync_mitigation_mode
attribute set to
monitor
, defensive
, or strictest
.
Host header preservation
When you enable the Preserve host header attribute,
the Application Load Balancer preserves the Host
header in the HTTP request, and sends the
header to targets without any modification. If the Application Load Balancer receives multiple
Host
headers, it preserves all of them. Listener rules are applied only
to the first Host
header received.
By default, when the Preserve host header attribute
is not enabled, the Application Load Balancer modifies the Host
header in the following manner:
When host header preservation is not enabled, and listener port
is a non-default port: When not using the default ports (ports 80 or 443)
we append the port number to the host header if it isn’t already appended by the client.
For example, the Host
header in the HTTP request with Host:
www.example.com
would be modified to Host: www.example.com:8080
,
if the listener port is a non-default port such as 8080
.
When host header preservation is not enabled, and the listener port is a default port (port 80 or 443): For default listener ports (either port 80 or 443), we do not append the port number to the outgoing host header. Any port number that was already in the incoming host header, is removed.
The following table shows more examples of how Application Load Balancers treat host headers in the HTTP request based on listener port.
Listener port | Example request | Host header in the request | Host header preservation is disabled (default behavior) | Host header preservation is enabled |
---|---|---|---|---|
Request is sent on default HTTP/HTTPS listener. | GET /index.html HTTP/1.1 Host: example.com |
example.com | example.com | example.com |
Request is sent on default HTTP listener and host header has a port (for example, 80 or 443). | GET /index.html HTTP/1.1 Host: example.com:80 |
example.com:80 | example.com | example.com:80 |
Request has an absolute path. | GET https://dns_name/index.html HTTP/1.1 Host:
example.com |
example.com | dns_name | example.com |
Request is sent on a non-default listener port (for example, 8080) | GET /index.html HTTP/1.1 Host: example.com |
example.com | example.com:8080 | example.com |
Request is sent on a non-default listener port and host header has port (for example, 8080). | GET /index.html HTTP/1.1 Host: example.com:8080 |
example.com:8080 | example.com:8080 | example.com:8080 |
To enable host header preservation using the console
Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/
. -
In the navigation pane, choose Load Balancers.
-
Select the load balancer.
-
On the Attributes tab, choose Edit.
-
Under Packet handling, turn on Preserve host header.
-
Choose Save changes.
To enable host header preservation using the Amazon CLI
Use the modify-load-balancer-attributes command with the
routing.http.preserve_host_header.enabled
attribute set to
true
.
Application Load Balancers and Amazon WAF
You can use Amazon 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 Amazon WAF Developer Guide.
By default, if the load balancer cannot get a response from Amazon 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 Amazon WAF, you can enable Amazon WAF fail open. To check whether your load balancer integrates with Amazon WAF, select your load balancer in the Amazon Web Services Management Console and choose the Integrated services tab.
Pre-defined web ACLs
When enabling Amazon WAF integration you can choose to automatically create a new web ACL with pre-defined rules. The pre-defined web ACL includes three Amazon managed rules which offer protections against the most common security threats.
-
AWSManagedRulesAmazonIpReputationList
‐ The Amazon IP reputation list rule group blocks IP addresses typically associated with bots or other threats. For more information, see Amazon IP reputation list managed rule group in the Amazon WAF Developer Guide. -
AWSManagedRulesCommonRuleSet
‐ The core rule set (CRS) rule group provides protection against exploitation of a wide range of vulnerabilities, including some of the high risk and commonly occurring vulnerabilities described in OWASP publications such as OWASP Top 10. For more information, see Core rule set (CRS) managed rule group in the Amazon WAF Developer Guide. -
AWSManagedRulesKnownBadInputsRuleSet
‐ The Known bad inputs rule group blocks request patterns that are known to be invalid and are associated with exploitation or discovery of vulnerabilities. For more information, see Known bad inputs managed rule group in the Amazon WAF Developer Guide.
To enable Amazon WAF using the console
Open the Amazon EC2 console at https://console.amazonaws.cn/ec2/
. -
On the navigation pane, choose Load Balancers.
-
Select the load balancer.
-
On the Integrations tab, expand Amazon Web Application Firewall (WAF), and choose Associate a WAF web ACL.
-
Under Web ACL, choose Auto-create pre-definied web ACL, or select an existing web ACL.
-
Under Rule action, choose Block, or Count.
-
Choose Confirm.
To enable Amazon WAF fail open using the Amazon CLI
Use the modify-load-balancer-attributes command with the
waf.fail_open.enabled
attribute set to true
.