Elastic Load Balancing

(1)

Elastic Load Balancing

Classic Load Balancers

Elastic Load Balancing: Classic Load Balancers

(2)

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be aﬃliated with, connected to, or sponsored by Amazon.

(3)

What is a Classic Load Balancer?

Elastic Load Balancing automatically distributes your incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones. It monitors the health of its registered targets, and routes traffic only to the healthy targets. Elastic Load Balancing scales your load balancer as your incoming traffic changes over time. It can automatically scale to the vast majority of workloads.

Elastic Load Balancing supports the following load balancers: Application Load Balancers, Network Load Balancers, Gateway Load Balancers, and Classic Load Balancers. You can select the type of load balancer that best suits your needs. This guide discusses Classic Load Balancers. For more information about the other load balancers, see the User Guide for Application Load Balancers, the User Guide for Network Load Balancers, and the User Guide for Gateway Load Balancers.

Classic Load Balancer overview

A load balancer distributes incoming application traﬃc across multiple EC2 instances in multiple Availability Zones. This increases the fault tolerance of your applications. Elastic Load Balancing detects unhealthy instances and routes traﬃc only to healthy instances.

Your load balancer serves as a single point of contact for clients. This increases the availability of your application. You can add and remove instances from your load balancer as your needs change, without disrupting the overall ﬂow of requests to your application. Elastic Load Balancing scales your load balancer as traﬃc to your application changes over time. Elastic Load Balancing can scale to the vast majority of workloads automatically.

A listener checks for connection requests from clients, using the protocol and port that you conﬁgure, and forwards requests to one or more registered instances using the protocol and port number that you conﬁgure. You add one or more listeners to your load balancer.

You can conﬁgure health checks, which are used to monitor the health of the registered instances so that the load balancer only sends requests to the healthy instances.

To ensure that your registered instances are able to handle the request load in each Availability Zone, it is important to keep approximately the same number of instances in each Availability Zone registered

(7)

Beneﬁts

with the load balancer. For example, if you have ten instances in Availability Zone us-west-2a and two instances in us-west-2b, the requests are distributed evenly between the two Availability Zones. As a result, the two instances in us-west-2b serve the same amount of traﬃc as the ten instances in us- west-2a. Instead, you should have six instances in each Availability Zone.

By default, the load balancer distributes traﬃc evenly across the Availability Zones that you enable for your load balancer. To distribute traﬃc evenly across all registered instances in all enabled Availability Zones, enable cross-zone load balancing on your load balancer. However, we still recommend that you maintain approximately equivalent numbers of instances in each Availability Zone for better fault tolerance.

For more information, see How Elastic Load Balancing works in the Elastic Load Balancing User Guide.

Beneﬁts

Using a Classic Load Balancer instead of an Application Load Balancer has the following beneﬁts:

• Support for EC2-Classic

• Support for TCP and SSL listeners

• Support for sticky sessions using application-generated cookies

For more information about the features supported by each load balancer type, see Product comparisons for Elastic Load Balancing.

How to get started

• To learn how to create a Classic Load Balancer and register EC2 instances with it, see Tutorial: Create a Classic Load Balancer (p. 3).

• To learn how to create an HTTPS load balancer and register EC2 instances with it, see Create a Classic Load Balancer with an HTTPS listener (p. 47).

• To learn how to use the various features supported by Elastic Load Balancing, see Conﬁgure your Classic Load Balancer (p. 70).

Pricing

With your load balancer, you pay only for what you use. For more information, see Elastic Load Balancing Pricing.

(8)

Before you begin

Tutorial: Create a Classic Load Balancer

This tutorial provides a hands-on introduction to Classic Load Balancers through the AWS Management Console, a web-based interface. You'll create a load balancer that receives public HTTP traﬃc and sends it to your EC2 instances.

Note that you can create your load balancer for use with EC2-Classic or a VPC. Some of the tasks described in this tutorial apply only to load balancers in a VPC.

Tasks

• Before you begin (p. 3)

• Step 1: Select a load balancer type (p. 3)

• Step 2: Deﬁne your load balancer (p. 4)

• Step 3: Assign security groups to your load balancer in a VPC (p. 5)

• Step 4: Conﬁgure health checks for your EC2 instances (p. 5)

• Step 5: Register EC2 instances with your load balancer (p. 6)

• Step 6: Tag your load balancer (optional) (p. 6)

• Step 7: Create and verify your load balancer (p. 6)

• Step 8: Delete your load balancer (optional) (p. 7)

Before you begin

• Complete the steps in Prepare your VPC and EC2 instances (p. 15).

• Launch the EC2 instances that you plan to register with your load balancer. Ensure that the security groups for these instances allow HTTP access on port 80.

• Install a web server, such as Apache or Internet Information Services (IIS), on each instance, enter its DNS name into the address ﬁeld of an internet-connected web browser, and verify that the browser displays the default page of the server.

