Elastic Load Balancing
Developer Guide (API Version 2012-06-01)
Did this page help you?  Yes | No |  Tell us about it...
« PreviousNext »
View the PDF for this guide.Go to the AWS Discussion Forum for this product.Go to the Kindle Store to download this guide in Kindle format.

Listener Configurations for Elastic Load Balancing

A typical web application communication goes through layers of hardware and software. Each layer provides a specific communication function. The control over the communication function is passed from one layer to the next, in sequence. The Open System Interconnection (OSI) defines a model framework for implementing a standard format for communication, called a protocol, in these layers. For detailed information about the layers of the OSI model, go to http://en.wikipedia.org/wiki/OSI_model.

When you use Elastic Load Balancing, you need to have a basic understanding of two layers: layer 4 and layer 7. Layer 4 is the transport layer that describes the Transmission Control Protocol (TCP) connection between the client and your back-end instance, through the load balancer. Layer 4 is the lowest level that is configurable for your load balancer. Layer 7 is the application layer that describes the use of Hypertext Transfer Protocol (HTTP) and HTTPS (secure HTTP) connections from clients to the load balancer and from the load balancer to your back-end instance.

You also need to have an understanding of the Secure Sockets Layer (SSL) protocol. The SSL protocol is primarily used to encrypt confidential data over insecure networks such as the Internet. The SSL protocol establishes a secure connection between a client and the back-end server and ensures that all the data passed between your client and your server is private and integral.


Before you start using Elastic Load Balancing, you have to configure the listeners for your load balancer. A listener is a process that listens for connection requests. It is configured with a protocol and a port number for front-end (client to load balancer) and back-end (load balancer to back-end instance) connections.

Elastic Load Balancing supports the load balancing of applications using HTTP, HTTPS (secure HTTP), TCP, and SSL (secure TCP) protocols. The HTTPS uses the SSL protocol to establish secure connections over the HTTP layer. You can also use SSL protocol to establish secure connections over the TCP layer.

The acceptable ports for both HTTPS/SSL and HTTP/TCP connections are 25, 80, 443, 465, 587, and 1024-65535.

You can specify the protocols for the front-end connections (client to load balancer) and the back-end connections (load balancer to back-end instance) independently. The front-end connection and the back-end connection must be from the same layer. For example, if your front-end connection is using the TCP or SSL protocol then your back-end connection can either be TCP or SSL. If the front-end connection of your load balancer is using HTTP or HTTPS then your back-end connections can either be HTTP or HTTPS.

By default, your load balancer is set to use the HTTP protocol with port 80 for the front-end connection and the back-end connection. The default settings can be changed using the AWS Management Console, the Query API, the command line interface (CLI), or the SDKs.

Using TCP/SSL Protocol with Elastic Load Balancing

When you use TCP (layer 4) for both front-end and back-end connections, your load balancer forwards the request to the back-end instances without modification to the headers. After getting the request, your load balancer attempts to open a TCP connection to the back-end instance on the port specified in the health check configuration. 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.

Because load balancers intercept traffic between clients and your back-end instances, the access logs from your back-end instance contain the IP address of the load balancer instead of the originating client. You can enable Proxy Protocol, which adds a header containing the connection information, such as the source IP address, the destination IP address, and the port numbers of the client. The header is then sent to the back-end instance as a part of the request. You can parse the first line in the request to retrieve the connection information. For information about enabling Proxy Protocol, see Enable or Disable Proxy Protocol Support.

This configuration will not insert cookies for session stickiness or the X-Forwarded-* headers.

Using HTTP/HTTPS Protocol with Elastic Load Balancing

When you use HTTP (layer 7) for both front-end and back-end connections, your load balancer parses the headers in the request and terminates the connection before re-sending the request to the back-end instance(s). This is the default configuration provided by Elastic Load Balancing.

