|« 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.
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, 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.
When you use TCP (layer 4) 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. 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.
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.
This configuration will not insert cookies for session stickiness or the 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 registered instance(s). This is the default configuration provided by Elastic Load Balancing.
When you use HTTP/HTTPS, the load balancer inserts or updates the X-Forwarded-For headers and can insert or update cookies for sticky sessions. For more information on sticky sessions, see Sticky Sessions.
If you use HTTPS 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. 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.
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 application. 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 after its validity period ends.
For information on SSL certificates see SSL Certificate for Elastic Load Balancing.
If you choose HTTPS/SSL for your front-end connection, you can either use the predefined SSL negotiation configuration provided by Elastic Load Balancing or create a custom SSL negotiation configuration based on your specific requirements.
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.
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.
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 moves 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.
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.
For configuring listeners:
To learn how to set up a basic HTTP/TCP load balancer using the AWS Management Console, see Get Started with Elastic Load Balancing.
For information on how to set up an HTTPS/SSL load balancer with cipher settings and back-end authentication, see Create a Load Balancer with SSL Cipher Settings and Back-End Server Authentication.
For information on how to set up a basic HTTP/TCP load balancer within Amazon VPC, see Elastic Load Balancing in Amazon VPC.
For information on adding a listener to an existing load balancer, see Adding a Listener to your Load Balancer .
For information on deleting a listener from an existing load balancer, see Delete a Listener from Your Load Balancer.
For performing Elastic Load Balancing tasks:
If you haven't already, install the tools you plan to use for performing Elastic Load Balancing tasks. For information on installing the command line interface or the Query API, see Setting Up Elastic Load Balancing Interfaces.
For information on using the various features supported by Elastic Load Balancing, see Using Elastic Load Balancing.
For detailed descriptions of the Elastic Load Balancing API operations, see the Elastic Load Balancing API Reference.
For detailed descriptions of the Elastic Load Balancing commands, see the Elastic Load Balancing Quick Reference Card.