Step 1: Select a load balancer type

Elastic Load Balancing supports diﬀerent types of load balancers. For this tutorial, you create a Classic Load Balancer.

To create a Classic Load Balancer

1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.

2. On the navigation bar, choose a Region for your load balancer. Be sure to select the same Region that you selected for your EC2 instances.

3. On the navigation pane, under LOAD BALANCING, choose Load Balancers.

4. Choose Create Load Balancer.

(9)

Step 2: Deﬁne your load balancer

5. For Classic Load Balancer, choose Create.

Step 2: Deﬁne your load balancer

You must provide a basic conﬁguration for your load balancer, such as a name, a network, and a listener.

A listener is a process that checks for connection requests. It is conﬁgured with a protocol and a port for front-end (client to load balancer) connections and a protocol and a port for back-end (load balancer to instance) connections. In this tutorial, you conﬁgure a listener that accepts HTTP requests on port 80 and sends them to your instances on port 80 using HTTP.

To deﬁne your load balancer and listener

1. For Load Balancer name, type a name for your load balancer.

The name of your Classic Load Balancer must be unique within your set of Classic Load Balancers for the region, can have a maximum of 32 characters, can contain only alphanumeric characters and hyphens, and must not begin or end with a hyphen.

2. For Create LB inside, select the same network that you selected for your instances: EC2-Classic or a speciﬁc VPC.

3. [Default VPC] If you selected a default VPC and would like to choose the subnets for your load balancer, select Enable advanced VPC conﬁguration.

4. Leave the default listener conﬁguration.

5. [EC2-VPC] For Available subnets, select at least one available public subnet using its add icon. The subnet is moved under Selected subnets. To improve the availability of your load balancer, select more than one public subnet.

Note

If you selected EC2-Classic as your network, or you have a default VPC but did not select Enable advanced VPC conﬁguration, you do not see the user interface to select subnets.

You can add at most one subnet per Availability Zone. If you select a subnet from an Availability Zone where there is already an selected subnet, this subnet replaces the currently selected subnet for the Availability Zone.

6. Choose Next: Assign Security Groups.

(10)

Step 3: Assign security groups to your load balancer in a VPC

If you selected a VPC as your network, you must assign your load balancer a security group that allows inbound traﬃc to the ports that you speciﬁed for your load balancer and the health checks for your load balancer.

Note

If you selected EC2-Classic as your network, you can continue to the next step. By default, Elastic Load Balancing provides a security group for load balancers in EC2-Classic.

To assign security group to your load balancer

1. On the Assign Security Groups page, select Create a new security group.

2. Type a name and description for your security group, or leave the default name and description.

This new security group contains a rule that allows traﬃc to the port that you conﬁgured your load balancer to use.

3. Choose Next: Conﬁgure Security Settings.

4. For this tutorial, you are not using a secure listener. Choose Next: Conﬁgure Health Check to continue to the next step.

Step 4: Conﬁgure health checks for your EC2 instances

Elastic Load Balancing automatically checks the health of the EC2 instances for your load balancer. If Elastic Load Balancing finds an unhealthy instance, it stops sending traffic to the instance and reroutes traffic to healthy instances. In this step, you customize the health checks for your load balancer.

To conﬁgure health checks for your instances

1. On the Conﬁgure Health Check page, leave Ping Protocol set to HTTP and Ping Port set to 80.

2. For Ping Path, replace the default value with a single forward slash ("/"). This tells Elastic Load Balancing to send health check queries to the default home page for your web server, such as index.html.

3. For Advanced Details, leave the default values.

4. Choose Next: Add EC2 Instances.

(11)

Step 5: Register EC2 instances with your load balancer

Your load balancer distributes traﬃc between the instances that are registered to it.

Note

When you register an instance with an elastic network interface (ENI) attached, the load balancer routes traﬃc to the primary IP address of the primary interface (eth0) of the instance.

To register EC2 instances with your load balancer

1. On the Add EC2 Instances page, select the instances to register with your load balancer.

2. Leave cross-zone load balancing and connection draining enabled.

3. Choose Next: Add Tags.

Alternatively, you can register instances with your load balancer later on using the following options:

• Select running instances after you create the load balancer. For more information, see Register Instances with Your Load Balancer (p. 30).

• Set up Auto Scaling to register the instances automatically when it launches them. For more information, see Set up a scaled and load-balanced application in the Amazon EC2 Auto Scaling User Guide.

Step 6: Tag your load balancer (optional)

You can tag your load balancer, or continue to the next step. Note that you can tag your load balancer later on; for more information, see Tag your Classic Load Balancer (p. 86).

To add tags to your load balancer

1. On the Add Tags page, specify a key and a value for the tag.

2. To add another tag, choose Create Tag and specify a key and a value for the tag.

3. After you are ﬁnished adding tags, choose Review and Create.