To connect with the back-end instances, an HTTP GET request or an HTTPS GET request is issued to the instance on the ping port and the ping path specified in the health check configuration. If the load balancer receives any response other than "200 OK" within the response timeout period, the instance is considered unhealthy.

For every registered and healthy instance behind a HTTP/HTTPS load balancer, Elastic Load Balancing opens and maintains one or more TCP connections. The pre-opened connections ensure that there is always an established connection ready to receive HTTP/HTTPS requests.

The HTTP requests and HTTP responses use header fields to send information about HTTP message. Elastic Load Balancing supports X-Forwarded-For headers. Because load balancers intercept traffic between clients and servers, your server access logs contain only the IP address of the load balancer. To see the IP address of the client, use the X-Forwarded-For request header. For more information, see X-Forwarded-For.

When you use HTTP/HTTPS, you can enable sticky sessions on your load balancer. A sticky session binds a user’s session to a specific back-end instance. This ensures that all requests coming from the user during the session will be sent to the same back-end instance. For more information on sticky sessions, see Sticky Sessions.

Not all HTTP extensions are supported in the load balancer. In some cases you will need to use a TCP listener if the load balancer is not able to terminate the request due to unexpected methods, response codes, or other non-standard HTTP 1.0/1.1 implementations.

SSL Server Certificates

If you use HTTPS or SSL for your front-end listener, you must install an SSL certificate on your load balancer. The load balancer uses the certificate to terminate the connection and then decrypt requests from clients before sending them to the back-end instances.

The SSL protocol uses an X.509 certificate (SSL server certificate) to authenticate both the client and the back-end instance. The X.509 certificate is a digital form of identification issued by a certificate authority (CA) and contains identification information, a validity period, a public key, a serial number, and the digital signature of the issuer.

Before you can install the SSL certificate on your load balancer, you must create the certificate, get the certificate signed by a CA, and then upload the certificate using the AWS Identity and Access Management (AWS IAM) service.

The SSL certificate comes with a validity period. You must replace the certificate before its validity period ends. For information on creating SSL certificate see SSL Certificate for Elastic Load Balancing. For procedure related to replacing your existing certificate, see Update an SSL Certificate for a Load Balancer.

SSL Negotiation

Elastic Load Balancing provides security policies that have predefined SSL negotiation configurations. These configurations are used for SSL negotiation when a connection is established between a client and your load balancer. The SSL negotiation configurations provide compatibility with a broad range of clients and use high-strength cryptographic algorithms called ciphers. However, some use cases might require all data on the network to be encrypted and allow only specific ciphers. Some security compliance standards (such as PCI, SOX, and so on) might require a specific set of protocols and ciphers from clients to ensure that the security standards are met. In such cases, Elastic Load Balancing provides options for selecting different configurations for protocols and ciphers, based on your specific requirements. Depending on the number of nodes, your ciphers and protocols should take effect within 30 seconds.

If you use SSL/HTTPS protocol for your front-end connection, you can either use one of the predefined security policies or create a custom security policy.For information about the predefined SSL negotiation configurations used by Elastic Load Balancing, see SSL Negotiation Configurations for Elastic Load Balancing. For information on how to configure the ciphers and protocols, see Step 2: Configure SSL Security Policy.

Using Back-End Server Authentication with Elastic Load Balancing

If want to use an SSL protocol but do not want to terminate the connection on your load balancer, you can use a TCP protocol for connection from the client to your load balancer, use the SSL protocol for connection from the load balancer to your back-end application, and install certificates on all the back-end instances handling requests.

If you choose to use an HTTPS/SSL connection for your back end, you can enable authentication on your back-end instance. This authentication can be used to ensure that back-end instances accept only encrypted communication and to ensure that the back-end instance has the correct certificates.

You can install any certificate you want on your back-end instances, including a self-signed certificate.

For a quick reference to the listener configurations supported by Elastic Load Balancing, see Elastic Load Balancing Listener Configurations Quick Reference.

Next Steps

For configuring listeners:

For performing Elastic Load Balancing tasks: