Overview of Elastic Load Balancing

This topic introduces you to Elastic Load Balancing basics you need to understand before you create your load balancer.

Load Balancer

A load balancer is represented by a DNS name and a set of ports. The load balancer is the destination to which all requests intended for your application should be directed. Each load balancer can distribute requests to multiple EC2 instances. Load Balancers can span multiple Availability Zones within an EC2 region, but they cannot span multiple regions.

To create or work with a load balancer in a specific region, use the corresponding regional service endpoint. For information about regions and endpoints supported by Elastic Load Balancing, go to Regions and Endpoints.

If no endpoint is explicitly specified, the US East (Northern Virginia) Region endpoint is used by default.

Elastic Load Balancing automatically generates a DNS name for each load balancer. You can map any other domain name (such as www.example.com) to the automatically generated DNS name using CNAME. Or you can use an Amazon Route 53 alias for the load balancer's DNS name. Amazon Route 53 provides secure and reliable routing to the infrastructure that uses AWS products, such as Amazon EC2, Amazon Simple Storage Service (Amazon S3), or Elastic Load Balancing. For more information on using Amazon Route 53 for your load balancer, see Using Domain Names with Elastic Load Balancing. For information about CNAME records, see the CNAME Record Wikipedia article.

Registering EC2 Instances

Elastic Load Balancing registers your load balancer with your EC2 instances using the IP addresses that are associated with your instances.

When the instance is stopped and then restarted, the IP address associated with your instance changes. Your load balancer cannot recognize the new IP address, which prevents it from routing traffic to your instances. You can de-register your Amazon EC2 instances from your load balancer after you stop your instance, and then register the load balancer with your instance after you've restarted. For more information on deregistering and registering your EC2 instances, see De-Registering and Registering Amazon EC2 Instances.

Availability Zones and Regions

A load balancer can distribute traffic to instances across all Availability Zones within a region. Elastic Load Balancing does not distribute traffic across regions.

For critical applications, we recommend that you distribute incoming traffic across multiple Availability Zones by registering multiple Availability Zones with your load balancer and registering your EC2 instances in each registered Availability Zone.

Incoming traffic is load balanced equally across all Availability Zones enabled for your load balancer, so it is important to have approximately equivalent numbers of instances in each zone. For example, if you have ten instances in Availability Zone us-east-1a and two instances in us-east-1b, the traffic will still be equally distributed between the two Availability Zones. As a result, the two instances in us-east-1b will have to serve the same amount of traffic as the ten instances in us-east-1a. As a best practice, we recommend you keep an equivalent or nearly equivalent number of instances in each of your Availability Zones. So in the example, rather than having ten instances in us-east-1a and two in us-east-1b, you could distribute your instances so that you have six instances in each Availability Zone.

For more information, see Expanding a Load Balanced Application to an Additional Availability Zone.

Sticky Sessions

By default, a load balancer routes each request independently to the application instance with the smallest load. However, you can use the sticky session feature (also known as session affinity), which enables the load balancer to bind a user's session to a specific application instance. This ensures that all requests coming from the user during the session will be sent to the same application instance.

The key to managing the sticky session is determining how long should your load balancer consistently route the user's request to the same application instance. If your application has its own session cookie, then you can set Elastic Load Balancing to create the session cookie to follow the duration specified by the application's session cookie. If your application does not have its own session cookie, then you can set Elastic Load Balancing to create a session cookie by specifying your own stickiness duration. You can associate stickiness duration for only HTTP/HTTPS load balancer listeners.

An application instance must always receive and send two cookies: A cookie that defines the stickiness duration and a special Elastic Load Balancing cookie named AWSELB, that has the mapping to the application instance.

HTTPS Support

HTTPS Support is a feature that allows you to use the SSL/TLS protocol for encrypted connections (also known as SSL offload). This feature enables traffic encryption between your load balancer and clients that initiate HTTPS sessions with your load balancer.

To use HTTPS Support you simply upload your certificate and key and then create a load balancer (or create or update a listener for an existing load balancer) that uses the HTTPS (Secure HTTP) or SSL (Secure TCT) protocol. To upload your certificate and key, you can use the AWS Management Console when you create your load balancer. Alternatively, you can upload the certificate and key using the tools provided by AWS Identity and Access Management (IAM). For more information on uploading SSL certificates, see Managing Server Certificates in the AWS Identity and Access Management documentation.

For more information about the advantages of using HTTPS Support, see Advantages of Using HTTPS/SSL with Elastic Load Balancing. For information about creating a load balancer that uses HTTPS, see Creating a Load Balancer With SSL Cipher Settings and Back-end Server Authentication.

X-Forwarded-For Support

The X-Forwarded-For request header helps you identify the IP address of a client. 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. Elastic Load Balancing stores the IP address of the client in the X-Forwarded-For request header and passes the header along to your server.

The X-Forwarded-For request header takes the following form:

X-Forwarded-For: clientIPAddress

The following example is an X-Forwarded-For request header for a client with an IP address of 203.0.113.7.

X-Forwarded-For: 203.0.113.7

The following example is an X-Forwarded-For request header for a client with an IPv6 address of 2001:DB8::/32:21f:5bff:febf:ce22.

X-Forwarded-For: 2001:DB8::/32:21f:5bff:febf:ce22

If you have back-end application instances in multiple Availability Zones, the X-Forwarded-For request header can contain one or more load balancer IP addresses. Because Elastic Load Balancing uses a different load balancer for each Availability Zone, a client request can be passed from one load balancer to another before reaching a back-end application instance. For example, if you have back-end instances in Availability Zones US-east-1a and US-east-1b, a client request might be handled initially by the load balancer in US-east-1a. If Elastic Load Balancing determines that this request should be routed to US-east-1b, the load balancer in US-east-1a routes the request to the load balancer in US-east-1b. This rerouting may occur if there are no healthy instances in US-east-1a or if sticky sessions are used and the back-end instance is in US-east-1b. Each of the load balancers adds its IP address to the X-Forwarded-For request header.

If more than one load balancer is involved in a client request, the X-Forwarded-For request header takes the following form:

X-Forwarded-For: clientIPAddress, previousLoadBalancerIPAddress

The following example is an X-Forwarded-For request header that arrived at a back-end application instance in the US-east-1b Availability Zone. The client (203.0.113.7) made a request that arrived first at a load balancer in US-east-1a (10.12.33.44). Subsequently, the load balancer for US-east-1a routed the request to the load balancer in US-east-1b (10.73.23.88).

X-Forwarded-For: 203.0.113.7, 10.12.33.44, 10.73.23.88

X-Forwarded-Proto Support

The X-Forwarded-Proto request header helps you identify the protocol ( HTTP or HTTPS) that a client used to connect to your server. Your server access logs contain only the protocol used between the server and the load balancer; they contain no information about the protocol used between the client and the load balancer. To determine the protocol used between the client and the load balancer, use the X-Forwarded-Proto request header. Elastic Load Balancing stores the protocol used between the client and the load balancer in the X-Forwarded-Proto request header and passes the header along to your server.

Your application or website can use the protocol stored in the X-Forwarded-Proto request header to render a response that redirects to the appropriate URL.

The X-Forwarded-Proto request header takes the following form:

X-Forwarded-Proto: originatingProtocol

The following example contains an X-Forwarded-Proto request header for a request that originated from the client as an HTTPS request:

X-Forwarded-Proto: HTTPS