Step 7: Create and verify your load balancer

Before you create the load balancer, review the settings that you selected. After creating the load balancer, you can verify that it's sending traﬃc to your EC2 instances.

To create and test your load balancer

1. On the Review page, choose Create.

2. After you are notiﬁed that your load balancer was created, choose Close.

3. Select your new load balancer.

4. On the Description tab, check the Status row. If it indicates that some of your instances are not in service, its probably because they are still in the registration process. For more information, see Troubleshoot a Classic Load Balancer: Instance registration (p. 119).

5. After at least one of your EC2 instances is in service, you can test your load balancer. Copy the string from DNS name (for example, my-load-balancer-1234567890.us-west-2.elb.amazonaws.com)

(12)

Step 8: Delete your load balancer (optional)

and paste it into the address ﬁeld of an internet-connected web browser. If your load balancer is working, you see the default page of your server.

Step 8: Delete your load balancer (optional)

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 a load balancer, you can delete it. As soon as the load balancer is deleted, you stop incurring charges for it. Note that deleting a load balancer does not aﬀect the instances registered with the load balancer.

To delete your load balancer

1. If you have a CNAME record for your domain that points to your load balancer, point it to a new location and wait for the DNS change to take eﬀect before deleting your load balancer.

4. Select the load balancer.

5. Choose Actions, Delete.

6. When prompted for conﬁrmation, choose Yes, Delete.

7. (Optional) After you delete a load balancer, the EC2 instances associated with the load balancer continue to run, and you are billed for each hour or partial hour that you keep them running. For information about stopping or terminating your instances, see Stop and start your instance or Terminate your instance in the Amazon EC2 User Guide for Linux Instances.

(13)

Public DNS names for your load balancer

Internet-facing Classic Load Balancers

An internet-facing load balancer has a publicly resolvable DNS name, so it can route requests from clients over the internet to the EC2 instances that are registered with the load balancer.

If a load balancer is in a VPC with ClassicLink enabled, its instances can be linked EC2-Classic instances. If a load balancer is in EC2-Classic, its instances must be in EC2-Classic.

Contents

• Public DNS names for your load balancer (p. 8)

• Create an internet-facing load balancer (p. 9)

Public DNS names for your load balancer

When your load balancer is created, it receives a public DNS name that clients can use to send requests.

The DNS servers resolve the DNS name of your load balancer to the public IP addresses of the load balancer nodes for your load balancer. Each load balancer node is connected to the back-end instances using private IP addresses.

EC2-VPC

Load balancers in a VPC support IPv4 addresses only. The console displays a public DNS name with the following form:

name-1234567890.region.elb.amazonaws.com

EC2-Classic

Load balancers in EC2-Classic support both IPv4 and IPv6 addresses. The console displays the following public DNS names:

(14)

Create an internet-facing load balancer

name-123456789.region.elb.amazonaws.com

ipv6.name-123456789.region.elb.amazonaws.com dualstack.name-123456789.region.elb.amazonaws.com

The base public DNS name returns only IPv4 records. The public DNS name with the ipv6 preﬁx returns only IPv6 records. The public DNS name with the dualstack preﬁx returns both IPv4 and IPv6 records.

We recommend that you enable IPv6 support by using the DNS name with the dualstack preﬁx to ensure that clients can access the load balancer using either IPv4 or IPv6.

Clients can connect to your load balancer in EC2-Classic using either IPv4 or IPv6. However,

communication between the load balancer and its back-end instances uses only IPv4, regardless of how the client communicates with your load balancer.

Create an internet-facing load balancer

When you create a load balancer in a VPC, you can make it an internal load balancer or an internet-facing load balancer. You create an internet-facing load balancer in a public subnet. Load balancers in EC2- Classic are always internet-facing load balancers.

When you create your load balancer, you configure listeners, configure health checks, and register back- end instances. You configure a listener by specifying a protocol and a port for front-end (client to load balancer) connections, and a protocol and a port for back-end (load balancer to back-end instances) connections. You can configure multiple listeners for your load balancer.

To create a basic internet-facing load balancer, see Tutorial: Create a Classic Load Balancer (p. 3).

To create a load balancer with an HTTPS listener, see Create a Classic Load Balancer with an HTTPS listener (p. 47).

(15)

Public DNS name for your load balancer

Internal Classic Load Balancers

When you create a load balancer in a VPC, you must choose whether to make it an internal load balancer or an internet-facing load balancer.

The nodes of an internet-facing load balancer have public IP addresses. The DNS name of an internet- facing load balancer is publicly resolvable to the public IP addresses of the nodes. Therefore, internet- facing load balancers can route requests from clients over the internet. For more information, see Internet-facing Classic Load Balancers (p. 8).

