# 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](load-balancer-target-groups.md), and then register targets with your target groups. You also create [listeners](load-balancer-listeners.md) 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](https://docs.amazonaws.cn/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html) in the *Elastic Load Balancing User Guide*.
**Topics**
+ [Subnets for your load balancer](#subnets-load-balancer)
+ [Load balancer security groups](#load-balancer-security-groups)
+ [Load balancer state](#load-balancer-state)
+ [Load balancer attributes](#load-balancer-attributes)
+ [IP address type](#ip-address-type)
+ [Application Load Balancer IP Address Management](#w2aab7c21)
+ [IPAM IP address pools](#ip-pools)
+ [Load balancer connections](#load-balancer-connections)
+ [Cross-zone load balancing](#cross-zone-load-balancing)
+ [DNS name](#dns-name)
+ [Create a load balancer](create-application-load-balancer.md)
+ [Update Availability Zones](load-balancer-subnets.md)
+ [Update security groups](load-balancer-update-security-groups.md)
+ [Update the IP address type](load-balancer-ip-address-type.md)
+ [Update the IPAM IP address pools](load-balancer-ip-pools.md)
+ [Edit load balancer attributes](edit-load-balancer-attributes.md)
+ [Tag a load balancer](load-balancer-tags.md)
+ [Delete a load balancer](load-balancer-delete.md)
+ [View the resource map](view-resource-map.md)
+ [Zonal shift](zonal-shift.md)
+ [LCU reservations](capacity-unit-reservation.md)
+ [Load balancer integrations](load-balancer-integrations.md)
## 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.
+ 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".
Application Load Balancers support the following types of subnets.
**Topics**
+ [Availability Zone subnets](#availability-zones)
+ [Local Zone subnets](#local-zones)
+ [Outpost subnets](#outposts)
### 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 continue to serve traffic, but the stalled scaling attempt might cause 5xx errors or timeouts when attempting to establish a connection.
### Local Zone subnets
You can specify Local Zone subnets. The following features are not supported with local zone subnets:
+ Lambda functions as targets
+ Mutual TLS authentication
+ Amazon WAF integration
### 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](https://docs.amazonaws.cn/outposts/latest/userguide/).
+ 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 [Amazon Health Dashboard](https://docs.amazonaws.cn/health/latest/ug/getting-started-health-dashboard.html) and 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 supported:
+ Amazon Global Accelerator integration
+ Lambda functions as targets
+ Mutual TLS authentication
+ Sticky sessions
+ User authentication
+ Amazon WAF integration
+ Target optimizer
+ Health check logs
+ Connection logs
+ Capacity unit reservation
+ JWT verification
+ Automated target weights
+ FIPS security policies
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-update-security-groups.md#security-group-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
You can configure your Application Load Balancer by editing its attributes. For more information, see [Edit load balancer attributes](edit-load-balancer-attributes.md).
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](enable-access-logging.md).
`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 and `true` 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`, 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 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. Select `true` 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 are `true` and `false`. The default is `false`.
`routing.http.x_amzn_tls_version_and_cipher_suite.enabled`
Indicates whether the two headers (`x-amzn-tls-version` and `x-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. The `x-amzn-tls-version` header has information about the TLS protocol version negotiated with the client, and the `x-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 are `true` and `false`. The default is `false`.
`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 are `true` and `false`. The default is `false`.
`routing.http.xff_header_processing.mode`
Enables you to modify, preserve, or remove the `X-Forwarded-For` header in the HTTP request before the Application Load Balancer sends the request to the target. The possible values are `append`, `preserve`, and `remove`. The default is `append`.
+ If the value is `append`, the Application Load Balancer adds the client IP address (of the last hop) to the `X-Forwarded-For` header in the HTTP request before it sends it to targets.
+ If the value is `preserve`, the Application Load Balancer preserves the `X-Forwarded-For` header in the HTTP request, and sends it to targets without any change.
+ If the value is `remove`, the Application Load Balancer removes the `X-Forwarded-For` header in the HTTP request before it sends it to targets.
`routing.http2.enabled`
Indicates whether clients can connect to the load balancer using HTTP/2. If `true`, clients can connect using HTTP/2 or HTTP/1.1. If `false`, clients must connect using HTTP/1.1. 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` and `false`. The default is `false`.
**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 can choose whichever attribute best meets 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).
**`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**
+ 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).
+ 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 can't complete the authentication process, resulting in HTTP 500 errors.
For more information, see [Update the IP address types for your Application Load Balancer](load-balancer-ip-address-type.md).
## Application Load Balancer IP Address Management
Application Load Balancers use Public Elastic IPv4 addresses from [EC2's public IPv4 address pool. ](https://docs.amazonaws.cn/awsec2/latest/userguide/using-instance-addresing.html) These IP addresses are visible in your Amazon account when using the [describe-addresses ](https://docs.amazonaws.cn/cli/latest/reference/ec2/describe-addresses.html) CLI, API or viewing the Elastic IPs (EIP) section in the Amazon Console. Each ALB-associated IP address is marked with a service\$1managed attribute set to "ALB".
While these IPs are visible in your account, they remain fully managed by the Application Load Balancer service and cannot be modified or released. Application Load Balancer releases IPs back into the public IPv4 address pool when no longer in use.
CloudTrail logs API calls related to Application Load Balancer's EIP, such as the "AllocateAddress". These API calls are invoked by the Service Principal 'elasticloadbalancing.amazonaws.com'.
**Note**
Note: IPs allocated by Application Load Balancer do not count against your account's EIP limits.
## IPAM IP address pools
An IPAM IP address pool is a collection of contiguous IP address ranges (or CIDRs) that you create using Amazon VPC IP Address Manager (IPAM). Using IPAM IP address pools with your Application Load Balancer enables you to organize your IPv4 addresses according to your routing and security needs. IPAM IP address pools give you the choice to bring some or all of your public IPv4 address ranges to Amazon and use them with your Application Load Balancers. Your IPAM IP address pool is always prioritized when launching EC2 instances and creating Application Load Balancers. When your IP addresses are no longer in use, they become immediately available for use again.
To get started, create an IPAM IP address pool. For more information, see [Bring your IP addresses to IPAM](https://docs.amazonaws.cn/vpc/latest/ipam/tutorials-byoip-ipam.html).
**Considerations**
+ IPAM IPv6 address pools are not supported.
+ IPAM IPv4 address pools are not supported with internal load balancers or the `dualstack-without-public-ipv4` IP address type.
+ You can't delete an IP address in an IPAM IP address pool if it's currently in use by a load balancer.
+ During the transition to a different IPAM IP address pool, existing connections are terminated according to the load balancers HTTP client keepalive duration.
+ IPAM IP address pools can be shared across multiple accounts. For more information, see [Configure integration options for your IPAM](https://docs.amazonaws.cn/vpc/latest/ipam/choose-single-user-or-orgs-ipam.html).
+ There are no additional charges associated with using IPAM IP address pools with your load balancers. However, there might be charges related to IPAM, depending on which tier you use.
If there are no more assignable IP addresses in your IPAM IP address pool, Elastic Load Balancing uses Amazon managed IPv4 addresses instead. There are additional charges to use Amazon managed IPv4 addresses. To avoid these costs, you can add IP address ranges to your existing IPAM IP address pool.
For more information, see [Amazon VPC pricing](https://www.amazonaws.cn/vpc/pricing/).
## 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.
## 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](https://docs.amazonaws.cn/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#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](edit-target-group-attributes.md#cross_zone_console_disable).
## DNS name
Each Application Load Balancer receives a default Domain Name System (DNS) name with the following syntax: *name*-*id*.elb.*region*.amazonaws.com.cn. For example, my-load-balancer-1234567890abcdef.elb.us-west-2.amazonaws.com.cn.
If you'd prefer to use a DNS name that is easier to remember, you can create a custom domain name and associate it with the DNS name for your Application Load Balancer. When a client makes a request using this custom domain name, the DNS server resolves it to the DNS name for your Application Load Balancer.
First, register a domain name with an accredited domain name registrar. Next, use your DNS service, such as your domain registrar, to create a DNS record to route requests to your Application Load Balancer. For more information, see the documentation for your DNS service. For example, if you use Amazon Route 53 as your DNS service, you create an alias record that points to your Application Load Balancer. For more information, see [Routing traffic to an ELB load balancer](https://docs.amazonaws.cn/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html) in the *Amazon Route 53 Developer Guide*.
The Application Load Balancer has one IP address per enabled Availability Zone. These are the IP addresses of the Application Load Balancer nodes. The DNS name of the Application Load Balancer resolves to these addresses. For example, suppose that the custom domain name for your Application Load Balancer is `example.applicationloadbalancer.com`. Use the following **dig** or **nslookup** command to determine the IP addresses of the Application Load Balancer nodes.
**Linux or Mac**
```
$ dig +short example.applicationloadbalancer.com
```
**Windows**
```
C:\> nslookup example.applicationloadbalancer.com
```
The Application Load Balancer has DNS records for its nodes. You can use DNS names with the following syntax to determine the IP addresses of the Application Load Balancer nodes: *az*.*name*-*id*.elb.*region*.amazonaws.com.cn.
**Linux or Mac**
```
$ dig +short us-west-2b.my-load-balancer-1234567890abcdef.elb.us-west-2.amazonaws.com.cn
```
**Windows**
```
C:\> nslookup us-west-2b.my-load-balancer-1234567890abcdef.elb.us-west-2.amazonaws.com.cn
```