# Configure your Classic Load Balancer
After you create a Classic Load Balancer, you can change its configuration. For example, you can update the load balancer attributes, subnets, and security groups.Load balancer attributes
[Connection draining](config-conn-drain.md)
If enabled, the load balancer allows existing requests to complete before the load balancer shifts traffic away from a deregistered or unhealthy instance.
[Cross-zone load balancing](enable-disable-crosszone-lb.md)
If enabled, the load balancer routes the request traffic evenly across all instances regardless of the Availability Zones.
[Desync migitation mode](config-desync-mitigation-mode.md)
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`.
[Idle timeout](config-idle-timeout.md)
If enabled, the load balancer allows the connections to remain idle (no data is sent over the connection) for the specified duration. The default is 60 seconds.
[Sticky sessions](elb-sticky-sessions.md)
Classic Load Balancers support both duration-based and application-based session stickiness.Load balancer details
[Security groups](elb-vpc-security-groups.md)
The security groups for your load balancer must allow traffic on the listener and health check ports.
[Subnets](elb-manage-subnets.md)
You can expand the ability of your load balancer to additional subnets.
[Proxy protocol](enable-proxy-protocol.md)
If enabled, we add a header with connection information that is sent to the instance.
[Tags](add-remove-tags.md)
You can add tags to categorize your load balancres.
# Configure the idle connection timeout for your Classic Load Balancer
For each request that a client makes through a Classic Load Balancer, the load balancer maintains two connections. The front-end connection is between the client and the load balancer. The back-end connection is between the load balancer and a registered EC2 instance. The load balancer has a configured idle timeout period that applies to its connections. If no data has been sent or received by the time that the idle timeout period elapses, the load balancer closes the connection. To ensure that lengthy operations such as file uploads have time to complete, send at least 1 byte of data before each idle timeout period elapses, and increase the length of the idle timeout period as needed.
If you use HTTP and HTTPS listeners, we recommend that you enable the HTTP keep-alive option for your instances. You can enable keep-alive in the web server settings for your instances. Keep-alive, when enabled, enables the load balancer to reuse back-end connections until the keep-alive timeout expires. To ensure that the load balancer is responsible for closing the connections to your instance, make sure that the value you set for the HTTP keep-alive time is greater than the idle timeout setting configured for your load balancer.
Note that TCP keep-alive probes do not prevent the load balancer from terminating the connection because they do not send data in the payload.
**Topics**
+ [Configure the idle timeout using the console](#config-idle-timeout-console)
+ [Configure the idle timeout using the AWS CLI](#config-idle-timeout-awscli)
## Configure the idle timeout using the console
By default, Elastic Load Balancing sets the idle timeout for your load balancer to 60 seconds. Use the following procedure to set a different value for the idle timeout.
**To configure the idle timeout setting for your load balancer using the console**
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. Choose the name of the load balancer to open its detail page.
1. On the **Attributes** tab, choose **Edit**.
1. On the **Edit load balancer attributes** page, in the **Traffic configuration** section, type a value for **Idle timeout**. The range for the idle timeout is from 1 to 4,000 seconds.
1. Choose **Save changes**.
## Configure the idle timeout using the AWS CLI
Use the following [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) command to set the idle timeout for your load balancer:
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"ConnectionSettings\":{\"IdleTimeout\":30}}"
```
The following is an example response:
```
{
"LoadBalancerAttributes": {
"ConnectionSettings": {
"IdleTimeout": 30
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
# Configure cross-zone load balancing for your Classic Load Balancer
With *cross-zone load balancing*, each load balancer node for your Classic Load Balancer distributes requests evenly across the registered instances in all enabled Availability Zones. If cross-zone load balancing is disabled, each load balancer node distributes requests evenly across the registered instances in its Availability Zone only. For more information, see [Cross-zone load balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing) in the *Elastic Load Balancing User Guide*.
Cross-zone load balancing reduces the need to maintain equivalent numbers of instances in each enabled Availability Zone, and improves your application's ability to handle the loss of one or more instances. However, we still recommend that you maintain approximately equivalent numbers of instances in each enabled Availability Zone for higher fault tolerance.
For environments where clients cache DNS lookups, incoming requests might favor one of the Availability Zones. Using cross-zone load balancing, this imbalance in the request load is spread across all available instances in the Region, reducing the impact of misbehaving clients.
When you create a Classic Load Balancer, the default for cross-zone load balancing depends on how you create the load balancer. With the API or CLI, cross-zone load balancing is disabled by default. With the AWS Management Console, the option to enable cross-zone load balancing is selected by default. After you create a Classic Load Balancer, you can enable or disable cross-zone load balancing at any time.
**Topics**
+ [Enable cross-zone load balancing](#enable-cross-zone)
+ [Disable cross-zone load balancing](#disable-cross-zone)
## Enable cross-zone load balancing
You can enable cross-zone load balancing for your Classic Load Balancer at any time.
**To enable cross-zone load balancing using the console**
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. Choose the name of the load balancer to open its detail page.
1. On the **Attributes** tab, choose **Edit**.
1. On the **Edit load balancer attributes** page, in the **Availability Zone routing configuration** section, enable **Cross-zone load balancing**.
1. Choose **Save changes**.
**To enable cross-zone load balancing using the AWS CLI**
1. Use the following [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) command to set the `CrossZoneLoadBalancing` attribute of your load balancer to `true`:
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"CrossZoneLoadBalancing\":{\"Enabled\":true}}"
```
The following is an example response:
```
{
"LoadBalancerAttributes": {
"CrossZoneLoadBalancing": {
"Enabled": true
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
1. (Optional) Use the following [describe-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancer-attributes.html) command to verify that cross-zone load balancing is enabled for your load balancer:
```
aws elb describe-load-balancer-attributes --load-balancer-name my-loadbalancer
```
The following is an example response:
```
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": false,
"Timeout": 300
},
"CrossZoneLoadBalancing": {
"Enabled": true
},
"ConnectionSettings": {
"IdleTimeout": 60
},
"AccessLog": {
"Enabled": false
}
}
}
```
## Disable cross-zone load balancing
You can disable the cross-zone load balancing option for your load balancer at any time.
**To disable cross-zone load balancing using the console**
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. Choose the name of the load balancer to open its detail page.
1. On the **Attributes** tab, choose **Edit**.
1. On the **Edit load balancer attributes** page, in the **Availability Zone routing configuration** section, disable **Cross-zone load balancing**.
1. Choose **Save changes**.
To disable cross-zone load balancing, set the `CrossZoneLoadBalancing` attribute of your load balancer to `false`.
**To disable cross-zone load balancing using the AWS CLI**
1. Use the following [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) command:
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"CrossZoneLoadBalancing\":{\"Enabled\":false}}"
```
The following is an example response:
```
{
"LoadBalancerAttributes": {
"CrossZoneLoadBalancing": {
"Enabled": false
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
1. (Optional) Use the following [describe-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancer-attributes.html) command to verify that cross-zone load balancing is disabled for your load balancer:
```
aws elb describe-load-balancer-attributes --load-balancer-name my-loadbalancer
```
The following is an example response:
```
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": false,
"Timeout": 300
},
"CrossZoneLoadBalancing": {
"Enabled": false
},
"ConnectionSettings": {
"IdleTimeout": 60
},
"AccessLog": {
"Enabled": false
}
}
}
```
# Configure connection draining for your Classic Load Balancer
To ensure that a Classic Load Balancer stops sending requests to instances that are de-registering or unhealthy, while keeping the existing connections open, use *connection draining*. This enables the load balancer to complete in-flight requests made to instances that are de-registering or unhealthy.
When you enable connection draining, you can specify a maximum time for the load balancer to keep connections alive before reporting the instance as de-registered. The maximum timeout value can be set between 1 and 3,600 seconds (the default is 300 seconds). When the maximum time limit is reached, the load balancer forcibly closes connections to the de-registering instance.
If a de-registering instance has no in-flight requests and no active connections, Elastic Load Balancing immediately completes the deregistration process.
While in-flight requests are being served, the load balancer reports the state of a de-registering instance as `InService: Instance deregistration currently in progress`. When the de-registering instance is finished serving all in-flight requests, or when the maximum timeout limit is reached, the load balancer reports the instance state as `OutOfService: Instance is not currently registered with the LoadBalancer`.
If an instance becomes unhealthy, the load balancer reports the instance state as `OutOfService`. If there are in-flight requests made to the unhealthy instance, they are completed. The maximum timeout limit does not apply to connections to unhealthy instances.
If your instances are part of an Auto Scaling group and connection draining is enabled for your load balancer, Auto Scaling waits for the in-flight requests to complete, or for the maximum timeout to expire, before terminating instances due to a scaling event or health check replacement.
You can disable connection draining if you want your load balancer to immediately close connections to the instances that are de-registering or have become unhealthy. When connection draining is disabled, any in-flight requests made to instances that are de-registering or unhealthy are not completed.
**Topics**
+ [Enable connection draining](#enable-conn-drain)
+ [Disable connection draining](#disable-conn-drain)
## Enable connection draining
You can enable connection draining for your load balancer at any time.
**To enable connection draining using the console**
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. Choose the name of the load balancer to open its detail page.
1. On the **Attributes** tab, choose **Edit**.
1. On the **Edit load balancer attributes** page, in the **Traffic configuration** section, select **Enable connection draining**.
1. (Optional) For **Timeout (draining interval)**, enter a value between 1 and 3,600 seconds. Otherwise the default of 300 seconds is used.
1. Choose **Save changes**.
**To enable connection draining using the AWS CLI**
Use the following [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) command:
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"ConnectionDraining\":{\"Enabled\":true,\"Timeout\":300}}"
```
The following is an example response:
```
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": true,
"Timeout": 300
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
## Disable connection draining
You can disable connection draining for your load balancer at any time.
**To disable connection draining using the console**
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. Choose the name of the load balancer to open its detail page.
1. On the **Attributes** tab, choose **Edit**.
1. On the **Edit load balancer attributes** page, in the **Traffic configuration** section, deselect **Enable connection draining**.
1. Choose **Save changes**.
**To disable connection draining using the AWS CLI**
Use the following [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) command:
```
aws elb modify-load-balancer-attributes --load-balancer-name my-loadbalancer --load-balancer-attributes "{\"ConnectionDraining\":{\"Enabled\":false}}"
```
The following is an example response:
```
{
"LoadBalancerAttributes": {
"ConnectionDraining": {
"Enabled": false,
"Timeout": 300
}
},
"LoadBalancerName": "my-loadbalancer"
}
```
# Configure sticky sessions for your Classic Load Balancer
By default, a Classic Load Balancer routes each request independently to the registered instance with the smallest load. However, you can use the *sticky session* feature (also known as *session affinity*), which enables the load balancer to bind a user's session to a specific instance. This ensures that all requests from the user during the session are sent to the same instance.
The key to managing sticky sessions is to determine how long your load balancer should consistently route the user's request to the same instance. If your application has its own session cookie, then you can configure Elastic Load Balancing so that the session cookie follows the duration specified by the application's session cookie. If your application does not have its own session cookie, then you can configure Elastic Load Balancing to create a session cookie by specifying your own stickiness duration.
Elastic Load Balancing creates a cookie, named AWSELB, that is used to map the session to the instance.
**Requirements**
+ An HTTP/HTTPS load balancer.
+ At least one healthy instance in each Availability Zone.
**Compatibility**
+ The RFC for the path property of a cookie allows underscores. However, Elastic Load Balancing URI encodes underscore characters as `%5F` because some browsers, such as Internet Explorer 7, expect underscores to be URI encoded as `%5F`. Because of the potential to impact browsers that are currently working, Elastic Load Balancing continues to URI encode underscore characters. For example, if the cookie has the property `path=/my_path`, Elastic Load Balancing changes this property in the forwarded request to `path=/my%5Fpath`.
+ You can't set the `secure` flag or `HttpOnly` flag on your duration-based session stickiness cookies. However, these cookies contain no sensitive data. Note that if you set the `secure` flag or `HttpOnly` flag on an application-controlled session stickiness cookie, it is also set on the AWSELB cookie.
+ If you have a trailing semicolon in the `Set-Cookie` field of an application cookie, the load balancer ignores the cookie.
**Topics**
+ [Duration-based session stickiness](#enable-sticky-sessions-duration)
+ [Application-controlled session stickiness](#enable-sticky-sessions-application)
## Duration-based session stickiness
The load balancer uses a special cookie, AWSELB, to track the instance for each request to each listener. When the load balancer receives a request, it first checks to see if this cookie is present in the request. If so, the request is sent to the instance specified in the cookie. If there is no cookie, the load balancer chooses an instance based on the existing load balancing algorithm. A cookie is inserted into the response for binding subsequent requests from the same user to that instance. The stickiness policy configuration defines a cookie expiration, which establishes the duration of validity for each cookie. The load balancer does not refresh the expiry time of the cookie and does not check whether the cookie is expired before using it. After a cookie expires, the session is no longer sticky. The client should remove the cookie from its cookie store upon expiry.
With CORS (cross-origin resource sharing) requests, some browsers require `SameSite=None; Secure` to enable stickiness. In this case, Elastic Load Balancing creates a second stickiness cookie, AWSELBCORS, which includes the same information as the original stickiness cookie plus this `SameSite` attribute. Clients receive both cookies.
If an instance fails or becomes unhealthy, the load balancer stops routing requests to that instance, and chooses a new healthy instance based on the existing load balancing algorithm. The request is routed to the new instance as if there is no cookie and the session is no longer sticky.
If a client switches to a listener with a different backend port, stickiness is lost.
**To enable duration-based sticky sessions for a load balancer using the console**
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. Choose the name of the load balancer to open its detail page.
1. On the **Listeners** tab, choose **Manage listeners**.
1. On the **Manage listeners** page, locate the listener to be updated and choose **Edit** under **Cookie stickiness**.
1. On the **Edit cookie stickiness setting** pop-up, select **Generated by load balancer**.
1. (Optional) For **Expiration period**, type the cookie expiration period, in seconds. If you do not specify an expiration period, the sticky session lasts for the duration of the browser session.
1. Choose **Save changes** to close the pop-up window.
1. Choose **Save changes** to return to the load balancer details page.
**To enable duration-based sticky sessions for a load balancer using the AWS CLI**
1. Use the following [create-lb-cookie-stickiness-policy](https://docs.aws.amazon.com/cli/latest/reference/elb/create-lb-cookie-stickiness-policy.html) command to create a load balancer-generated cookie stickiness policy with a cookie expiration period of 60 seconds:
```
aws elb create-lb-cookie-stickiness-policy --load-balancer-name my-loadbalancer --policy-name my-duration-cookie-policy --cookie-expiration-period 60
```
1. Use the following [set-load-balancer-policies-of-listener](https://docs.aws.amazon.com/cli/latest/reference/elb/set-load-balancer-policies-of-listener.html) command to enable session stickiness for the specified load balancer:
```
aws elb set-load-balancer-policies-of-listener --load-balancer-name my-loadbalancer --load-balancer-port 443 --policy-names my-duration-cookie-policy
```
**Note**
The `set-load-balancer-policies-of-listener` command replaces the current set of policies associated with the specified load balancer port. Every time you use this command, specify the `--policy-names` option to list all policies to enable.
1. (Optional) Use the following [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) command to verify that the policy is enabled:
```
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
```
The response includes the following information, which shows that the policy is enabled for the listener on the specified port:
```
{
"LoadBalancerDescriptions": [
{
...
"ListenerDescriptions": [
{
"Listener": {
"InstancePort": 443,
"SSLCertificateId": "arn:aws:iam::123456789012:server-certificate/my-server-certificate",
"LoadBalancerPort": 443,
"Protocol": "HTTPS",
"InstanceProtocol": "HTTPS"
},
"PolicyNames": [
"my-duration-cookie-policy",
"ELBSecurityPolicy-TLS-1-2-2017-01"
]
},
...
],
...
"Policies": {
"LBCookieStickinessPolicies": [
{
"PolicyName": "my-duration-cookie-policy",
"CookieExpirationPeriod": 60
}
],
"AppCookieStickinessPolicies": [],
"OtherPolicies": [
"ELBSecurityPolicy-TLS-1-2-2017-01"
]
},
...
}
]
}
```
## Application-controlled session stickiness
The load balancer uses a special cookie to associate the session with the instance that handled the initial request, but follows the lifetime of the application cookie specified in the policy configuration. The load balancer only inserts a new stickiness cookie if the application response includes a new application cookie. The load balancer stickiness cookie does not update with each request. If the application cookie is explicitly removed or expires, the session stops being sticky until a new application cookie is issued.
The following attributes set by back-end instances are sent to clients in the cookie: `path`, `port`, `domain`, `secure`, `httponly`, `discard`, `max-age`, `expires`, `version`, `comment`, `commenturl`, and `samesite`.
If an instance fails or becomes unhealthy, the load balancer stops routing requests to that instance, and chooses a new healthy instance based on the existing load balancing algorithm. The load balancer treats the session as now "stuck" to the new healthy instance, and continues routing requests to that instance even if the failed instance comes back.
**To enable application-controlled session stickiness using the console**
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. Choose the name of the load balancer to open its detail page.
1. On the **Listeners** tab, choose **Manage listeners**.
1. On the **Manage listeners** page, locate the listener to be updated and choose **Edit** under **Cookie stickiness**.
1. Select **Generated by application**.
1. For **Cookie Name**, type the name of your application cookie.
1. Choose **Save changes**.
**To enable application-controlled session stickiness using the AWS CLI**
1. Use the following [create-app-cookie-stickiness-policy](https://docs.aws.amazon.com/cli/latest/reference/elb/create-app-cookie-stickiness-policy.html) command to create an application-generated cookie stickiness policy:
```
aws elb create-app-cookie-stickiness-policy --load-balancer-name my-loadbalancer --policy-name my-app-cookie-policy --cookie-name my-app-cookie
```
1. Use the following [set-load-balancer-policies-of-listener](https://docs.aws.amazon.com/cli/latest/reference/elb/set-load-balancer-policies-of-listener.html) command to enable session stickiness for a load balancer:
```
aws elb set-load-balancer-policies-of-listener --load-balancer-name my-loadbalancer --load-balancer-port 443 --policy-names my-app-cookie-policy
```
**Note**
The `set-load-balancer-policies-of-listener` command replaces the current set of policies associated with the specified load balancer port. Every time you use this command, specify the `--policy-names` option to list all policies to enable.
1. (Optional) Use the following [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) command to verify that the sticky policy is enabled:
```
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
```
1. The response includes the following information, which shows that the policy is enabled for the listener on the specified port:
```
{
"LoadBalancerDescriptions": [
{
...
"ListenerDescriptions": [
{
"Listener": {
"InstancePort": 443,
"SSLCertificateId": "arn:aws:iam::123456789012:server-certificate/my-server-certificate",
"LoadBalancerPort": 443,
"Protocol": "HTTPS",
"InstanceProtocol": "HTTPS"
},
"PolicyNames": [
"my-app-cookie-policy",
"ELBSecurityPolicy-TLS-1-2-2017-01"
]
},
{
"Listener": {
"InstancePort": 80,
"LoadBalancerPort": 80,
"Protocol": "TCP",
"InstanceProtocol": "TCP"
},
"PolicyNames": []
}
],
...
"Policies": {
"LBCookieStickinessPolicies": [],
"AppCookieStickinessPolicies": [
{
"PolicyName": "my-app-cookie-policy",
"CookieName": "my-app-cookie"
}
],
"OtherPolicies": [
"ELBSecurityPolicy-TLS-1-2-2017-01"
]
},
...
}
]
}
```
# Configure desync mitigation mode for your Classic Load Balancer
Desync mitigation mode protects your application from issues due to HTTP Desync. The load balancer classifies each request based on its threat level, allows safe requests, and then mitigates risk as specified by the mitigation mode that you specify. The desync mitigation modes are monitor, defensive, and strictest. The default is the defensive mode, which provides durable mitigation against HTTP desync while maintaining the availability of your application. You can switch to strictest mode to ensure that your application receives only requests that comply with RFC 7230.
The http\$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.
**Topics**
+ [Classifications](#desync-mitigation-classification)
+ [Modes](#desync-mitigation-modes)
+ [Modify desync mitigation mode](#update-desync-mitigation-mode)
**Tip**
This configuration applies only to Classic Load Balancers. For information that applies to Application Load Balancers, see [Desync mitigation mode for Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#desync-mitigation-mode).
## 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.
The following lists describe the issues for each classification.
**Acceptable**
+ A header contains a non-ASCII or control character.
+ The request version contains a bad value.
+ There is a Content-Length header with a value of 0 for a GET or HEAD request.
+ The request URI contains a space that is not URL encoded.
**Ambiguous**
+ The request URI contains control characters.
+ The request contains both a Transfer-Encoding header and a Content-Length header.
+ There are multiple Content-Length headers with the same value.
+ A header is empty or there is a line with only spaces.
+ There is a header that can be normalized to Transfer-Encoding or Content-Length using common text normalization techniques.
+ There is a Content-Length header for a GET or HEAD request.
+ There is a Transfer-Encoding header for a GET or HEAD request.
**Severe**
+ The request URI contains a null character or carriage return.
+ The Content-Length header contains a value that cannot be parsed or is not a valid number.
+ A header contains a null character or carriage return.
+ The Transfer-Encoding header contains a bad value.
+ The request method is malformed.
+ The request version is malformed.
+ There are multiple Content-Length headers with different values.
+ There are multiple Transfer-Encoding: chunked headers.
If a request does not comply with RFC 7230, the load balancer increments the `DesyncMitigationMode_NonCompliant_Request_Count` metric. For more information, see [Classic Load Balancer metrics](elb-cloudwatch-metrics.md#loadbalancing-metrics-clb).
## Modes
The following table describes how Classic 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.
## Modify desync mitigation mode
**To update desync mitigation mode using the console**
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. Choose the name of the load balancer to open its detail page.
1. On the **Attributes** tab, choose **Edit**.
1. On the **Edit load balancer attributes** page, under **Traffic configuration**, choose **Defensive - recommended**, **Strictest**, or **Monitor**.
1. Choose **Save changes**.
**To update desync mitigation mode using the AWS CLI**
Use the [modify-load-balancer-attributes](https://docs.aws.amazon.com/cli/latest/reference/elb/modify-load-balancer-attributes.html) command with the `elb.http.desyncmitigationmode` attribute set to `monitor`, `defensive`, or `strictest`.
```
aws elb modify-load-balancer-attributes --load-balancer-name my-load-balancer --load-balancer-attributes file://attribute.json
```
The following is the contents of `attribute.json`.
```
{
"AdditionalAttributes": [
{
"Key": "elb.http.desyncmitigationmode",
"Value": "strictest"
}
]
}
```
# Configure proxy protocol for your Classic Load Balancer
Proxy protocol is an internet protocol used to carry connection information from the source requesting the connection to the destination for which the connection was requested. Elastic Load Balancing uses proxy protocol version 1, which uses a human-readable header format.
By default, when you use Transmission Control Protocol (TCP) for both front-end and back-end connections, your Classic Load Balancer forwards requests to the instances without modifying the request headers. If you enable proxy protocol, a human-readable header is added to the request header with connection information such as the source IP address, destination IP address, and port numbers. The header is then sent to the instance as part of the request.
**Note**
The AWS Management Console does not support enabling proxy protocol.
**Topics**
+ [Proxy protocol header](#proxy-protocol)
+ [Prerequisites for enabling proxy protocol](#proxy-protocol-prerequisites)
+ [Enable proxy protocol using the AWS CLI](#enable-proxy-protocol-cli)
+ [Disable proxy protocol using the AWS CLI](#proxy-protocol-disable-policy-cli)
## Proxy protocol header
The proxy protocol header helps you identify the IP address of a client when you have a load balancer that uses TCP for back-end connections. Because load balancers intercept traffic between clients and your instances, the access logs from your instance contain the IP address of the load balancer instead of the originating client. You can parse the first line of the request to retrieve your client's IP address and the port number.
The address of the proxy in the header for IPv6 is the public IPv6 address of your load balancer. This IPv6 address matches the IP address that is resolved from your load balancer's DNS name, which begins with either `ipv6` or `dualstack`. If the client connects with IPv4, the address of the proxy in the header is the private IPv4 address of the load balancer, which is not resolvable through a DNS lookup.
The proxy protocol line is a single line that ends with a carriage return and line feed (`"\r\n"`), and has the following form:
```
PROXY_STRING + single space + INET_PROTOCOL + single space + CLIENT_IP + single space + PROXY_IP + single space + CLIENT_PORT + single space + PROXY_PORT + "\r\n"
```
**Example: IPv4**
The following is an example of the proxy protocol line for IPv4.
```
PROXY TCP4 198.51.100.22 203.0.113.7 35646 80\r\n
```
## Prerequisites for enabling proxy protocol
Before you begin, do the following:
+ Confirm that your load balancer is not behind a proxy server with proxy protocol enabled. If proxy protocol is enabled on both the proxy server and the load balancer, the load balancer adds another header to the request, which already has a header from the proxy server. Depending on how your instance is configured, this duplication might result in errors.
+ Confirm that your instances can process the proxy protocol information.
+ Confirm that your listener settings support proxy protocol. For more information, see [Listener configurations for Classic Load Balancers](using-elb-listenerconfig-quickref.md).
## Enable proxy protocol using the AWS CLI
To enable proxy protocol, you must create a policy of type `ProxyProtocolPolicyType` and then enable the policy on the instance port.
Use the following procedure to create a new policy for your load balancer of type `ProxyProtocolPolicyType`, set the newly created policy to the instance on port `80`, and verify that the policy is enabled.
**To enable proxy protocol for your load balancer**
1. (Optional) Use the following [describe-load-balancer-policy-types](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancer-policy-types.html) command to list the policies supported by Elastic Load Balancing:
```
aws elb describe-load-balancer-policy-types
```
The response includes the names and descriptions of the supported policy types. The following shows the output for the `ProxyProtocolPolicyType` type:
```
{
"PolicyTypeDescriptions": [
...
{
"PolicyAttributeTypeDescriptions": [
{
"Cardinality": "ONE",
"AttributeName": "ProxyProtocol",
"AttributeType": "Boolean"
}
],
"PolicyTypeName": "ProxyProtocolPolicyType",
"Description": "Policy that controls whether to include the IP address and port of the originating
request for TCP messages. This policy operates on TCP/SSL listeners only"
},
...
]
}
```
1. Use the following [create-load-balancer-policy](https://docs.aws.amazon.com/cli/latest/reference/elb/create-load-balancer-policy.html) command to create a policy that enables proxy protocol:
```
aws elb create-load-balancer-policy --load-balancer-name my-loadbalancer --policy-name my-ProxyProtocol-policy --policy-type-name ProxyProtocolPolicyType --policy-attributes AttributeName=ProxyProtocol,AttributeValue=true
```
1. Use the following [set-load-balancer-policies-for-backend-server](https://docs.aws.amazon.com/cli/latest/reference/elb/set-load-balancer-policies-for-backend-server.html) command to enable the newly created policy on the specified port. Note that this command replaces the current set of enabled policies. Therefore, the `--policy-names` option must specify both the policy that you are adding to the list (for example, `my-ProxyProtocol-policy`) and any policies that are currently enabled (for example, `my-existing-policy`).
```
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-loadbalancer --instance-port 80 --policy-names my-ProxyProtocol-policy my-existing-policy
```
1. (Optional) Use the following [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) command to verify that proxy protocol is enabled:
```
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
```
The response includes the following information, which shows that the `my-ProxyProtocol-policy` policy is associated with port `80`.
```
{
"LoadBalancerDescriptions": [
{
...
"BackendServerDescriptions": [
{
"InstancePort": 80,
"PolicyNames": [
"my-ProxyProtocol-policy"
]
}
],
...
}
]
}
```
## Disable proxy protocol using the AWS CLI
You can disable the policies associated with your instance and then enable them at a later time.
**To disable the proxy protocol policy**
1. Use the following [set-load-balancer-policies-for-backend-server](https://docs.aws.amazon.com/cli/latest/reference/elb/set-load-balancer-policies-for-backend-server.html) command to disable the proxy protocol policy by omitting it from the `--policy-names` option, but including the other policies that should remain enabled (for example, `my-existing-policy`).
```
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-loadbalancer --instance-port 80 --policy-names my-existing-policy
```
If there are no other policies to enable, specify an empty string with `--policy-names` option as follows:
```
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-loadbalancer --instance-port 80 --policy-names "[]"
```
1. (Optional) Use the following [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) command to verify that the policy is disabled:
```
aws elb describe-load-balancers --load-balancer-name my-loadbalancer
```
The response includes the following information, which shows that no ports are associated with a policy.
```
{
"LoadBalancerDescriptions": [
{
...
"BackendServerDescriptions": [],
...
}
]
}
```
# Tag your Classic 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 Classic Load Balancer. Tag keys must be unique for 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.
**Topics**
+ [Tag restrictions](#tag-restrictions)
+ [Add a tag](#add-tags)
+ [Remove a tag](#remove-tags)
## Tag restrictions
The following basic restrictions apply to tags:
+ 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.
## Add a tag
You can add tags to your load balancer at any time.
**To add a tag using the console**
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. Choose the name of the load balancer to open its detail page.
1. On the **Tags** tab, choose **Manage tags**.
1. On the **Manage tags** page, for each tag, choose **Add new tag** and then specify a key and a value.
1. After you have finished adding tags, choose **Save changes**.
**To add a tag using the AWS CLI**
Use the following [add-tags](https://docs.aws.amazon.com/cli/latest/reference/elb/add-tags.html) command to add the specified tag:
```
aws elb add-tags --load-balancer-name my-loadbalancer --tag "Key=project,Value=lima"
```
## Remove a tag
You can remove tags from your load balancer whenever you are finished with them.
**To remove a tag using the console**
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. Choose the name of the load balancer to open its detail page.
1. On the **Tags** tab, choose **Manage tags**.
1. On the **Manage tags** page, choose **Remove** next to each tag you want to remove.
1. After you have finished removing tags, choose **Save changes**.
**To remove a tag using the AWS CLI**
Use the following [remove-tags](https://docs.aws.amazon.com/cli/latest/reference/elb/remove-tags.html) command to remove the tag with the specified key:
```
aws elb remove-tags --load-balancer-name my-loadbalancer --tag project
```
# Configure subnets for your Classic Load Balancer
When you add a subnet to your load balancer, Elastic Load Balancing creates a load balancer node in the Availability Zone. Load balancer nodes accept traffic from clients and forward requests to the healthy registered instances in one or more Availability Zones. We recommend that you add one subnet per Availability Zone for at least two Availability Zones. This improves the availability of your load balancer. Note that you can modify the subnets for your load balancer at any time.
Select subnets from the same Availability Zones as your instances. If your load balancer is an internet-facing load balancer, you must select public subnets in order for your back-end instances to receive traffic from the load balancer (even if the back-end instances are in private subnets). If your load balancer is an internal load balancer, we recommend that you select private subnets. For more information about subnets for your load balancer, see [Recommendations for your VPC](elb-backend-instances.md#set-up-ec2).
To add a subnet, register the instances in the Availability Zone with the load balancer, then attach a subnet from that Availability Zone to the load balancer. For more information, see [Register instances with your Classic Load Balancer](elb-deregister-register-instances.md).
After you add a subnet, the load balancer starts routing requests to the registered instances in the corresponding Availability Zone. By default, the load balancer routes requests evenly across the Availability Zones for its subnets. To route requests evenly across the registered instances in the Availability Zones for its subnets, enable cross-zone load balancing. For more information, see [Configure cross-zone load balancing for your Classic Load Balancer](enable-disable-crosszone-lb.md).
You might want to remove a subnet from your load balancer temporarily when its Availability Zone has no healthy registered instances, or when you want to troubleshoot or update the registered instances. After you've removed a subnet, the load balancer stops routing requests to the registered instances in its Availability Zone, but continues to route requests to the registered instances in the Availability Zones for the remaining subnets. Note that after you remove a subnet, the instances in that subnet remain registered with the load balancer, but you can deregister them if you choose. For more information, see [Register instances with your Classic Load Balancer](elb-deregister-register-instances.md).
**Topics**
+ [Requirements](#elb-subnet-requirements)
+ [Configure subnets using the console](#add-remove-subnets-console)
+ [Configure subnets using the CLI](#add-remove-subnets-cli)
## Requirements
When you update the subnets for your load balancer, you must meet the following requirements:
+ The load balancer must have at least one subnet at all times.
+ You can add at most one subnet per Availability Zone.
+ You cannot add a Local Zone subnet.
Because there are separate APIs to add and remove subnets from a load balancer, you must consider the order of operations carefully when swapping the current subnets for new subnets in order to meet these requirements. Also, you must temporarily add a subnet from another Availability Zone if you need to swap all subnets for your load balancer. For example, if your load balancer has a single Availability Zone and you need to swap its subnet for another subnet, you must first add a subnet from a second Availability Zone. Then you can remove the subnet from the original Availability Zone (without going below one subnet), add a new subnet from the original Availability Zone (without exceeding one subnet per Availability Zone), and then remove the subnet from the second Availability Zone (if it is only needed to perform the swap).
## Configure subnets using the console
Use the following procedure to add or remove subnets using the console.
**To configure subnets using the console**
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. Choose the name of the load balancer to open its detail page.
1. On the **Network mapping** tab, choose **Edit subnets**.
1. On the **Edit subnets** page, in the **Network mapping** section, add and remove subnets as needed..
1. When you are finished, choose **Save changes**.
## Configure subnets using the CLI
Use the following examples to add or remove subnets using the AWS CLI.
**To add a subnet to your load balancer using the CLI**
Use the following [attach-load-balancer-to-subnets](https://docs.aws.amazon.com/cli/latest/reference/elb/attach-load-balancer-to-subnets.html) command to add two subnets to your load balancer:
```
aws elb attach-load-balancer-to-subnets --load-balancer-name my-load-balancer --subnets subnet-dea770a9 subnet-fb14f6a2
```
The response lists all subnets for the load balancer. For example:
```
{
"Subnets": [
"subnet-5c11033e",
"subnet-dea770a9",
"subnet-fb14f6a2"
]
}
```
**To remove a subnet using the AWS CLI**
Use the following [detach-load-balancer-from-subnets](https://docs.aws.amazon.com/cli/latest/reference/elb/detach-load-balancer-from-subnets.html) command to remove the specified subnets from the specified load balancer:
```
aws elb detach-load-balancer-from-subnets --load-balancer-name my-loadbalancer --subnets subnet-450f5127
```
The response lists the remaining subnets for the load balancer. For example:
```
{
"Subnets": [
"subnet-15aaab61"
]
}
```
# Configure security groups for your Classic Load Balancer
When you use the AWS Management Console to create a load balancer, you can choose an existing security group or create a new one. If you choose an existing security group, it must allow traffic in both directions to the listener and health check ports for the load balancer. If you choose to create a security group, the console automatically adds rules to allow all traffic on these ports.
[Nondefault VPC] If you use the AWS CLI or API create a load balancer in a nondefault VPC, but you don't specify a security group, your load balancer is automatically associated with the default security group for the VPC.
[Default VPC] If you use the AWS CLI or API to create a load balancer in your default VPC, you can't choose an existing security group for your load balancer. Instead, Elastic Load Balancing provides a security group with rules to allow all traffic on the ports specified for the load balancer. Elastic Load Balancing creates only one such security group per AWS account, with a name of the form default\$1elb\$1*id* (for example, `default_elb_fc5fbed3-0405-3b7d-a328-ea290EXAMPLE`). Subsequent load balancers that you create in the default VPC also use this security group. Be sure to review the security group rules to ensure that they allow traffic on the listener and health check ports for the new load balancer. When you delete your load balancer, this security group is not deleted automatically.
If you add a listener to an existing load balancer, you must review your security groups to ensure they allow traffic on the new listener port in both directions.
**Topics**
+ [Recommended rules for load balancer security groups](#recommended-sg-rules)
+ [Assign security groups using the console](#assign-sg-console)
+ [Assign security groups using the AWS CLI](#assign-sg-cli)
## Recommended rules for load balancer security groups
The security groups for your load balancers must allow them to communicate with your instances. The recommended rules depend on the type of load balancer, internet-facing or internal.
**Internet-facing load balancer**
The following table shows the recommended inbound rules for an internet-facing load balancer.
| Source | Protocol | Port Range | Comment |
| --- | --- | --- | --- |
| 0.0.0.0/0 | TCP | *listener* | Allow all inbound traffic on the load balancer listener port |
The following table shows the recommended outbound rules for an internet-facing load balancer.
| Destination | Protocol | Port Range | Comment |
| --- | --- | --- | --- |
| *instance security group* | TCP | *instance listener* | Allow outbound traffic to instances on the instance listener port |
| *instance security group* | TCP | *health check* | Allow outbound traffic to instances on the health check port |
**Internal load balancers**
The following table shows the recommended inbound rules for an internal load balancer.
| Source | Protocol | Port Range | Comment |
| --- | --- | --- | --- |
| *VPC CIDR* | TCP | *listener* | Allow inbound traffic from the VPC CIDR on the load balancer listener port |
The following table shows the recommended outbound rules for an internal load balancer.
| Destination | Protocol | Port Range | Comment |
| --- | --- | --- | --- |
| *instance security group* | TCP | *instance listener* | Allow outbound traffic to instances on the instance listener port |
| *instance security group* | TCP | *health check* | Allow outbound traffic to instances on the health check port |
## Assign security groups using the console
Use the following procedure to change the security groups associated with your load balancer.
**To update a security group assigned to your load balancer using the console**
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. Choose the name of the load balancer to open its detail page.
1. On the **Security** tab, choose **Edit**.
1. On the **Edit security groups** page, Under **Security groups**, add or remove security groups as needed.
You can add up to five security groups.
1. When you are finished, choose **Save changes**.
## Assign security groups using the AWS CLI
Use the following [apply-security-groups-to-load-balancer](https://docs.aws.amazon.com/cli/latest/reference/elb/apply-security-groups-to-load-balancer.html) command to associate a security group with a load balancer. The specified security groups override the previously associated security groups.
```
aws elb apply-security-groups-to-load-balancer --load-balancer-name my-loadbalancer --security-groups sg-53fae93f
```
The following is an example response:
```
{
"SecurityGroups": [
"sg-53fae93f"
]
}
```
# Configure network ACLs for your Classic Load Balancer
The default network access control list (ACL) for a VPC allows all inbound and outbound traffic. If you create custom network ACLs, you must add rules that allow the load balancer and instances to communicate.
The recommended rules for the subnet for your load balancer depend on the type of load balancer, internet-facing or internal.
**Internet-facing load balancer**
The following are the recommended inbound rules for an internet-facing load balancer.
| Source | Protocol | Port Range | Comment |
| --- | --- | --- | --- |
| 0.0.0.0/0 | TCP | *listener* | Allow all inbound traffic on the load balancer listener port |
| *VPC CIDR* | TCP | 1024-65535 | Allow inbound traffic from the VPC CIDR on the ephemeral ports |
The following are the recommended outbound rules for an internet-facing load balancer.
| Destination | Protocol | Port Range | Comment |
| --- | --- | --- | --- |
| *VPC CIDR* | TCP | *instance listener* | Allow all outbound traffic on the instance listener port |
| *VPC CIDR* | TCP | *health check* | Allow all outbound traffic on the health check port |
| 0.0.0.0/0 | TCP | 1024-65535 | Allow all outbound traffic on the ephemeral ports |
**Internal load balancer**
The following are the recommended inbound rules for an internal load balancer.
| Source | Protocol | Port Range | Comment |
| --- | --- | --- | --- |
| *VPC CIDR* | TCP | *listener* | Allow inbound traffic from the VPC CIDR on the load balancer listener port |
| *VPC CIDR* | TCP | 1024-65535 | Allow inbound traffic from the VPC CIDR on the ephemeral ports |
The following are the recommended outbound rules for an internal load balancer.
| Destination | Protocol | Port Range | Comment |
| --- | --- | --- | --- |
| *VPC CIDR* | TCP | *instance listener* | Allow outbound traffic to the VPC CIDR on the instance listener port |
| *VPC CIDR* | TCP | *health check* | Allow outbound traffic to the VPC CIDR on the health check port |
| *VPC CIDR* | TCP | 1024-65535 | Allow outbound traffic to the VPC CIDR on the ephemeral ports |
# Configure a custom domain name for your Classic Load Balancer
Each Classic Load Balancer receives a default Domain Name System (DNS) name. This DNS name includes the name of the AWS Region in which the load balancer is created. For example, if you create a load balancer named `my-loadbalancer` in the US West (Oregon) Region, your load balancer receives a DNS name such as `my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com`. To access the website on your instances, you paste this DNS name into the address field of a web browser. However, this DNS name is not easy for your customers to remember and use.
If you'd prefer to use a friendly DNS name for your load balancer, such as `www.example.com`, instead of the default DNS name, you can create a custom domain name and associate it with the DNS name for your load balancer. When a client makes a request using this custom domain name, the DNS server resolves it to the DNS name for your load balancer.
**Topics**
+ [Associating your custom domain name with your load balancer name](#dns-associate-custom-elb)
+ [Using Route 53 DNS failover for your load balancer](#configure-dns-failover)
+ [Disassociating your custom domain name from your load balancer](#dns-disassociate-custom-elb)
## Associating your custom domain name with your load balancer name
First, if you haven't already done so, register your domain name. The Internet Corporation for Assigned Names and Numbers (ICANN) manages domain names on the internet. You register a domain name using a *domain name registrar*, an ICANN-accredited organization that manages the registry of domain names. The website for your registrar will provide detailed instructions and pricing information for registering your domain name. For more information, see the following resources:
+ To use Amazon Route 53 to register a domain name, see [Registering domain names using Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html) in the *Amazon Route 53 Developer Guide*.
+ For a list of accredited registrars, see the [List of Accredited Registrars](https://www.icann.org/en/accredited-registrars).
Next, use your DNS service, such as your domain registrar, to create a CNAME record to route queries to your load balancer. For more information, see the documentation for your DNS service.
Alternatively, you can use Route 53 as your DNS service. You create a *hosted zone*, which contains information about how to route traffic on the internet for your domain, and an *alias resource record set*, which routes queries for your domain name to your load balancer. Route 53 doesn't charge for DNS queries for alias record sets, and you can use alias record sets to route DNS queries to your load balancer for the zone apex of your domain (for example, `example.com`). For information about transferring DNS services for existing domains to Route 53, see [Configuring Route 53 as your DNS service](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring.html) in the *Amazon Route 53 Developer Guide*.
Finally, create a hosted zone and an alias record set for your domain using Route 53. For more information, see [Routing traffic to a load balancer](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html) in the *Amazon Route 53 Developer Guide*.
## Using Route 53 DNS failover for your load balancer
If you use Route 53 to route DNS queries to your load balancer, you can also configure DNS failover for your load balancer using Route 53. In a failover configuration, Route 53 checks the health of the registered EC2 instances for the load balancer to determine whether they are available. If there are no healthy EC2 instances registered with the load balancer, or if the load balancer itself is unhealthy, Route 53 routes traffic to another available resource, such as a healthy load balancer or a static website in Amazon S3.
For example, suppose that you have a web application for `www.example.com`, and you want redundant instances running behind two load balancers residing in different Regions. You want the traffic to be primarily routed to the load balancer in one Region, and you want to use the load balancer in the other Region as a backup during failures. If you configure DNS failover, you can specify your primary and secondary (backup) load balancers. Route 53 directs traffic to the primary load balancer if it is available, or to the secondary load balancer otherwise.
**Using evaluate target health**
+ When evaluate target health is set to `Yes` on an alias record for a Classic Load Balancer, Route 53 evaluates the health of the resource specified by the `alias target` value. For a Classic Load Balancer, Route 53 uses the instance health checks associated with the load balancer.
+ When at least one of the registered instances in a Classic Load Balancer is healthy, Route 53 marks the alias record as healthy. Route 53 then returns records according to your routing policy. If the failover routing policy is used, Route 53 returns the primary record.
+ When all the registered instances for a Classic Load Balancer are unhealthy, Route 53 marks the alias record as unhealthy. Route 53 then returns records according to your routing policy. If the failover routing policy is used, then Route 53 returns the secondary record.
For more information, see [Configuring DNS failover](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) in the *Amazon Route 53 Developer Guide*.
## Disassociating your custom domain name from your load balancer
You can disassociate your custom domain name from a load balancer instance by first deleting the resource record sets in your hosted zone and then deleting the hosted zone. For more information, see [Editing records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-editing.html) and [Deleting a public hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/DeleteHostedZone.html) in the *Amazon Route 53 Developer Guide*.