The nodes of an internal load balancer have only private IP addresses. The DNS name of an internal load balancer is publicly resolvable to the private IP addresses of the nodes. Therefore, internal load balancers can only route requests from clients with access to the VPC for the load balancer.

If your application has multiple tiers, for example web servers that must be connected to the internet and database servers that are only connected to the web servers, you can design an architecture that uses both internal and internet-facing load balancers. Create an internet-facing load balancer and register the web servers with it. Create an internal load balancer and register the database servers with it. The web servers receive requests from the internet-facing load balancer and send requests for the database servers to the internal load balancer. The database servers receive requests from the internal load balancer.

Contents

• Public DNS name for your load balancer (p. 10)

• Create an internal Classic Load Balancer (p. 11)

Public DNS name for your load balancer

When an internal load balancer is created, it receives a public DNS name with the following form:

(16)

Create an internal load balancer

internal-name-123456789.region.elb.amazonaws.com

The DNS servers resolve the DNS name of your load balancer to the private IP addresses of the load balancer nodes for your internal load balancer. Each load balancer node is connected to the private IP addresses of the back-end instances using elastic network interfaces. If cross-zone load balancing is enabled, each node is connected to each back-end instance, regardless of Availability Zone. Otherwise, each node is connected only to the instances that are in its Availability Zone.

Create an internal Classic Load Balancer

You can create an internal load balancer to distribute traﬃc to your EC2 instances from clients with access to the VPC for the load balancer.

Contents

• Prerequisites (p. 11)

• Create an internal load balancer using the console (p. 11)

• Create an internal load balancer using the AWS CLI (p. 13)

Prerequisites

• If you have not yet created a VPC for your load balancer, you must create it before you get started. For more information, see Prepare your VPC and EC2 instances (p. 15).

• Launch the EC2 instances that you plan to register with your internal load balancer. Ensure that you launch them in private subnets in the VPC intended for the load balancer.

Create an internal load balancer using the console

By default, Elastic Load Balancing creates an internet-facing load balancer. Use the following procedure to create an internal load balancer and register your EC2 instances with the newly created internal load balancer.

To create an internal load balancer

3. Choose Create Load Balancer.

4. For Select load balancer type, choose Classic Load Balancer.

5. On the Deﬁne Load Balancer page, do the following:

a. For Load Balancer name, type a name for your load balancer.

The name of your Classic Load Balancer must be unique within your set of Classic Load

Balancers for the region, can have a maximum of 32 characters, can contain only alphanumeric characters and hyphens, and must not begin or end with a hyphen.

b. For Create LB inside, select a VPC for your load balancer.

c. Choose Create an internal load balancer.

d. [Default VPC] If you selected a default VPC and would like to select subnets for your load balancer, choose Enable advanced VPC conﬁguration.

e. Leave the default listener conﬁguration.

(17)

Create an internal load balancer using the console

f. For Available subnets, select at least one available subnet using its add icon. The subnet is moved under Selected subnets. To improve the availability of your load balancer, select more than one subnet.

Note

If you selected a default VPC as your network, but did not select Enable advanced VPC conﬁguration, you do not have the option to select subnets.

You can attach at most one subnet per Availability Zone. If you select a subnet from an Availability Zone where there is already an attached subnet, this subnet replaces the currently attached subnet for the Availability Zone.

g. Choose Next: Assign Security Groups.

6. On the Assign Security Groups page, choose Create a new security group. Enter a name and description for your security group, or leave the default name and description. This new security group contains a rule that allows traﬃc to the port that you conﬁgured your load balancer to use.

If you will use a different port for the health checks, you must choose Add Rule to add a rule that allows inbound traffic to that port as well. Choose Next: Configure Security Settings.

7. On the Conﬁgure Security Settings page, choose Next: Conﬁgure Health Check to continue to the next step. If you prefer to create a HTTPS load balancer, see HTTPS listeners for your Classic Load Balancer (p. 40).

8. On the Conﬁgure Health Check page, conﬁgure the health check settings that your application requires, and then choose Next: Add EC2 Instances.

9. On the Add EC2 Instances page, select the instances to register with your load balancer, and then choose Next: Add Tags.

Note

When you register an instance with an elastic network interface (ENI) attached, the load balancer routes traﬃc to the primary IP address of the primary interface (eth0) of the instance.

10. (Optional) You can add tags to your load balancer. When you are ﬁnished adding tags, choose Review and Create.

11. On the Review page, check your settings. If you need to make changes, choose the corresponding link to edit the settings. When you are ﬁnished, choose Create.

12. After you are notiﬁed that your load balancer was created, choose Close.

13. Select your new load balancer.

14. On the Description tab, note that DNS name and Scheme indicate that the load balancer is internal.

Check the Status row. If it indicates that some of your instances are not in service, its probably because they are still in the registration process. For more information, see Troubleshoot a Classic Load Balancer: Instance registration (p. 119).

(18)

Create an internal load balancer using the AWS CLI

