Before you start using Elastic Load Balancing, you must configure one or more listeners for your load balancer. A listener is a process that checks for connection requests. It is configured 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 back-end instance) connections.
Elastic Load Balancing supports the following protocols:
HTTPS (secure HTTP)
SSL (secure TCP)
The HTTPS protocol uses the SSL protocol to establish secure connections over the HTTP layer. You can also use the SSL protocol to establish secure connections over the TCP layer.
If the front-end connection uses TCP or SSL, then your back-end connections can use either TCP or SSL. If the front-end connection uses HTTP or HTTPS, then your back-end connections can use either HTTP or HTTPS.
Back-end instances can listen on all ports in the ephemeral port range (1-65535).
Load balancers can listen on the following ports: 25, 80, 443, 465, 587, and 1024-65535.
Communication for a typical web application 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 more information, see OSI model in Wikipedia.
When you use Elastic Load Balancing, you need a basic understanding of 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.
The Secure Sockets Layer (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.
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 modifying the headers. After your load balancer receives the request, it 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 for 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 with the connection information of the client, such as the source IP address, destination IP address, and port numbers. 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 more information, see Configure Proxy Protocol Support for Your Load Balancer.
Using this configuration, you do not receive cookies for session stickiness or X-Forwarded headers.
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 instances.
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 an HTTP/HTTPS load balancer, Elastic Load Balancing opens and maintains one or more TCP connections. These 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 messages. 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,
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 are sent to the same back-end instance. For more information, see Configure Sticky Sessions for Your Load Balancer.
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.
You can create an HTTPS load balancer with the following security features.
If you use HTTPS or SSL for your front-end listener, you must install an X.509 certificate (SSL server 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. You must create the certificate, get the certificate signed by a Certificate Authority (CA), and upload the certificate using AWS Identity and Access Management (IAM). For more information, see SSL Certificates for Elastic Load Balancing.
Elastic Load Balancing provides predefined SSL negotiation configurations that 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, you can create a custom SSL negotiation configuration, based on your specific requirements. Your ciphers and protocols should take effect within 30 seconds. For more information, see SSL Negotiation Configurations for Elastic Load Balancing.
If want to use SSL, but don't want to terminate the connection on your load balancer, you can use TCP for connections from the client to your load balancer, use the SSL protocol for connections from the load balancer to your back-end application, and install certificates on all the back-end instances handling requests.
If you 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 on your back-end instances, including a self-signed certificate.
For more information, see Configure Back-end Server Authentication.