# Application Load Balancers 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.aws.amazon.com/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 + AWS 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 AWS Region. For more information, see the [AWS Outposts User Guide](https://docs.aws.amazon.com/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 [AWS Health Dashboard](https://docs.aws.amazon.com/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 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 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, AWS Direct Connect, or Site-to-Site 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 AWS WAF-enabled load balancer to route requests to targets if it is unable to forward the request to AWS 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, AWS Direct Connect, or Site-to-Site 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.aws.amazon.com/awsec2/latest/userguide/using-instance-addresing.html) These IP addresses are visible in your AWS account when using the [describe-addresses ](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-addresses.html) CLI, API or viewing the Elastic IPs (EIP) section in the AWS 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 AWS 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.aws.amazon.com/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.aws.amazon.com/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 AWS managed IPv4 addresses instead. There are additional charges to use AWS 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://aws.amazon.com/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.aws.amazon.com/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. For example, my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com. 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.aws.amazon.com/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. **Linux or Mac** ``` $ dig +short us-east-2b.my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com ``` **Windows** ``` C:\> nslookup us-east-2b.my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com ``` # Create an Application Load Balancer Create a load balancer An Application Load Balancer takes requests from clients and distributes them across targets in a target group, such as EC2 instances. For more information, see [How Elastic Load Balancing works.](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html) in the *Elastic Load Balancing User Guide*. **Topics** + [ ## Prerequisites ](#load-balancer-prereqs) + [ ## Create the load balancer ](#create-load-balancer) + [ ## Test the load balancer ](#test-load-balancer) + [ ## Next steps ](#application-load-balancer-next-steps) ## Prerequisites + Decide which Availability Zones and IP address types your application will support. Configure the load balancer VPC with subnets in each of these Availability Zones. If the application will support both IPv4 and IPv6 traffic, ensure that the subnets have both IPv4 and IPv6 CIDRs. Deploy at least one target in each Availability Zone. For more information, see [Subnets for your load balancer](application-load-balancers.md#subnets-load-balancer). + Ensure that the security groups for target instances allow traffic on the listener port from client IP addresses (if targets are specified by instance ID) or load balancer nodes (if targets are specified by IP address). For more information, see [Recommended rules](load-balancer-update-security-groups.md#security-group-recommended-rules). + Ensure that the security groups for target instances allow traffic from the load balancer on the health check port using the health check protocol. ## Create the load balancer As part of creating an Application Load Balancer, you'll create the load balancer, at least one listener, and at least one target group. Your load balancer is ready to handle client requests when there is at least one healthy registered target in each of its enabled Availability Zones. ------ #### [ Console ] **To create an Application Load Balancer** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, choose **Load Balancers**. 1. Choose **Create load balancer**. 1. Under **Application Load Balancer**, choose **Create**. 1. **Basic configuration** 1. For **Load balancer name**, enter a name for your load balancer. The name must be unique within your set of load balancers for the Region. Names can have a maximum of 32 characters, and can contain only alphanumeric characters and hyphens. They can not begin or end with a hyphen, or with `internal-`. You can't change the name of your Application Load Balancer after it's created. 1. For **Scheme**, choose **Internet-facing** or **Internal**. An internet-facing load balancer routes requests from clients to targets over the internet. An internal load balancer routes requests to targets using private IP addresses. 1. For **Load balancer IP address type**, choose **IPv4** if your clients use IPv4 addresses to communicate with the load balancer or **Dualstack** if your clients use both IPv4 and IPv6 addresses to communicate with the load balancer. Choose **Dualstack without public IPv4** if your clients use only IPv6 addresses to communicate with the load balancer. 1. **Network mapping** 1. For **VPC**, select the VPC that you prepared for your load balancer. With an internet-facing load balancer, only VPCs with an internet gateway are available for selection. 1. (Optional) For **IP pools**, you can select **Use IPAM pool for public IPv4 addresses**. For more information, see [IPAM IP address pools](application-load-balancers.md#ip-pools). 1. For **Availability Zones and subnets**, enable zones for your load balancer as follows: + Select subnets from at least two Availability Zones + Select subnets from at least one Local Zone + Select one Outpost subnet For more information, see [Subnets for your load balancer](application-load-balancers.md#subnets-load-balancer). With a **Dualstack** load balancer, you must select subnets with both IPv4 and IPv6 CIDR blocks. 1. **Security groups** We preselect the default security group for the load balancer VPC. You can select additional security groups as needed. If you don't have a security group that meets your needs, choose **create a new security group** to create one now. For more information, see [Create a security group](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html) in the *Amazon VPC User Guide*. 1. **Listeners and routing** 1. The default is a listener that accepts HTTP traffic on port 80. You can keep the default listener settings, or modify **Protocol** and **Port** as needed. 1. For **Default action**, select a target group to forward traffic. If you don't have a target group that meets your needs, choose **Create target group** to create one now. For more information, see [Create a target group](create-target-group.md). 1. (Optional) Choose **Add listener tag** and enter a tag key and a tag value. 1. (Optional) Choose **Add listener** to add another listener (for example, an HTTPS listener). 1. **Secure listener settings** This section appears only if you add an HTTPS listener. 1. For **Security policy**, choose a security policy that meets your requirements. For more information, see [Security policies](describe-ssl-policies.md). 1. For **Default SSL/TLS certificate**, the following options are available: + If you created or imported a certificate using AWS Certificate Manager, choose **From ACM**, then choose the certificate. + If you imported a certificate using IAM, choose **From IAM**, and then choose your certificate. + If you don't have an available certificate in ACM but do have a certificate for use with your load balancer, select **Import certificate** and provide the required information. Otherwise, choose **Request new ACM certificate**. For more information, see [AWS Certificate Manager certificates](https://docs.aws.amazon.com/acm/latest/userguide/gs.html) in the *AWS Certificate Manager User Guide*. 1. (Optional) Select **Mutual authentication (mTLS)**, choose a policy to enable ALPN. For more information, see [Mutual TLS authentication](mutual-authentication.md). 1. **Optimize with service integrations** (Optional) You can integrate other AWS with your load balancer. For more information, see [Load balancer integrations](load-balancer-integrations.md). 1. **Load balancer tags** (Optional) Expand **Load balancer tags**. Choose **Add new tag** and enter a tag key and a tag value. For more information, see [Tags](load-balancer-tags.md). 1. **Summary** Review your configuration, and choose **Create load balancer**. A few default attributes are applied to your Network Load Balancer during creation. You can view and edit them after creating the Network Load Balancer. For more information, see [Load balancer attributes](application-load-balancers.md#load-balancer-attributes). ------ #### [ AWS CLI ] **To create an Application Load Balancer** Use the [create-load-balancer](https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-load-balancer.html) command. The following example creates an internet-facing load balancer with two enabled Availability Zones and a security group. ``` aws elbv2 create-load-balancer \ --name my-load-balancer \ --type application \ --subnets subnet-1234567890abcdef0 subnet-0abcdef1234567890 \ --security-groups sg-1111222233334444 ``` **To create an internal Application Load Balancer** Include the `--scheme` option as shown in the following example. ``` aws elbv2 create-load-balancer \ --name my-load-balancer \ --type application \ --scheme internal \ --subnets subnet-1234567890abcdef0 subnet-0abcdef1234567890 \ --security-groups sg-1111222233334444 ``` **To create a dualstack Application Load Balancer** Include the `--ip-address-type` option as shown in the following example. ``` aws elbv2 create-load-balancer \ --name my-load-balancer \ --type application \ --ip-address-type dualstack \ --subnets subnet-1234567890abcdef0 subnet-0abcdef1234567890 \ --security-groups sg-1111222233334444 ``` **To add a listener** Use the [create-listener](https://docs.aws.amazon.com/cli/latest/reference/elbv2/create-listener.html) command. For examples, see [Create an HTTP listener](create-listener.md) and [Create an HTTPS listener](create-https-listener.md). ------ #### [ CloudFormation ] **To create an Application Load Balancer** Define a resource of type [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html). ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal IpAddressType: dualstack Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup Tags: - Key: "department" Value: "123" ``` **To add a listener** Define a resource of type [AWS::ElasticLoadBalancingV2::Listener](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-listener.html). For examples, see [Create an HTTP listener](create-listener.md) and [Create an HTTPS listener](create-https-listener.md). ------ ## Test the load balancer After creating your load balancer, you can verify that your EC2 instances pass the initial health check. You can then check that the load balancer is sending traffic to your EC2 instance. To delete the load balancer, see [Delete an Application Load Balancer](load-balancer-delete.md). **To test the load balancer** 1. After the load balancer is created, choose **Close**. 1. In the navigation pane, choose **Target Groups**. 1. Select the newly created target group. 1. Choose **Targets** and verify that your instances are ready. If the status of an instance is `initial`, it's typically because the instance is still in the process of being registered. This status can also indicate that the instance has not passed the minimum number of health checks to be considered healthy. After the status of at least one instance is healthy, you can test your load balancer. For more information, see [Target health status](target-group-health-checks.md#target-health-states). 1. In the navigation pane, choose **Load Balancers**. 1. Select the newly created load balancer. 1. Choose **Description** and copy the DNS name of the internet facing or internal load balancer (for example, my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com). + For internet facing load balancers, paste the DNS name into the address field of an internet connected web browser. + For internal load balancers, paste the DNS name into the address field of a web browser which has private connectivity to the VPC. If everything is configured correctly, the browser displays the default page of your server. 1. If the web page does not display, refer to the following documents for additional configuration help and troubleshooting steps. + For DNS related issues, see [ Routing traffic to an ELB load balancer](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html) in the *Amazon Route 53 Developer Guide*. + For Load Balancer related issues, see [Troubleshoot your Application Load Balancers](load-balancer-troubleshooting.md). ## Next steps After you create your load balancer, you might want to do the following: + Add [listener rules](listener-rules.md). + Configure [load balancer attributes](edit-load-balancer-attributes.md). + Configure [target group attributes](edit-target-group-attributes.md). + [HTTPS listeners] Add certificates to the [optional certificate list](listener-update-certificates.md#add-certificates). + Configure [monitoring features](load-balancer-monitoring.md). # Update the Availability Zones for your Application Load Balancer Update Availability Zones You can enable or disable the Availability Zones for your load balancer at any time. After you enable an Availability Zone, the load balancer starts routing requests to the registered targets in that Availability Zone. Application Load Balancers have cross-zone load balancing on by default, resulting in requests being routed to all registered targets across all Availability Zones. When cross-zone load balancing is off, the load balancer only routes request to targets in the same Availability Zone. For more information, see [Cross-zone load balancing](application-load-balancers.md#cross-zone-load-balancing). Your load balancer is most effective if you ensure that each enabled Availability Zone has at least one registered target. After you disable an Availability Zone, the targets in that Availability Zone remain registered with the load balancer, but the load balancer will not route requests to them. For more information, see [Subnets for your load balancer](application-load-balancers.md#subnets-load-balancer). ------ #### [ Console ] **To update Availability Zones** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer. 1. On the **Network mapping** tab, choose **Edit subnets**. 1. To enable an Availability Zone, select its check box and select one subnet. If there is only one available subnet, it is selected for you. 1. To change the subnet for an enabled Availability Zone, choose one of the other subnets from the list. 1. To disable an Availability Zone, clear its check box. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update Availability Zones** Use the [set-subnets](https://docs.aws.amazon.com/cli/latest/reference/elbv2/set-subnets.html) command. ``` aws elbv2 set-subnets \ --load-balancer-arn load-balancer-arn \ --subnets subnet-8360a9e7EXAMPLE subnet-b7d581c0EXAMPLE ``` ------ #### [ CloudFormation ] **To update Availability Zones** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal IpAddressType: dualstack Subnets: - !Ref subnet-AZ1 - !Ref new-subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup ``` ------ # Security groups for your Application Load Balancer Update security groups The security group for your Application Load Balancer controls the traffic that is allowed to reach and leave the load balancer. You must ensure that your load balancer can communicate with registered targets on both the listener port and the health check port. Whenever you add a listener to your load balancer or update the health check port for a target group used by the load balancer to route requests, you must verify that the security groups associated with the load balancer allow traffic on the new port in both directions. If they don't, you can edit the rules for the currently associated security groups or associate different security groups with the load balancer. You can choose the ports and protocols to allow. For example, you can open Internet Control Message Protocol (ICMP) connections for the load balancer to respond to ping requests (however, ping requests are not forwarded to any instances). **Considerations** + To ensure your targets receive traffic exclusively from the load balancer, restrict the security groups associated with your targets to accept traffic solely from the load balancer. This can be achieved by setting the load balancer's security group as the source in the ingress rule of the target's security group. + If your Application Load Balancer is a target of an Network Load Balancer, the security groups for your Application Load Balancer use connection tracking to track information about traffic coming from the Network Load Balancer. This happens regardless of the security group rules set for your Application Load Balancer. For more information, see [Security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) in the *Amazon EC2 User Guide*. + We recommend that you allow inbound ICMP traffic to support Path MTU Discovery. For more information, see [Path MTU Discovery](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#path_mtu_discovery) in the *Amazon EC2 User Guide*. ## Recommended rules The following rules are recommended for an internet-facing load balancer with instances as targets. | | | **Inbound** | | --- | | Source | Port Range | Comment | | 0.0.0.0/0 | *listener* | Allow all inbound traffic on the load balancer listener port | | **Outbound** | | --- | | Destination | Port Range | Comment | | *instance security group* | *instance listener* | Allow outbound traffic to instances on the instance listener port | | *instance security group* | *health check* | Allow outbound traffic to instances on the health check port | The following rules are recommended for an internal load balancer with instances as targets. | | | **Inbound** | | --- | | Source | Port Range | Comment | | *VPC CIDR* | *listener* | Allow inbound traffic from the VPC CIDR on the load balancer listener port | | **Outbound** | | --- | | Destination | Port Range | Comment | | *instance security group* | *instance listener* | Allow outbound traffic to instances on the instance listener port | | *instance security group* | *health check* | Allow outbound traffic to instances on the health check port | The following rules are recommended for an Application Load Balancer with instances as targets that itself is a target of a Network Load Balancer. | | | **Inbound** | | --- | | Source | Port Range | Comment | | *client IP addresses/CIDR* | *`alb `listener* | Allow inbound client traffic on the load balancer listener port | | *VPC CIDR* | *`alb `listener* | Allow inbound client traffic via AWS PrivateLink on the load balancer listener port | | *VPC CIDR* | *`alb `listener* | Allow inbound health traffic from the Network Load Balancer | | **Outbound** | | --- | | Destination | Port Range | Comment | | *instance security group* | *instance listener* | Allow outbound traffic to instances on the instance listener port | | *instance security group* | *health check* | Allow outbound traffic to instances on the health check port | ## Update the associated security groups You can update the security groups associated with your load balancer at any time. ------ #### [ Console ] **To update security groups** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer. 1. On the **Security** tab, choose **Edit**. 1. To associate a security group with your load balancer, select it. To remove a security group association, choose the **X** icon for the security group. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update security groups** Use the [set-security-groups](https://docs.aws.amazon.com/cli/latest/reference/elbv2/set-security-groups.html) command. ``` aws elbv2 set-security-groups \ --load-balancer-arn load-balancer-arn \ --security-groups sg-01dd3383691d02f42 sg-00f4e409629f1a42d ``` ------ #### [ CloudFormation ] **To update security groups** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup - !Ref myNewSecurityGroup ``` ------ # Update the IP address types for your Application Load Balancer Update the IP address type You can configure your Application Load Balancer so that clients can communicate with the load balancer using IPv4 addresses only, or using both IPv4 and IPv6 addresses (dualstack). The load balancer communicates with targets based on the IP address type of the target group. For more information, see [IP address type](application-load-balancers.md#ip-address-type). **Dualstack requirements** + You can set the IP address type when you create the load balancer and update it at any time. + The virtual private cloud (VPC) and subnets that you specify for the load balancer must have associated IPv6 CIDR blocks. For more information, see [IPv6 addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing) in the *Amazon EC2 User Guide*. + The route tables for the load balancer subnets must route IPv6 traffic. + The security groups for the load balancer must allow IPv6 traffic. + The network ACLs for the load balancer subnets must allow IPv6 traffic. ------ #### [ Console ] **To update the IP address type** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer. 1. On the **Network mapping** tab, choose **Edit IP address type**. 1. For **IP address type**, choose **IPv4** to support IPv4 addresses only, **Dualstack** to support both IPv4 and IPv6 addresses, or **Dualstack without public IPv4** to support IPv6 addresses only. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update the IP address type** Use the [set-ip-address-type](https://docs.aws.amazon.com/cli/latest/reference/elbv2/set-ip-address-type.html) command. ``` aws elbv2 set-ip-address-type \ --load-balancer-arn load-balancer-arn \ --ip-address-type dualstack ``` ------ #### [ CloudFormation ] **To update the IP address type** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal IpAddressType: dualstack Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup ``` ------ # Update the IPAM IP address pools for your Application Load Balancer Update the IPAM IP address pools IPAM IP address pools must first be created within IPAM before they can be used by your Application Load Balancer. For more information, see [Bring your IP addresses to IPAM](https://docs.aws.amazon.com/vpc/latest/ipam/tutorials-byoip-ipam.html). ------ #### [ Console ] **To update the IPAM IP address pool** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer. 1. On the **Network mapping** tab, choose **Edit IP pools**. 1. Under **IP pools**, select **Use IPAM pool for public IPv4 addresses** and choose an IPAM pool. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update the IPAM IP address pool** Use the [modify-ip-pools](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-ip-pools.html) command. ``` aws elbv2 modify-ip-pools \ --load-balancer-arn load-balancer-arn \ --ipam-pools Ipv4IpamPoolId=ipam-pool-1234567890abcdef0 ``` ------ #### [ CloudFormation ] **To update the IPAM IP address pool** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internet-facing IpAddressType: ipv4 Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup Ipv4IpamPoolId: !Ref myIPAMPool ``` ------ # Edit attributes for your Application Load Balancer Edit load balancer attributes After you create an Application Load Balancer, you can edit its attributes. **Topics** + [ ## Connection idle timeout ](#connection-idle-timeout) + [ ## HTTP client keepalive duration ](#http-client-keep-alive-duration) + [ ## Deletion protection ](#deletion-protection) + [ ## Desync mitigation mode ](#desync-mitigation-mode) + [ ## Host header preservation ](#host-header-preservation) ## 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. Application Load Balancers do not support HTTP/2 PING frames. These do not reset the connection idle timeout. By default, Elastic Load Balancing sets the idle timeout value for your load balancer to 60 seconds. ------ #### [ Console ] **To update the connection idle timeout value** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer. 1. On the **Attributes** tab, choose **Edit**. 1. Under **Traffic configuration**, enter a value for **Connection idle timeout**. The valid range is 1 through 4000 seconds. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update the connection idle timeout value** Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command with the `idle_timeout.timeout_seconds` attribute. The valid range is 1 to 4000 seconds. ``` aws elbv2 modify-load-balancer-attributes \ --load-balancer-arn load-balancer-arn \ --attributes "Key=idle_timeout.timeout_seconds,Value=120" ``` ------ #### [ CloudFormation ] **To update the connection idle timeout value** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `idle_timeout.timeout_seconds` attribute. The valid range is 1 to 4000 seconds. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup LoadBalancerAttributes: - Key: "idle_timeout.timeout_seconds" Value: "120" ``` ------ ## HTTP client keepalive duration The HTTP client keepalive duration is the maximum length of time that an Application Load Balancer maintains a persistent HTTP connection to a client. After the configured HTTP client keepalive duration elapses, the Application Load Balancer accepts one more request and then 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 Balancer sets the HTTP client keepalive duration value for load balancers 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, up to a maximum of 604800 seconds, or 7 days. An Application Load Balancer begins the HTTP client keepalive duration period when an HTTP connection to a client is initially established. The duration period continues when there's no traffic, and does not reset until a new connection is established. When load balancer traffic is shifted away from an impaired Availability Zone using zonal shift or zonal autoshift, clients with existing open connections might continue to make requests against the impaired location until the clients reconnect. To support faster recovery, consider setting a lower keepalive duration value, to limit the amount of time that clients stay connected to a load balancer. For more information, see [Limit the time that clients stay connected to your endpoints](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html#arc-zonal-shift.existing-connections) in the *Amazon Application Recovery Controller (ARC) Developer Guide*. **Note** When the load balancer switches 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 decrease the amount of time it takes to switch the IP address type for your Application Load Balancer, consider lowering the HTTP client keepalive duration. The Application Load Balancer assigns the HTTP client keepalive duration value during the initial connection. When you update the HTTP client keepalive duration, this can result in simultaneous connections with different HTTP client keepalive duration values. Existing connections retain the HTTP client keepalive duration value applied during its initial connection. New connections receive the updated HTTP client keepalive duration value. ------ #### [ Console ] **To update the client keepalive duration** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer. 1. On the **Attributes** tab, choose **Edit**. 1. Under **Traffic configuration**, enter a value for **HTTP client keepalive duration**. The valid range is 60 to 604800 seconds. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update the client keepalive duration** Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command with the `client_keep_alive.seconds` attribute. The valid range is 60 to 604800 seconds. ``` aws elbv2 modify-load-balancer-attributes \ --load-balancer-arn load-balancer-arn \ --attributes "Key=client_keep_alive.seconds,Value=7200" ``` ------ #### [ CloudFormation ] **To update the client keepalive duration** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `client_keep_alive.seconds` attribute. The valid range is 60 to 604800 seconds. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup LoadBalancerAttributes: - Key: "client_keep_alive.seconds" Value: "7200" ``` ------ ## 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. ------ #### [ Console ] **To enable or disable deletion protection** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer. 1. On the **Attributes** tab, choose **Edit**. 1. Under **Protection**, enable or disable **Deletion protection**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To enable or disable deletion protection** Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command with the `deletion_protection.enabled` attribute. ``` aws elbv2 modify-load-balancer-attributes \ --load-balancer-arn load-balancer-arn \ --attributes "Key=deletion_protection.enabled,Value=true" ``` ------ #### [ CloudFormation ] **To enable or disable deletion protection** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `deletion_protection.enabled` attribute. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup LoadBalancerAttributes: - Key: "deletion_protection.enabled" Value: "true" ``` ------ ## 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](https://tools.ietf.org/html/rfc7230). The http\$1desync\$1guardian library analyzes HTTP requests to prevent HTTP desync attacks. For more information, see [HTTP Desync Guardian](https://github.com/aws/http-desync-guardian) on GitHub. **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](load-balancer-cloudwatch-metrics.md#load-balancer-metrics-alb). 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](load-balancer-access-logs.md#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. ------ #### [ Console ] **To update desync mitigation mode** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer. 1. On the **Attributes** tab, choose **Edit**. 1. Under **Traffic configuration**, **Packet handling**, for **Desync mitigation mode**, choose **Defensive**, **Strictest**, or **Monitor**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To update desync mitigation mode** Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command with the `routing.http.desync_mitigation_mode` attribute. The possible values are `monitor`, `defensive`, or `strictest`. The default is `defensive`. ``` aws elbv2 modify-load-balancer-attributes \ --load-balancer-arn load-balancer-arn \ --attributes "Key=routing.http.desync_mitigation_mode,Value=monitor" ``` ------ #### [ CloudFormation ] **To update desync mitigation mode** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `routing.http.desync_mitigation_mode` attribute. The possible values are `monitor`, `defensive`, or `strictest`. The default is `defensive`. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup LoadBalancerAttributes: - Key: "routing.http.desync_mitigation_mode" Value: "monitor" ``` ------ ## 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\$1name/index.html HTTP/1.1 Host: example.com | example.com | dns\$1name | 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 | ------ #### [ Console ] **To enable host header preservation** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. In the navigation pane, choose **Load Balancers**. 1. Select the load balancer. 1. On the **Attributes** tab, choose **Edit**. 1. Under **Packet handling**, turn on **Preserve host header**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To enable host header preservation** Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command with the `routing.http.preserve_host_header.enabled` attribute set to `true`. ``` aws elbv2 modify-load-balancer-attributes \ --load-balancer-arn load-balancer-arn \ --attributes "Key=routing.http.preserve_host_header.enabled,Value=true" ``` ------ #### [ CloudFormation ] **To enable host header preservation** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `routing.http.preserve_host_header.enabled` attribute. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup LoadBalancerAttributes: - Key: "routing.http.preserve_host_header.enabled" Value: "true" ``` ------ # Tag an Application Load Balancer Tag a load balancer Tags help you to categorize your load balancers in different ways, for example, by purpose, owner, or environment. You can add multiple tags to each load balancer. If you add a tag with a key that is already associated with the load balancer, it updates the value of that tag. When you are finished with a tag, you can remove it from your load balancer. **Restrictions** + Maximum number of tags per resource—50 + Maximum key length—127 Unicode characters + Maximum value length—255 Unicode characters + Tag keys and values are case sensitive. Allowed characters are letters, spaces, and numbers representable in UTF-8, plus the following special characters: \$1 - = . \$1 : / @. Do not use leading or trailing spaces. + Do not use the `aws:` prefix in your tag names or values because it is reserved for AWS use. You can't edit or delete tag names or values with this prefix. Tags with this prefix do not count against your tags per resource limit. ------ #### [ Console ] **To update the tags for a load balancer** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer. 1. On the **Tags** tab, choose **Manage tags**. 1. To add a tag, choose **Add tag** and enter the tag key and tag value. 1. To update a tag, enter new values in **Key** or **Value**. 1. To delete a tag, choose **Remove** next to the tag. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To add tags** Use the [add-tags](https://docs.aws.amazon.com/cli/latest/reference/elbv2/add-tags.html) command. ``` aws elbv2 add-tags \ --resource-arns load-balancer-arn \ --tags "Key=project,Value=lima" "Key=department,Value=digital-media" ``` **To remove tags** Use the [remove-tags](https://docs.aws.amazon.com/cli/latest/reference/elbv2/remove-tags.html) command. ``` aws elbv2 remove-tags \ --resource-arns load-balancer-arn \ --tag-keys project department ``` ------ #### [ CloudFormation ] **To add tags** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `Tags` property. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup Tags: - Key: 'project' Value: 'lima' - Key: 'department' Value: 'digital-media' ``` ------ # Delete an Application Load Balancer Delete a load balancer As soon as your load balancer becomes available, you are billed for each hour or partial hour that you keep it running. When you no longer need the load balancer, you can delete it. As soon as the load balancer is deleted, you stop incurring charges for it. You can't delete a load balancer if deletion protection is enabled. For more information, see [Deletion protection](edit-load-balancer-attributes.md#deletion-protection). Note that deleting a load balancer does not affect its registered targets. For example, your EC2 instances continue to run and are still registered to their target groups. To delete your target groups, see [Delete an Application Load Balancer target group](delete-target-group.md). **DNS records** If you have a DNS record for your domain that points to your load balancer, point it to a new location and wait for the DNS change to take effect before deleting your load balancer. + If the record is a CNAME record with a Time To Live (TTL) of 300 seconds, wait at least 300 seconds before continuing to the next step. + If the record is a Route 53 Alias(A) record, wait at least 60 seconds. + If using Route 53, the record change takes 60 seconds to propagate to all global Route 53 name servers. Add this time to the TTL value of the record that is being updated. ------ #### [ Console ] **To delete a load balancer** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer, and then choose **Actions**, **Delete load balancer**. 1. When prompted for confirmation, enter **confirm** and then choose **Delete**. ------ #### [ AWS CLI ] **To delete a load balancer** Use the [delete-load-balancer](https://docs.aws.amazon.com/cli/latest/reference/elbv2/delete-load-balancer.html) command. ``` aws elbv2 delete-load-balancer \ --load-balancer-arn load-balancer-arn ``` ------ # View the Application Load Balancer resource map View the 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 the resource map for your Application Load Balancer** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer. 1. 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](load-balancer-troubleshooting.md#troubleshoot-with-resourcemap). **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. # Zonal shift for your Application Load Balancer Zonal shift Zonal shift and zonal autoshift are features of Amazon Application Recovery Controller (ARC). With zonal shift, you can shift traffic away from an impaired Availability Zone with a single action. This way, you can continue operating from other healthy Availability Zones in an AWS Region. With zonal autoshift, you authorize AWS to shift away resource traffic for an application from an Availability Zone during events, on your behalf, to help reduce time to recovery. AWS starts an autoshift when internal monitoring indicates that there is an Availability Zone impairment that could potentially impact customers. When AWS starts an autoshift, application traffic to resources that you've configured for zonal autoshift starts shifting away from the Availability Zone. When you start a zonal shift, your load balancer stops sending new traffic for the resource to the affected Availability Zone. ARC creates the zonal shift immediately. However, it can take a short time for existing, in-progress connections in the Availability Zone to complete, depending on client behavior and connection reuse. Depending on your DNS settings and other factors, existing connections can complete in just a few minutes, or might take longer. For more information, see [Limit the time that clients stay connected to your endpoints](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html#arc-zonal-shift.existing-connections) in the *Amazon Application Recovery Controller (ARC) Developer Guide*. **Topics** + [Before you begin](#zonal-shift-before-you-begin) + [ ## Cross-zone load balancing ](#cross-zone-enabled) + [Administrative override](#admin-override) + [Enable zonal shift](enable-zonal-shift.md) + [Start a zonal shift](start-zonal-shift.md) + [Update a zonal shift](update-zonal-shift.md) + [Cancel a zonal shift](cancel-zonal-shift.md) ## Before you begin a zonal shift Before you begin + Zonal shift is disabled by default and must be enabled on each Application Load Balancer. For more information, see [Enable zonal shift for your Application Load Balancer](enable-zonal-shift.md). + You can start a zonal shift for a specific load balancer only for a single Availability Zone. You can't start a zonal shift for multiple Availability Zones. + AWS proactively removes zonal load balancer IP addresses from DNS when multiple infrastructure issues impact services. Always check current Availability Zone capacity before you start a zonal shift. If your load balancers have cross-zone load balancing turned off and you use a zonal shift to remove a zonal load balancer IP address, the Availability Zone affected by the zonal shift also loses target capacity. For more information, see [Best practices for zonal shifts in ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html) in the *Amazon Application Recovery Controller (ARC) Developer Guide*. ## Cross-zone load balancing When a zonal shift is started on an Application Load Balancer with cross-zone load balancing enabled, all traffic to targets is blocked in the availability zone being impacted, and zonal IP addresses are removed from DNS. **Benefits:** + Quicker recovery from availability zone failures. + The ability to move traffic to a healthy availability zone if failures are detected in an availability zone. + You can test application integrity by simulating and identifying failures to prevent unplanned downtime. ## Zonal shift administrative override Administrative override Targets that belong to a Application Load Balancer include a new status `AdministrativeOverride`, which is independent from the `TargetHealth` state. When a zonal shift is started for a Application Load Balancer, all targets within the zone being shifted away from are considered administratively overridden. The Application Load Balancer stops routing new traffic to administratively overridden targets. Existing connections remain intact until they are organically closed. The possible `AdministrativeOverride` states are: **unknown** State cannot be propagated due to an internal error **no\$1override** No override is currently active on target **zonal\$1shift\$1active** Zonal shift is active in target Availability Zone # Enable zonal shift for your Application Load Balancer Enable zonal shift Zonal shift is disabled by default and must be enabled on each Application Load Balancer. This ensures that you can start a zonal shift using only the specific Application Load Balancers that you want. For more information, see [Zonal shift for your Application Load Balancer](zonal-shift.md). ------ #### [ Console ] **To enable zonal shift** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**. 1. Select the Application Load Balancer. 1. On the **Attributes** tab, choose **Edit**. 1. Under **Availability Zone routing configuration**, for **ARC zonal shift integration**, choose **Enable**. 1. Choose **Save changes**. ------ #### [ AWS CLI ] **To enable zonal shift** Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-load-balancer-attributes.html) command with the `zonal_shift.config.enabled` attribute. ``` aws elbv2 modify-load-balancer-attributes \ --load-balancer-arn load-balancer-arn \ --attributes "Key=zonal_shift.config.enabled,Value=true" ``` ------ #### [ CloudFormation ] **To enable zonal shift** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource to include the `zonal_shift.config.enabled` attribute. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal IpAddressType: dualstack Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup LoadBalancerAttributes: -Key: "zonal_shift.config.enabled" Value: "true" ``` ------ # Start a zonal shift for your Application Load Balancer Start a zonal shift Zonal shift in ARC enables you to temporarily move traffic for supported resources away from an Availability Zone so that your application can continue to operate normally with other Availability Zones in an AWS Region. **Prerequisite** Before you begin, verify that you [enabled zonal shift](enable-zonal-shift.md#enable-zonal-shift.title) for the load balancer. ------ #### [ Console ] This procedure explains how to start a zonal shift using the Amazon EC2 console. For steps to start a zonal shift using the ARC console, see [Starting a zonal shift](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) in the *Amazon Application Recovery Controller (ARC) Developer Guide*. **To start a zonal shift** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**. 1. Select the Application Load Balancer. 1. On the **Integrations** tab, expand **Amazon Application Recovery Controller (ARC)** and choose **Start zonal shift**. 1. Select the Availability Zone that you want to move traffic away from. 1. Choose or enter an expiration for the zonal shift. A zonal shift can initially be set from 1 minute up to three days (72 hours). All zonal shifts are temporary. You must set an expiration, but you can update active shifts later to set a new expiration. 1. Enter a comment. You can update the zonal shift later to edit the comment. 1. Select the check box to acknowledge that starting a zonal shift reduces capacity for your application by shifting traffic away from the Availability Zone. 1. Choose **Confirm**. ------ #### [ AWS CLI ] **To start a zonal shift** Use the Amazon Application Recovery Controller (ARC) [start-zonal-shift](https://docs.aws.amazon.com/cli/latest/reference/arc-zonal-shift/start-zonal-shift.html) command. ``` aws arc-zonal-shift start-zonal-shift \ --resource-identifier load-balancer-arn \ --away-from use2-az2 \ --expires-in 2h \ --comment "zonal shift due to scheduled maintenance" ``` ------ # Update a zonal shift for your Application Load Balancer Update a zonal shift You can update a zonal shift to set a new expiration, or edit or replace the comment for the zonal shift. ------ #### [ Console ] This procedure explains how to update a zonal shift using the Amazon EC2 console. For steps to update a zonal shift using the Amazon Application Recovery Controller (ARC) console, see [Updating a zonal shift](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) in the *Amazon Application Recovery Controller (ARC) Developer Guide*. **To update a zonal shift** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**. 1. Select an Application Load Balancer with an active zonal shift. 1. On the **Integrations** tab, expand **Amazon Application Recovery Controller (ARC)** and choose **Update zonal shift**. This opens the ARC console to continue the update process. 1. (Optional) For **Set zonal shift expiration**, select or enter an expiration. 1. (Optional) For **Comment**, optionally edit the existing comment or enter a new comment. 1. Choose **Update**. ------ #### [ AWS CLI ] **To update a zonal shift** Use the Amazon Application Recovery Controller (ARC) [update-zonal-shift](https://docs.aws.amazon.com/cli/latest/reference/arc-zonal-shift/update-zonal-shift.html) command. ``` aws arc-zonal-shift update-zonal-shift \ --zonal-shift-id 9ac9ec1e-1df1-0755-3dc5-8cf57EXAMPLE \ --expires-in 1h \ --comment "extending zonal shift for scheduled maintenance" ``` ------ # Cancel a zonal shift for your Application Load Balancer Cancel a zonal shift You can cancel a zonal shift any time before it expires. You can cancel zonal shifts that you initiate, or zonal shifts that AWS starts for a resource for a practice run for zonal autoshift. ------ #### [ Console ] This procedure explains how to cancel a zonal shift using the Amazon EC2 console. For steps to cancel a zonal shift using the Amazon Application Recovery Controller (ARC) console, see [Canceling a zonal shift](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) in the *Amazon Application Recovery Controller (ARC) Developer Guide*. **To cancel a zonal shift** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, under **Load Balancing**, choose **Load Balancers**. 1. Select an Application Load Balancer with an active zonal shift. 1. On the **Integrations** tab, under **Amazon Application Recovery Controller (ARC)**, choose **Cancel zonal shift**. This opens the ARC console to continue the cancelation process. 1. Choose **Cancel zonal shift**. 1. When prompted for confirmation, choose **Confirm**. ------ #### [ AWS CLI ] **To cancel a zonal shift** Use the Amazon Application Recovery Controller (ARC) [cancel-zonal-shift](https://docs.aws.amazon.com/cli/latest/reference/arc-zonal-shift/cancel-zonal-shift.html) command. ``` aws arc-zonal-shift cancel-zonal-shift \ --zonal-shift-id 9ac9ec1e-1df1-0755-3dc5-8cf57EXAMPLE ``` ------ # Capacity reservations for your Application Load Balancer LCU reservations Load balancer Capacity Unit (LCU) reservations allow you to reserve a static minimum capacity for your load balancer. Application Load Balancers automatically scale to support detected workloads and meet capacity needs. When minimum capacity is configured, your load balancer continues scaling up or down based on the traffic received, but also prevents the capacity from going lower than the minimum capacity configured. Consider using LCU reservation in following situations: + You have an upcoming event that will have a sudden, unusual high traffic and want to ensure your load balancer can support the sudden traffic spike during the event. + You have unpredictable spiky traffic due to the nature of your workload for a short period. + You are setting up your load balancer to on-board or migrate your services at a specific start time and need start with a high capacity instead of waiting for auto-scaling to take effect. + You are migrating workloads between load balancers and want to configure the destination to match the scale of the source. **Estimate the capacity that you need** When determining the amount of capacity you should reserve for your load balancer, we recommend performing load testing or reviewing historical workload data that represents the upcoming traffic you expect. Using the Elastic Load Balancing console, you can estimate how much capacity you need to reserve based on the reviewed traffic. Alternatively, you can utilize the CloudWatch metric `PeakLCUs` to determine the level of capacity needed. The `PeakLCUs` metric accounts for peaks in your traffic pattern that the load balancer must scale across all scaling dimensions to support your workload. The `PeakLCUs` metric is different from the `ConsumedLCUs` metric, which only aggregates the billing dimensions of your traffic. Using the `PeakLCUs` metric is recommended to ensure your LCU reservation is adequate during load balancer scaling. When estimating capacity, use a per-minute `Sum` of `PeakLCUs`. If you don't have historical workload data to reference and cannot perform load testing, you can estimate capacity needed using the LCU reservation calculator. The LCU reservation calculator uses data based on historical workloads AWS observe and may not represent your specific workload. For more information, see [Load Balancer Capacity Unit Reservation Calculator](https://exampleloadbalancer.com/ondemand_capacity_reservation_calculator.html). **Minimum and maximum values for an LCU reservation** The total reservation request must be at least 100 LCU. The maximum value is determined by the quotas for your account. For more information, see [Load Balancer Capacity Units](load-balancer-limits.md#lcu-quotas). # Request Load balancer Capacity Unit reservation for your Application Load Balancer Request reservation Before you use LCU reservation, review the following: + Capacity is reserved at the regional level and is evenly distributed across availability zones. Confirm you have enough evenly distributed targets in each availability zone before turning on LCU reservation. + LCU reservation requests are fulfilled on a first come first serve basis, and depends on available capacity for a zone at that time. Most requests are typically fulfilled within a few minutes, but can take up to a few hours. + To update an existing reservation, the previous request must be provisioned or failed. You can increase reserved capacity as many times as you need, however you can only decrease the reserved capacity two times per day. + You will continue to incur charges for any reserved or provisioned capacity until they are terminated or cancelled. ------ #### [ Console ] **To request an LCU reservation** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer name. 1. On the **Capacity** tab, choose **Edit LCU Reservation**. 1. Select **Historic reference based estimate**. 1. Select the reference period to view the recommended reserved LCU level. 1. If you do not have historic reference workload, you can choose **Manual estimate** and enter the number of LCUs to be reserved. 1. Choose **Save**. ------ #### [ AWS CLI ] **To request an LCU reservation** Use the [modify-capacity-reservation](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-capacity-reservation.html) command. ``` aws elbv2 modify-capacity-reservation \ --load-balancer-arn load-balancer-arn \ --minimum-load-balancer-capacity CapacityUnits=100 ``` ------ #### [ CloudFormation ] **To request an LCU reservation** Update the [AWS::ElasticLoadBalancingV2::LoadBalancer](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-loadbalancer.html) resource. ``` Resources: myLoadBalancer: Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer' Properties: Name: my-alb Type: application Scheme: internal Subnets: - !Ref subnet-AZ1 - !Ref subnet-AZ2 SecurityGroups: - !Ref mySecurityGroup MinimumLoadBalancerCapacity: CapacityUnits: 100 ``` ------ # Update or cancel Load Balancer Capacity Unit reservations for your Application Load Balancer Update or cancel reservation If the traffic patterns for your load balancer change, you can update or cancel the LCU reservation for your load balancer. The status of the LCU reservation must be **Provisioned**. ------ #### [ Console ] **To update or cancel an LCU reservation** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer name. 1. On the **Capacity** tab, do one of the following: 1. To update the LCU reservation choose **Edit LCU Reservation**. 1. To cancel the LCU reservation, choose **Cancel Capacity**. ------ #### [ AWS CLI ] **To cancel an LCU reservation** Use the [modify-capacity-reservation](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-capacity-reservation.html) command. ``` aws elbv2 modify-capacity-reservation \ --load-balancer-arn load-balancer-arn \ --reset-capacity-reservation ``` ------ # Monitor Load Balancer Capacity Unit reservation for your Application Load Balancer Monitor reservation **Reservation status** The following are the possible status values for an LCU reservation: + `pending` ‐ Indicates the reservation it is in the process of provisioning. + `provisioned` ‐ Indicates the reserved capacity is ready and available to use. + `failed` ‐ Indicates the request cannot be completed at the time. + `rebalancing` ‐ Indicates an availability zone has been added or removed and the load balancer is rebalancing capacity. **LCU utilization** The `ReservedLCUs` metric is reported on a per-minute basis. Capacity is reserved on an hourly basis. For example, if you have a LCU reservation of 6,000, the one-hour total for `ReservedLCUs` is 6,000, and the one-minute total is 100. To determine your reserved LCU utilization, refer to the `PeakLCUs` metric. You can set CloudWatch alarms to compare the per-minute `Sum` of `PeakLCUs` against your reserved capacity value, or the per-hour `Sum` of `ReservedLCUs`, to determine whether you have reserved enough capacity to meet your needs. ------ #### [ Console ] **To view the status of an LCU reservation** 1. Open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. On the navigation pane, choose **Load Balancers**. 1. Select the load balancer name. 1. On the **Capacity** tab, you can view the **Reservation Status** and **Reserved LCU** value. ------ #### [ AWS CLI ] **To monitor the status of an LCU reservation** Use the [describe-capacity-reservation](https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-capacity-reservation.html) command. ``` aws elbv2 describe-capacity-reservation \ --load-balancer-arn load-balancer-arn ``` ------ # Integrations for your Application Load Balancer Load balancer integrations You can optimize your Application Load Balancer architecture by integrating with several other AWS services to enhance the performance, security, and availability of your application. **Topics** + [ ## Amazon Application Recovery Controller (ARC) ](#arc-integration) + [ ## Amazon CloudFront \$1 AWS WAF ](#cloudfront-waf) + [ ## AWS Global Accelerator ](#global-accelerator) + [ ## AWS Config ](#config-integration) + [ ## AWS WAF ](#load-balancer-waf) ## Amazon Application Recovery Controller (ARC) Amazon Application Recovery Controller (ARC) helps you to shift traffic for your load balancer away from an impaired Availability Zone to a healthy Availability Zone in the same Region. Using zonal shift reduces the duration and severity that power outages, hardware issues, or software issues in an Availability Zone can have on your applications. For more information, see [Zonal shift for your Application Load Balancer](zonal-shift.md). ## Amazon CloudFront \$1 AWS WAF Amazon CloudFront is a web service that helps improve the performance, availability, and security of your applications that use AWS. CloudFront acts as a distributed, single point of entry for your web applications that use Application Load Balancers. It extends your Application Load Balancer's reach globally, allowing it to serve users efficiently from nearby edge locations, optimizing content delivery and reducing latency for users worldwide. The automatic content caching at these edge locations significantly reduces the load on your Application Load Balancer, improving its performance and scalability. The one-click integration available in the Elastic Load Balancing console creates a CloudFront distribution with the recommended AWS WAF security protections, and associates it to your Application Load Balancer. The AWS WAF protections block against common web exploits before reaching your load balancer. You can access the CloudFront distribution and its corresponding security dashboard from the load balancer’s **Integrations** tab in the console. For more information, see [Manage AWS WAF security protections in the CloudFront security dashboard](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/security-dashboard.html) in the *Amazon CloudFront Developer Guide* and [Introducing CloudFront Security Dashboard, a Unified CDN and Security Experience](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-cloudfront-security-dashboard-a-unified-cdn-and-security-experience/) at *aws.amazon.com/blogs*. As a security best practice, configure your internet-facing Application Load Balancer's security groups to allow inbound traffic only from the AWS-managed prefix list for CloudFront, and remove any other inbound rules. For more information, see [Use the CloudFront managed prefix list](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html), [Configure CloudFront to add a custom HTTP header to requests](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html#restrict-alb-add-custom-header.html) and [Configure an Application Load Balancer to only forward requests that contain a specific header](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html#restrict-alb-route-based-on-header.html) in the *Amazon CloudFront Developer Guide*>. **Note** CloudFront only supports ACM certificates in the US East (N. Virginia) us-east-1 region. If your Application Load Balancer has an HTTPS listener configured with an ACM certificate in a region other than us-east-1, you will need to either change the CloudFront origin connection from HTTPS to HTTP, or provision an ACM certificate in the US East (N. Virginia) region and attach it to your CloudFront distribution. ## AWS Global Accelerator To optimize application availability, performance, and security, create an accelerator for your load balancer. The accelerator directs traffic over the AWS global network to static IP addresses that serve as fixed endpoints in the nearest Region to the client. AWS Global Accelerator is protected by Shield Standard, which minimizes application downtime and latency from DDoS attacks. For more information, see [Adding an accelerator when you create a load balancer](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-accelerators.alb-accelerator.html) in the *AWS Global Accelerator Developer Guide*. ## AWS Config To optimize monitoring and compliance of your load balancer, set up AWS Config. AWS Config provides a detailed view of the configuration of AWS resources in your AWS account. This includes how the resources are related to one another and how they were configured in the past so that you can see how the configurations and relationships change over time. AWS Config streamlines audits, compliance, and troubleshooting. For more information, see the [AWS Config Developer Guide](https://docs.aws.amazon.com/config/latest/developerguide/). ## 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). 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 AWS WAF fail open. **Pre-defined web ACLs** When enabling AWS WAF integration you can choose to automatically create a new web ACL with pre-defined rules. The pre-defined web ACL includes three AWS 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](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html#aws-managed-rule-groups-ip-rep-amazon) in the *AWS 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](https://owasp.org/www-project-top-ten/). For more information, see [Core rule set (CRS) managed rule group ](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-baseline.html#aws-managed-rule-groups-baseline-crs) in the *AWS 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](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-baseline.html#aws-managed-rule-groups-baseline-known-bad-inputs) in the *AWS WAF Developer Guide*. For more information, see [Using web ACLs in AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html) in the *AWS WAF Developer Guide*.