By default, Elastic Load Balancing creates an internet-facing load balancer. Use the following procedure to create an internal load balancer and register your EC2 instances with the newly created internal load balancer.

To create an internal load balancer

1. Use the create-load-balancer command with the --scheme option set to internal, as follows:

aws elb create-load-balancer --load-balancer-name my-internal-loadbalancer --listeners Protocol=HTTP,LoadBalancerPort=80,InstanceProtocol=HTTP,InstancePort=80

--subnets subnet-4e05f721 --scheme internal --security-groups sg-b9ffedd5

The following is an example response. Note that the name indicates that this is an internal load balancer.

{ "DNSName": "internal-my-internal-loadbalancer-786501203.us- west-2.elb.amazonaws.com"

}

2. Use the following register-instances-with-load-balancer command to add instances:

aws elb register-instances-with-load-balancer --load-balancer-name my-internal- loadbalancer --instances i-4f8cf126 i-0bb7ca62

The following is an example response:

{ "Instances": [ {

"InstanceId": "i-4f8cf126"

}, {

"InstanceId": "i-0bb7ca62"

} ] }

3. (Optional) Use the following describe-load-balancers command to verify the internal load balancer:

aws elb describe-load-balancers --load-balancer-name my-internal-loadbalancer

The response includes the DNSName and Scheme ﬁelds, which indicate that this is an internal load balancer.

{ "LoadBalancerDescriptions": [ {

...

"DNSName": "internal-my-internal-loadbalancer-1234567890.us- west-2.elb.amazonaws.com",

"SecurityGroups": [ "sg-b9ffedd5"

],

"Policies": {

"LBCookieStickinessPolicies": [],

(19)

Create an internal load balancer using the AWS CLI

"AppCookieStickinessPolicies": [], "OtherPolicies": []

},

"LoadBalancerName": "my-internal-loadbalancer", "CreatedTime": "2014-05-22T20:32:19.920Z", "AvailabilityZones": [

"us-west-2a"

],

"Scheme": "internal", ...

} ] }

(20)

Best practices for your instances

Registered instances for your Classic Load Balancer

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.

Contents

• Best practices for your instances (p. 15)

• Prepare your VPC and EC2 instances (p. 15)

• Conﬁgure health checks for your Classic Load Balancer (p. 16)

• Conﬁgure security groups for your Classic Load Balancer (p. 19)

• Add or remove Availability Zones for your load balancer in EC2-Classic (p. 26)

• Add or remove subnets for your Classic Load Balancer in a VPC (p. 28)

• Register or deregister EC2 instances for your Classic Load Balancer (p. 30)

Best practices for your instances

• 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 in the Amazon EC2 User Guide for Linux Instances.

Prepare your VPC and EC2 instances

We recommend that you launch your instances and create your load balancer in a virtual private cloud (VPC). If you have a new AWS account or plan to use a Region that you haven't used before, you have a default VPC. You can use a default VPC if you have one, or create your own VPC.

Load balancers in a VPC

Amazon Virtual Private Cloud (Amazon VPC) enables you to deﬁne a virtual networking environment in a private, isolated section of the AWS cloud. Within this virtual private cloud (VPC), you can launch AWS resources such as load balancers and EC2 instances. For more information, see the Amazon VPC User Guide.

Subnets for your load balancer

(21)

Conﬁgure health checks

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.

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.

Security groups

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 Security groups for load balancers in a VPC (p. 20). The security group for your instances must allow traﬃc in both directions on both ports for each subnet for your load balancer. For more information, see Security groups for instances in a VPC (p. 22).

Network ACLs

The network ACLs for your VPC must allow traﬃc in both directions on the listener port and the health check port. For more information, see Network ACLs for load balancers in a VPC (p. 22).

ClassicLink

ClassicLink enables your EC2-Classic instances to communicate with VPC instances using private IP addresses, provided that the VPC security groups allow it. If you plan to register linked EC2-Classic instances with your load balancer, you must enable ClassicLink for your VPC, and then create your load balancer in the ClassicLink-enabled VPC. For more information, see ClassicLink basics and Working with ClassicLink in the Amazon EC2 User Guide for Linux Instances.

Conﬁgure health checks for your Classic Load Balancer

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 in the Amazon EC2 Auto Scaling User Guide.

(22)

Health check conﬁguration

Contents

• Health check conﬁguration (p. 17)

• Update the health check conﬁguration (p. 18)

• Check the health of your instances (p. 18)

• Troubleshoot health checks (p. 19)

Health check conﬁguration

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 speciﬁed port within the conﬁgured 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.

(23)

Update the health check conﬁguration

Field Description

Unhealthy Threshold The number of consecutive failed health checks that must occur before declaring an EC2 instance unhealthy.

Healthy Threshold The number of consecutive successful health checks that must occur before declaring an EC2 instance healthy.

