# Registered instances for your Classic Load Balancer
Registered instances

After you've created your Classic Load Balancer, you must register your EC2 instances with the load balancer. You can select EC2 instances from a single Availability Zone or multiple Availability Zones within the same Region as the load balancer. Elastic Load Balancing routinely performs health checks on registered EC2 instances, and automatically distributes incoming requests to the DNS name of your load balancer across the registered, healthy EC2 instances.

**Topics**
+ [

## Best practices for your instances
](#backend-instance-best-practices)
+ [

## Recommendations for your VPC
](#set-up-ec2)
+ [Register instances with your load balancer](elb-deregister-register-instances.md)
+ [Health checks](elb-healthchecks.md)
+ [Security groups](elb-instances-security-groups.md)
+ [Network ACLs](elb-instances-network-acls.md)

## Best practices for your instances

+ You must ensure that the load balancer can communicate with your instances on both the listener port and the health check port. For more information, see [Configure security groups for your Classic Load Balancer](elb-vpc-security-groups.md). The security group for your instances must allow traffic in both directions on both ports for each subnet for your load balancer.
+ Install a web server, such as Apache or Internet Information Services (IIS), on all instances that you plan to register with your load balancer.
+ For HTTP and HTTPS listeners, we recommend that you enable the keep-alive option in your EC2 instances, which enables the load balancer to re-use the connections to your instances for multiple client requests. This reduces the load on your web server and improves the throughput of the load balancer. The keep-alive timeout should be at least 60 seconds to ensure that the load balancer is responsible for closing the connection to your instance.
+ Elastic Load Balancing supports Path Maximum Transmission Unit (MTU) Discovery. To ensure that Path MTU Discovery can function correctly, you must ensure that the security group for your instance allows ICMP fragmentation required (type 3, code 4) messages. 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*.

## Recommendations for your VPC


**Virtual private cloud (VPC)**  
Unless you created your AWS account before 2014, you have a default VPC in each Region. You can use a default VPC for your load balancer, if you have one, or you can create a new VPC. For more information, see the *[Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/)*.

**Subnets for your load balancer**  
To ensure that your load balancer can scale properly, verify that each subnet for your load balancer has a CIDR block with at least a `/27` bitmask (for example, `10.0.0.0/27`) and has at least 8 free IP addresses. Your load balancer uses these IP addresses to establish connections with the instances, and to scale out when necessary. If there are insufficient IP addresses, the load balancer might be unable to scale, causing 503 errors due to insufficient capacity.

Create a subnet in each Availability Zone where you want to launch instances. Depending on your application, you can launch your instances in public subnets, private subnets, or a combination of public and private subnets. A public subnet has a route to an internet gateway. Note that default VPCs have one public subnet per Availability Zone by default.

When you create a load balancer, you must add one or more public subnets to the load balancer. If your instances are in private subnets, create public subnets in the same Availability Zones as the subnets with your instances; you will add these public subnets to the load balancer.

**Network ACLs**  
The network ACLs for your VPC must allow traffic in both directions on the listener port and the health check port. For more information, see [Network ACLs for the instances for your Classic Load Balancer](elb-instances-network-acls.md).

# Register instances with your Classic Load Balancer
Register instances with your load balancer

Registering an EC2 instance adds it to your load balancer. The load balancer continuously monitors the health of registered instances in its enabled Availability Zones, and routes requests to the instances that are healthy. If demand on your instances increases, you can register additional instances with the load balancer to handle the demand.

Deregistering an EC2 instance removes it from your load balancer. The load balancer stops routing requests to an instance as soon as it is deregistered. If demand decreases, or you need to service your instances, you can deregister instances from the load balancer. An instance that is deregistered remains running, but no longer receives traffic from the load balancer, and you can register it with the load balancer again when you are ready.

When you deregister an instance, Elastic Load Balancing waits until in-flight requests have completed if connection draining is enabled. For more information, see [Configure connection draining for your Classic Load Balancer](config-conn-drain.md).

If your load balancer is attached to an Auto Scaling group, instances in the group are automatically registered with the load balancer. If you detach a load balancer from your Auto Scaling group, the instances in the group are deregistered.

Elastic Load Balancing registers your EC2 instance with your load balancer using its IP address.

[EC2-VPC] When you register an instance with an elastic network interface (ENI) attached, the load balancer routes requests to the primary IP address of the primary interface (eth0) of the instance.

**Topics**
+ [

## Register an instance
](#elb-register-instances)
+ [

## View the instances registered with a load balancer
](#elb-describe-load-balancer-instances)
+ [

## Determine the load balancer for a registered instance
](#elb-describe-instance-load-balancer)
+ [

## Deregister an instance
](#elb-deregister-instances)

## Register an instance


When you are ready, register your instance with your load balancer. If the instance is an in Availability Zone that is enabled for the load balancer, the instance is ready to receive traffic from the load balancer as soon as it passes the required number of health checks.

**To register your instances 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 **Target instances** tab, select **Manage instances**.

1. On the **Manage instances** page, within the **Available instances** table, select the instances to register with your load balancer.

1. Ensure the instances needing to be registered are populated within the **Review selected instances** table.

1. Choose **Save changes**.

**To register your instances using the AWS CLI**  
Use the following [register-instances-with-load-balancer](https://docs.aws.amazon.com/cli/latest/reference/elb/register-instances-with-load-balancer.html) command:

```
aws elb register-instances-with-load-balancer --load-balancer-name my-loadbalancer --instances i-4e05f721
```

The following is an example response that lists the instances registered with the load balancer:

```
{
    "Instances": [
        {
            "InstanceId": "i-315b7e51"
        }, 
        {
            "InstanceId": "i-4e05f721"
        }
    ]
}
```

## View the instances registered with a load balancer


Use the following [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) command to list the instances registered with the specified load balancer:

```
aws elb describe-load-balancers --load-balancer-names my-load-balancer --output text --query "LoadBalancerDescriptions[*].Instances[*].InstanceId"
```

The following is example output:

```
i-e905622e
i-315b7e51
i-4e05f721
```

## Determine the load balancer for a registered instance


Use the following [describe-load-balancers](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html) command to get the name of the load balancer to which the specified instance is registered:

```
aws elb describe-load-balancers --output text --query "LoadBalancerDescriptions[?Instances[?InstanceId=='i-e905622e']].[LoadBalancerName]"
```

The following is example output:

```
my-load-balancer
```

## Deregister an instance


You can deregister an instance from your load balancer if you no longer need the capacity or if you need to service the instance.

If your load balancer is attached to an Auto Scaling group, detaching the instance from the group also deregisters it from the load balancer. For more information, see [Detach EC2 instances from your Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-detach-attach-instances.html) in the *Amazon EC2 Auto Scaling User Guide*.

**To deregister your instances 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 **Target instances** tab, select **Manage instances**.

1. On the **Manage instances** page, within the **Available instances** table, deselect the instances to deregister from your load balancer.

1. Ensure the instances needing to be deregistered are not populated within the **Review selected instances** table.

1. Choose **Save changes**.

**To deregister your instances using the AWS CLI**  
Use the following [deregister-instances-from-load-balancer](https://docs.aws.amazon.com/cli/latest/reference/elb/deregister-instances-from-load-balancer.html) command:

```
aws elb deregister-instances-from-load-balancer --load-balancer-name my-loadbalancer --instances i-4e05f721
```

The following is an example response that lists the remaining instances registered with the load balancer:

```
{
    "Instances": [
        {
            "InstanceId": "i-315b7e51"
        }
    ]
}
```

# Health checks for the instances for your Classic Load Balancer
Health checks

Your Classic Load Balancer periodically sends requests to its registered instances to test their status. These tests are called *health checks*. The status of the instances that are healthy at the time of the health check is `InService`. The status of any instances that are unhealthy at the time of the health check is `OutOfService`. The load balancer performs health checks on all registered instances, whether the instance is in a healthy state or an unhealthy state.

The load balancer routes requests only to the healthy instances. When the load balancer determines that an instance is unhealthy, it stops routing requests to that instance. The load balancer resumes routing requests to the instance when it has been restored to a healthy state.

The load balancer checks the health of the registered instances using either the default health check configuration provided by Elastic Load Balancing or a health check configuration that you configure.

If you have associated your Auto Scaling group with a Classic Load Balancer, you can use the load balancer health check to determine the health state of instances in your Auto Scaling group. By default an Auto Scaling group periodically determines the health state of each instance. For more information, see [Add Elastic Load Balancing health checks to your Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html) in the *Amazon EC2 Auto Scaling User Guide*.

**Topics**
+ [

## Health check configuration
](#health-check-configuration)
+ [

## Update the health check configuration
](#update-health-check-config)
+ [

## Check the health of your instances
](#check-instance-health)
+ [

## Troubleshoot health checks
](#troubleshoot-health-checks)

## Health check configuration


A health configuration contains the information that a load balancer uses to determine the health state of the registered instances. The following table describes the health check configuration fields.


| Field | Description | 
| --- | --- | 
|  Protocol  |  The protocol to use to connect with the instance. Valid values: `TCP`, `HTTP`, `HTTPS`, and `SSL` Console default: `HTTP` CLI/API default: `TCP`  | 
|  Port  |  The port to use to connect with the instance, as a `protocol:port` pair. If the load balancer fails to connect with the instance at the specified port within the configured response timeout period, the instance is considered unhealthy. Protocols: `TCP`, `HTTP`, `HTTPS`, and `SSL` Port range: 1 to 65535 Console default: `HTTP:80` CLI/API default: `TCP:80`  | 
|  Path  |  The destination for the HTTP or HTTPS request. An HTTP or HTTPS GET request is issued to the instance on the port and the path. If the load balancer receives any response other than "200 OK" within the response timeout period, the instance is considered unhealthy. If the response includes a body, your application must either set the Content-Length header to a value greater than or equal to zero, or specify Transfer-Encoding with a value set to 'chunked'. Default: `/index.html`  | 
|  Response Timeout  |  The amount of time to wait when receiving a response from the health check, in seconds. Valid values: 2 to 60 Default: 5  | 
|  HealthCheck Interval  |  The amount of time between health checks of an individual instance, in seconds. Valid values: 5 to 300 Default: 30  | 
|  Unhealthy Threshold  |  The number of consecutive failed health checks that must occur before declaring an EC2 instance unhealthy. Valid values: 2 to 10 Default: 2  | 
|  Healthy Threshold  |  The number of consecutive successful health checks that must occur before declaring an EC2 instance healthy. Valid values: 2 to 10 Default: 10  | 

The load balancer sends a health check request to each registered instance every `Interval` seconds, using the specified port, protocol, and path. Each health check request is independent and lasts the entire interval. The time it takes for the instance to respond does not affect the interval for the next health check. If the health checks exceed **UnhealthyThresholdCount** consecutive failures, the load balancer takes the instance out of service. When the health checks exceed **HealthyThresholdCount** consecutive successes, the load balancer puts the instance back in service.

An HTTP/HTTPS health check succeeds if the instance returns a 200 response code within the health check interval. A TCP health check succeeds if the TCP connection succeeds. An SSL health check succeeds if the SSL handshake succeeds.

## Update the health check configuration


You can update the health check configuration for your load balancer at any time.

**To update the health check configuration 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 **Health checks** tab, choose **Edit**.

1. On the **Edit health check settings** page, under **Health checks**, update the configuration as needed.

1. After you're satisfied with your selections, choose **Save changes**.

**To update the health check configuration for your load balancer using the AWS CLI**  
Use the following [configure-health-check](https://docs.aws.amazon.com/cli/latest/reference/elb/configure-health-check.html) command:

```
aws elb configure-health-check --load-balancer-name my-load-balancer --health-check Target=HTTP:80/path,Interval=30,UnhealthyThreshold=2,HealthyThreshold=2,Timeout=3
```

## Check the health of your instances


You can check the health status of your registered instances.

**To check the health status of your instances 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. In the **Details** section, **Status** indicates how many instances are in service.

1. On the **Target instances** tab, within the **Target instances** table, the **Health status** column indicates the specific status of each registered instance.

**To check the health status of your instances using the AWS CLI**  
Use the following [describe-instance-health](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-instance-health.html) command:

```
aws elb describe-instance-health --load-balancer-name my-load-balancer
```

## Troubleshoot health checks


Your registered instances can fail the load balancer health check for several reasons. The most common reasons for failing a health check are where EC2 instances close connections to your load balancer or where the response from the EC2 instances times out. For information about potential causes and steps you can take to resolve failed health check issues, see [Troubleshoot a Classic Load Balancer: Health checks](ts-elb-healthcheck.md).

# Security groups for the instances for your Classic Load Balancer
Security groups

A *security group* acts as a firewall that controls the traffic allowed to and from one or more instances. When you launch an EC2 instance, you can associate one or more security groups with the instance. For each security group, you add one or more rules to allow traffic. You can modify the rules for a security group at any time; the new rules are automatically applied to all instances associated with the security group. For more information, see [Amazon EC2 security groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) in the *Amazon EC2 User Guide*.

The security groups for your instances must allow them to communicate with the load balancer. The following table shows the recommended inbound rules.


| Source | Protocol | Port Range | Comment | 
| --- | --- | --- | --- | 
| *load balancer security group* | TCP | *instance listener* | Allow traffic from the load balancer on the instance listener port | 
| *load balancer security group* | TCP | *health check* | Allow traffic from the load balancer on the health check port | 

We also 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*.

# Network ACLs for the instances for your Classic Load Balancer
Network ACLs

A *network access control list* (ACL) allows or denies specific inbound or outbound traffic at the subnet level. You can use the default network ACL for your VPC, or you can create a custom network ACL for your VPC with rules that are similar to the rules for your security groups in order to add an additional layer of security to your VPC.

The default network access control list (ACL) for the 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 instances depend on whether the subnet is private or public. The following rules are for a private subnet. If your instances are in a public subnet, change the source and destination from the CIDR of the VPC to `0.0.0.0/0`.

The following are the recommended inbound rules.


| Source | Protocol | Port Range | Comment | 
| --- | --- | --- | --- | 
|  *VPC CIDR*  |  TCP  |  *instance listener*  |  Allow inbound traffic from the VPC CIDR on the instance listener port  | 
|  *VPC CIDR*  |  TCP  |  *health check*  |  Allow inbound traffic from the VPC CIDR on the health check port  | 

The following are the recommended outbound rules.


| Destination | Protocol | Port Range | Comment | 
| --- | --- | --- | --- | 
|  *VPC CIDR*  |  TCP  |  1024-65535  |  Allow outbound traffic to the VPC CIDR on the ephemeral ports  |