I have a Classic Load Balancer with duration-based or application-controlled session stickiness. The load balancer is configured to route client HTTP or HTTPS sessions to the same registered instance, but client requests are being routed to different registered instances. How can I troubleshoot problems with Elastic Load Balancing (ELB) session stickiness?

By default, a Classic Load Balancer routes each request to the registered instance with the fewest outstanding requests. Using sticky sessions (session affinity) configures a load balancer to bind user sessions to a specific instance, so all requests from a user during a session are sent to the same instance. A sticky session can fail if:

1.    The registered instance is not inserting an application cookie.

2.    The client is not returning the cookies in the request header.

3.    The cookies inserted by a registered instance are not formatted correctly.

4.    The expiration period specified when using a duration-based sticky session has passed.

5.    The HTTP or HTTPS request is passing through more than one load balancer that has stickiness enabled.

Note: The load balancer session stickiness feature is supported only with HTTP or HTTPS listeners.

Application-controlled session stickiness

1.    Check for HTTP errors with your Classic Load Balancer. For more information, see Troubleshoot a Classic Load Balancer: HTTP Errors.

2.    Run a command similar to the following to the load balancer DNS name. Check for the these two cookies in the response:

  • An application cookie is inserted by your application running on a backend instance.
  • An AWSELB cookie is inserted by the load balancer.

Note: Before you run this command, be sure to replace the DNS name with the name of your load balancer.  

[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-TESTELB-1430759361.eu-central-1.elb.amazonaws.com

Note: The curl utility is native to Linux, but can also be installed on Windows.

The following is an example response to the command:

...

< Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/
< Set-Cookie: 
AWSELB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/

...

Note: If there is no AWSELB cookie in the response, then there is no stickiness between the client and the backend instance.

3.    Verify that the registered instance is inserting an application cookie by sending an HTTP request directly to the registered instance IP by running a command similar to the following:

[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null 172.31.30.168

The command returns a response similar to the following example:

...

< Set-Cookie: PHPSESSID=5pq74110nuir60kpapj04mglg4; path=/

...

4.    Verify that the cookie name generated by the registered instance is the same as the cookie name configured on the load balancer.

5.    If the registered instances insert an application cookie in their responses and the load balancer inserts an AWSELB cookie, be sure that the client sends both of these cookies in subsequent requests. If the client fails to include either the application or the AWSELB cookie, then stickiness won't work. To verify that the client sends both the application and AWSELB cookies, take a packet capture on the client or use the browser’s web-debugging tools to retrieve the cookie information in the request header.

6.    If you want to know which backend instance that the load balancer routed the request to, you can configure the backend instance to display the instance ID using Instance Metadata by running a script similar to the following:

<?php $instance_id =file_get_contents('http://169.254.169.254/latest/meta-data/instance-id');
echo "instance id = " . $instance_id . "\\xA";
?> 

7.    Review your ELB access log to check if requests from the same user were routed to different registered instances. For more information about reviewing ELB access logs, see Access Logs for Your Classic Load Balancer.

8.    Verify that the cookie inserted by the application is formatted correctly for HTTP.

9.    If your request is passing through multiple load balancers, verify that stickiness is enabled on only one load balancer. If more than one load balancer inserts a cookie, it replaces the original cookie and stickiness fails.

Duration-based session stickiness

1.    Run a command similar to the following to the load balancer DNS name to check for an AWSELB cookie in the response:  

[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-TESTELB-1430759361.eu-central-1.elb.amazonaws.com

The command returns a response similar to the following example:

...

< Set-Cookie: 
AWSELB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/

...

Note: If there is no AWSELB cookie in the response, then there is no stickiness between the client and the backend instance.

2.    If the load balancer inserts an AWSELB cookie, be sure that the client sends this cookie in subsequent requests. If the client fails to include the AWSELB cookie, then stickiness won't work. To verify that the client sends the AWSELB cookie, take a packet capture on the client or use the browser’s web-debugging tools to retrieve the cookie information in the request header.

3.    Check the duration configured on the load balancer. If the cookie expiration period has passed, client sessions no longer stick to the registered instance until a new cookie is issued by the load balancer.

4.    If your request is passing through multiple load balancers, verify that stickiness is enabled on only one load balancer. If more than one load balancer inserts a cookie, it replaces the original cookie and stickiness fails.  


Did this page help you? Yes | No

Back to the AWS Support Knowledge Center

Need help? Visit the AWS Support Center

Published: 2018-03-30