The load balancer sends a health check request to each registered instance every Interval seconds, using the speciﬁed 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 aﬀect 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 conﬁguration

You can update the health check conﬁguration for your load balancer at any time.

To update the health check conﬁguration for your load balancer using the console

3. Select your load balancer.

4. On the Health Check tab, choose Edit Health Check.

5. On the Conﬁgure Health Check page, update the conﬁguration as needed.

6. Choose Save.

To update the health check conﬁguration for your load balancer using the AWS CLI Use the following conﬁgure-health-check 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.

(24)

Troubleshoot health checks

To check the health status of your instances using the console

4. On the Description tab, Status indicates how many instances are in service.

5. On the Instances tab, the Status column indicates the status of each instance.

To check the health status of your instances using the AWS CLI Use the following describe-instance-health 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 (p. 115).

Conﬁgure security groups for your Classic Load Balancer

A security group acts as a ﬁrewall that controls the traﬃc 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 traﬃc. 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 in the Amazon EC2 User Guide for Linux Instances.

There is a significant difference between the way Classic Load Balancers support security groups in EC2- Classic and in a VPC. In EC2-Classic, the load balancer provides a special source security group that you can use to ensure that instances receive traffic only from your load balancer. You can't modify this source security group. In a VPC, you provide the security group for your load balancer, which enables you to 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).

In both EC2-Classic and in a VPC, you must ensure that the security groups for your instances allow the load balancer to communicate with your instances on both the listener port and the health check port. In a VPC, your security groups and network access control lists (ACL) must allow traﬃc in both directions on these ports.

Contents

• Security groups for load balancers in a VPC (p. 20)

• Security groups for instances in a VPC (p. 22)

• Network ACLs for load balancers in a VPC (p. 22)

(25)

Security groups for load balancers in a VPC

• Security groups for instances in EC2-Classic (p. 24)

Security groups for load balancers in a VPC

When you use the AWS Management Console to create a load balancer in a VPC, you can choose an existing security group for the VPC or create a new security group for the VPC. If you choose an existing security group, it must allow traﬃc 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 traﬃc 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 traﬃc on the ports speciﬁed for the load balancer. Elastic Load Balancing creates only one such security group per AWS account, with a name of the form default_elb_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 traﬃc 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 traﬃc on the new listener port in both directions.

Contents

• Recommended rules for load balancer security groups (p. 20)

• Manage security groups using the console (p. 21)

• Manage security groups using the AWS CLI (p. 21)

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).

The following table shows the recommended rules for an internet-facing load balancer.

Inbound

Source Protocol Port Range Comment

0.0.0.0/0 TCP listener Allow all inbound traﬃc

on the load balancer listener port

Outbound

Destination Protocol Port Range Comment

instance security group

TCP instance listener Allow outbound traﬃc to instances on the instance listener port

(26)

Security groups for load balancers in a VPC

TCP health check Allow outbound traﬃc to instances on the health check port

The following table shows the recommended rules for an internal load balancer.

Inbound

VPC CIDR TCP listener Allow inbound traﬃc

from the VPC CIDR on the load balancer listener port

Outbound

Destination Protocol Port Range Comment

TCP instance listener Allow outbound traﬃc to instances on the instance listener port instance security

group

TCP health check Allow outbound traﬃc to instances on the health check port

Manage security groups using the console

Use the following procedure to change the security groups associated with your load balancer in a VPC.

To update a security group assigned to your load balancer

4. On the Description tab, choose Edit security groups.

5. On the Edit security groups page, select or clear security groups as needed.

6. When you are ﬁnished, choose Save.

Manage security groups using the AWS CLI

Use the following apply-security-groups-to-load-balancer command to associate a security group with a load balancer in a VPC. The speciﬁed 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:

{

(27)

Security groups for instances in a VPC

"SecurityGroups": [ "sg-53fae93f"

]}

Security groups for instances in a VPC

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

Inbound

load balancer

security group TCP instance listener Allow traﬃc from the load balancer on the instance listener port load balancer

security group

TCP health check Allow traﬃc from the load balancer on the health check port

We also recommend that you allow inbound ICMP traﬃc to support Path MTU Discovery. For more information, see Path MTU Discovery in the Amazon EC2 User Guide for Linux Instances.

Network ACLs for load balancers in a VPC

The default network access control list (ACL) for the VPC allows all inbound and outbound traﬃc. 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).

The following are the recommended rules for an internet-facing load balancer.

Inbound

Source Protocol Port Comment

0.0.0.0/0 TCP listener Allow all inbound traﬃc

on the load balancer listener port

VPC CIDR TCP 1024-65535 Allow inbound traﬃc

from the VPC CIDR on the ephemeral ports Outbound

Destination Protocol Port Comment

VPC CIDR TCP instance listener Allow all outbound traﬃc on the instance listener port

(28)

