|« PreviousNext »|
|Did this page help you? Yes | No | Tell us about it...|
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.
Elastic Load Balancing supports the load balancing of applications using HTTP, HTTPS , TCP, and Secure Sockets Layer (SSL) protocols. 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. If you choose HTTPS/SSL protocols for your front-end connection, the back-end connection to the instance can either be in plain text or HTTPS/SSL. If you choose HTTP for your front-end connection, the back-end connection to the instance can be HTTP or HTTPS.
The acceptable ports for both HTTPS/SSL and HTTP/TCP connections are 25, 80, 443, and 1024-65535.
Before you start using Elastic Load Balancing, you'll have to configure the listeners for your load balancer. Listener is a process that listens for client connection requests. It is configured with a protocol and a port number for front-end (Load Balancer) and back-end (Back-end instance) connections.
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.
When you use TCP for both front-end and back-end connections, your load balancer will forward the request to the back-end instances without modification to the headers. This configuration will also not insert cookies for session stickiness or the X-Forwarded-* headers.
If you use SSL (secure TCP) for your front-end connection, you will have to install an SSL server certificate on your load balancer. The load balancer uses the certificate to first terminate and then decrypt the requests before sending the requests to the back-end instances. With this configuration, you can also choose to configure ciphers for SSL negotiation between your client and the load balancer.
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 registered instance(s). This is the default configuration provided by Elastic Load Balancing.
If you use HTTPS (secure HTTP) for your front-end listener, you must install an SSL server certificate on your load balancer. The load balancer uses the certificate to terminate and then decrypt requests before sending them to the back-end instances. Additionally, when you use HTTPS, the load balancer inserts or updates the X-Forwarded-* headers and can insert or update cookies for sticky sessions. For more information on X-Forwarded-* headers, see X-Forwarded-For. With this configuration, you can also choose to configure ciphers for SSL negotiation between your client and the 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.
Elastic Load Balancing provides SSL support for connections between clients and the load balancer and also for connections between the load balancer and your back-end application instances. Support for an end-to-end HTTPS/SSL connection enables traffic encryption on those network segments that initiate HTTPS/SSL connections.
There are several advantages to using HTTPS/SSL connections with your load balancer:
The SSL server certificate used to terminate client connections can be managed centrally on the load balancer, rather than on every individual application instance.
The work of encrypting and decrypting SSL traffic is moved from the application instance to the load balancer.
The load balancer can ensure session affinity or "sticky sessions" by terminating the incoming HTTPS request and then re-encrypting the content to send to the back-end application instance.
All of the features available for HTTP can be used with HTTPS connections.
Using HTTPS/SSL protocols for both front-end and back-end connections ensures end-to-end traffic encryption. If you are using SSL and do not want Elastic Load Balancing to terminate, you can use a TCP listener and install certificates on all the back-end instances handling requests.
To enable HTTPS support, use AWS Identity and Access Management (IAM) to upload your SSL certificate and key. After you upload your certificate, specify its Amazon Resource Name (ARN) when you create a new load balancer or update an existing load balancer. For more information see Creating a HTTPS/SSL Load Balancer.
To update an existing SSL certificate, use IAM to upload your new SSL certificate. After you upload the new certficate, update your load balancer with the new certificate. For more information, see How to Update an SSL Certificate for a Load Balancer.
If you choose HTTPS/SSL for your front-end connection, you can either use the pre-defined SSL cipher set or use a cipher set of your choice to enable or disable the ciphers based on your specific requirements.
The Secure Sockets Layer (SSL) protocol uses a combination of protocols and algorithms to protect your information over the internet. A SSL cipher is an encryption algorithm that uses encryption keys to create a ciphered (coded) message. There are multiple forms of SSL cipher algorithms available.
Elastic Load Balancing configures your load balancer with a pre-defined cipher set that is used for SSL negotiation when a connection is established between a client and your load balancer. The pre-defined cipher set provides compatibility with a broad range of clients and uses high strength cryptographic algorithms. However, in some use cases there might be a requirement for all data on the network to be encrypted and for allowing only specific ciphers. Some use cases might require specific protocols (such as PCI, SOX, etc.) from clients to ensure that standards are met. In such cases, Elastic Load Balancing provides options for you to select different configurations for SSL protocols and ciphers. You can choose to enable or disable the ciphers depending on your specific requirements. Depending on the number of nodes, your ciphers and protocols should take less than 30 seconds to take effect.
For information on how to configure the cipher settings, see Creating a HTTPS/SSL Load Balancer.
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.
For a quick reference to the listener configurations supported by Elastic Load Balancing, see Elastic Load Balancing Listener Configurations Quick Reference.