Network ACLs for load balancers in a VPC

VPC CIDR TCP health check Allow all outbound

traﬃc on the health check port

0.0.0.0/0 TCP 1024-65535 Allow all outbound

traﬃc on the ephemeral ports

The following are the recommended rules for an internal load balancer.

Inbound

VPC CIDR TCP listener Allow inbound traﬃc

from the VPC CIDR on the load balancer listener port

VPC CIDR TCP 1024-65535 Allow inbound traﬃc

from the VPC CIDR on the ephemeral ports Outbound

VPC CIDR TCP instance listener Allow outbound traﬃc to the VPC CIDR on the instance listener port

VPC CIDR TCP health check Allow outbound traﬃc

to the VPC CIDR on the health check port

VPC CIDR TCP 1024-65535 Allow outbound traﬃc

to the VPC CIDR on the ephemeral ports

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.

Inbound

VPC CIDR TCP instance listener Allow inbound traﬃc from the VPC CIDR on the instance listener port

VPC CIDR TCP health check Allow inbound traﬃc

from the VPC CIDR on the health check port Outbound

(29)

Security groups for instances in EC2-Classic

VPC CIDR TCP 1024-65535 Allow outbound traﬃc

to the VPC CIDR on the ephemeral ports

Security groups for instances in EC2-Classic

To allow communication between your load balancer and your instances launched in EC2-Classic, create an inbound rule for the security group for your instances that allows inbound traﬃc from either all IP addresses (using the 0.0.0.0/0 CIDR block) or only from the load balancer (using the source security group provided by Elastic Load Balancing).

Use the following procedure to lock down traﬃc between your load balancer and your instances in EC2- Classic.

To lock down traﬃc between your load balancer and instances using the console

4. On the Description tab, copy the name of the source security group.

5. On the Instances tab, select the instance ID of one of the instances registered with your load balancer.

6. On the Description tab, for Security groups, select the name of the security group.

7. On the Inbound tab, choose Edit, Add Rule.

8. From the Type column, select the protocol type. The Protocol and Port Range columns are populated. From the Source column, select Custom IP and then paste the name of the source security group that you copied earlier (for example, amazon-elb/amazon-elb-sg).

9. (Optional) If your security group has rules that are less restrictive than the rule that you just added, remove the less restrictive rule using its delete icon.

To lock down traﬃc between your load balancer and instances using the AWS CLI

1. Use the following describe-load-balancers command to display the name and owner of the source security group for your load balancer:

aws elb describe-load-balancers --load-balancer-name my-loadbalancer

The response includes the name and owner in the SourceSecurityGroup ﬁeld. For example:

{ "LoadBalancerDescriptions": [ {

...

"SourceSecurityGroup": {

"OwnerAlias": "amazon-elb", "GroupName": "amazon-elb-sg"

(30)

Security groups for instances in EC2-Classic

} } ] }

2. Add a rule to the security group for your instances as follows:

a. If you do not know the name of the security group for your instances, use the following describe-instances command to get the name and ID of the security group for the speciﬁed instance:

aws ec2 describe-instances --instance-ids i-315b7e51

The response includes the name and ID of the security group in the SecurityGroups ﬁeld.

Make a note of the name of the security group; you'll use it in the next step.

b. Use the following authorize-security-group-ingress command to add a rule to the security group for your instance to allow traﬃc from your load balancer:

aws ec2 authorize-security-group-ingress --group-name my-security-group --source- security-group-name amazon-elb-sg --source-security-group-owner-id amazon-elb 3. (Optional) Use the following describe-security-groups command to verify that the security group has

the new rule:

aws ec2 describe-security-groups --group-names my-security-group

The response includes a UserIdGroupPairs data structure that lists the security groups that are granted permissions to access the instance.

{

"SecurityGroups": [ {

...

"IpPermissions": [ {

"IpRanges": [], "FromPort": -1, "IpProtocol": "icmp", "ToPort": -1,

"UserIdGroupPairs": [ {

"GroupName": "amazon-elb-sg", "GroupId": "sg-5a9c116a", "UserId": "amazon-elb"

} ] }, {

"IpRanges": [], "FromPort": 1, "IpProtocol": "tcp", "ToPort": 65535, "UserIdGroupPairs": [ {

} ] },

(31)

Add or remove Availability Zones

{

"IpRanges": [], "FromPort": 1, "IpProtocol": "udp", "ToPort": 65535, "UserIdGroupPairs": [ {

} ] }, . . . }

4. (Optional) If your security group has rules that are less restrictive than the rule you just added, use the revoke-security-group-ingress command to remove the less restrictive rules. For example, the following command removes a rule that allows TCP traﬃc from everyone (CIDR range 0.0.0.0/0):

aws ec2 revoke-security-group-ingress --group-name my-security-group --protocol tcp -- port 80 --cidr 0.0.0.0/0

Add or remove Availability Zones for your load balancer in EC2-Classic

When you add an Availability Zone to your load balancer, Elastic Load Balancing creates a load balancer node in the Availability Zone. Load balancer nodes accept traﬃc from clients and forward requests to the healthy registered instances in one or more Availability Zones.

You can set up your load balancer in EC2-Classic to distribute incoming requests across EC2 instances in a single Availability Zone or multiple Availability Zones. First, launch EC2 instances in all the Availability Zones that you plan to use. Next, register these instances with your load balancer. Finally, add the Availability Zones to your load balancer. After you add an Availability Zone, the load balancer starts routing requests to the registered instances in that Availability Zone. Note that you can modify the Availability Zones for your load balancer at any time.

By default, the load balancer routes requests evenly across its Availability Zones. To route requests evenly across the registered instances in the Availability Zones, enable cross-zone load balancing. For more information, see Conﬁgure cross-zone load balancing for your Classic Load Balancer (p. 71).

You might want to remove an Availability Zone from your load balancer temporarily when it has no healthy registered instances or when you want to troubleshoot or update the registered instances. After you've removed an Availability Zone, the load balancer stops routing requests to the registered instances in this Availability Zone but continues to route requests to the registered instances in the remaining Availability Zones.

If your load balancer is in a VPC, see Add or remove subnets for your Classic Load Balancer in a VPC (p. 28).

Contents

• Add an Availability Zone (p. 27)

• Remove an Availability Zone (p. 27)

(32)

Add an Availability Zone

You can expand the availability of your application to an additional Availability Zone. Register the instances in this Availability Zone with the load balancer, then add the Availability Zone. For more information, see Register or deregister EC2 instances for your Classic Load Balancer (p. 30).

To add an Availability Zone using the console

4. On the Instances tab, choose Edit Availability Zones.

5. On the Add and Remove Availability Zones page, select the Availability Zone.

6. Choose Save.

To add an Availability Zone using the AWS CLI

Use the following enable-availability-zones-for-load-balancer command to add an Availability Zone:

aws elb enable-availability-zones-for-load-balancer --load-balancer-name my-loadbalancer -- availability-zones us-west-2b

The response lists all Availability Zones for the load balancer. For example:

{

"AvailabilityZones": [ "us-west-2a",

"us-west-2b"

]}

Remove an Availability Zone

You can remove an Availability Zone from your load balancer. Note that after you remove an Availability Zone, the instances in that Availability Zone remain registered with the load balancer. For more

information, see Register or deregister EC2 instances for your Classic Load Balancer (p. 30).

To remove an Availability Zone using the console

4. On the Instances tab, choose Edit Availability Zones.

5. On the Add and Remove Availability Zones page, clear the Availability Zone.

6. Choose Save.

To remove an Availability Zone using the AWS CLI

Use the following disable-availability-zones-for-load-balancer command:

aws elb disable-availability-zones-for-load-balancer --load-balancer-name my-loadbalancer --availability-zones us-west-2a

(33)

Add or remove subnets

The response lists the remaining Availability Zones for the load balancer. For example:

{ "AvailabilityZones": [ "us-west-2b"

] }

Add or remove subnets for your Classic Load Balancer in a VPC

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 traﬃc from clients and forward requests to the healthy registered instances in one or more Availability Zones. For load balancers in a VPC, 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 traﬃc 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 Prepare your VPC and EC2 instances (p. 15).

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 Conﬁgure cross-zone load balancing for your Classic Load Balancer (p. 71).

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.

If your load balancer is in EC2-Classic, see Add or remove Availability Zones for your load balancer in EC2-Classic (p. 26).

Contents

• Requirements (p. 28)

• Add a subnet (p. 29)

• Remove a subnet (p. 29)

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.

(34)

Add a 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 ﬁrst 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).

Add a subnet

You can expand the availability of your load balancer to an additional subnet. Register the instances in this subnet with the load balancer, then attach a subnet to the load balancer that is from the same Availability Zone as the instances. For more information, see Register or deregister EC2 instances for your Classic Load Balancer (p. 30).

To add a subnet to your load balancer using the console

4. In the bottom pane, select the Instances tab.

5. Choose Edit Availability Zones.

6. For Available Subnets, select the subnet using its add (+) icon. The subnet is moved under Selected subnets.

Note that you can select at most one subnet per Availability Zone. If you select a subnet from an Availability Zone where there is already an selected subnet, this subnet replaces the currently selected subnet for the Availability Zone.

7. Choose Save.

To add a subnet to your load balancer using the CLI

Use the following attach-load-balancer-to-subnets 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"

] }

Remove a subnet

You can remove a subnet from your load balancer. Note that after you remove a subnet, the instances in that subnet remain registered with the load balancer. For more information, see Register or deregister EC2 instances for your Classic Load Balancer (p. 30).

Elastic Load Balancing