Skip to content

How do I troubleshoot Application Load Balancer session stickiness issues?

5 minute read
0

I have an Application Load Balancer that uses duration-based stickiness or application-based stickiness sessions. However, the user sessions route to different targets.

Short description

Sticky sessions use cookies to bind a user's session to a specific target. As a result, all requests from the user during the session go to the same target.

A sticky session might fail for the following reasons:

  • The registered target didn't generate a cookie.
  • The client didn't return the cookie in the request header.
  • The cookies aren't correctly formatted.
  • The duration-based session is over.
  • The session request passed through multiple load balancers.
  • The target's health status changed to unhealthy.
  • An AWS service turned off stickiness.

Resolution

Prerequisite: Make sure that your Application Load Balancer meets the sticky session requirements.

Troubleshoot application-based session stickiness

Make sure that the registered target's cookie name matches the load balancer's cookie name

To check the load balancer's cookies, run the following command:

curl -vko /dev/null name-id.elb.region.amazonaws.com

Note: Replace name with your load balancer name, id with your AWS account ID, and region with your AWS Region. If your load balancer uses host-based routing rules, then add the -H "Host: your-domain.com" flag to the preceding command. Replace your-domain with your domain name. To install the Linux curl utility on the Windows operating system (OS), see curl 8.21.0 for Windows on the curl website.

Example output:

...
< Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/

< Set-Cookie:

AWSALBAPP-0=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/

...

Note: In the preceding example, the cookie name is PHPSESSID.

Confirm that the registered target generated an application cookie. Run the following command to send an HTTP request to the IP address of the target Amazon Elastic Compute Cloud (Amazon EC2) instance:

curl -vko /dev/null 000.00.00.000

Note: Replace 000.00.00.000 with your target's IP address. If your load balancer uses host-based routing rules, then add the -H "Host: your-domain.com" flag to the preceding command. Replace your-domain with your domain name.

Example output:

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

...

To check the cookie name that the target uses, complete the following steps:

  1. Open the Amazon EC2 console.
  2. On the navigation pane, under Load Balancing, choose Target Groups.
  3. Choose the target group.
  4. Choose the Attributes tab, and then choose Edit.
  5. Under Target selection configuration, check the value for App cookie name.

Make sure that the client sends both the target application and load balancer cookies

The client must send both the target's application cookie and the load balancer's AWSALBAPP cookie. To check the cookies that the client sends, take a packet capture of the client. To retrieve the cookie information in the request header, use a browser web debugging tool, tcpdump on the tcpdump website, or Wireshark utility on the Wireshark website.

Make sure that the targets have a healthy status

Confirm that all targets in the target group that uses stickiness have a Healthy health check status. To troubleshoot unhealthy targets, see Troubleshoot unhealthy targets using the resource map.

Note: If the target health status changes to Unhealthy, then stickiness breaks and the load balancer doesn't route requests to that target. The load balancer selects a new healthy target to establish a sticky session with.

Check whether stickiness was deactivated

Check the AWS CloudTrail Event history for the ModifyTargetGroupAttributes and the stickiness.enabled attribute to identify whether an AWS service deactivated stickiness. Services such as Amazon Elastic Kubernetes Service (Amazon EKS) might deactivate stickiness.

Duration-based session stickiness

To confirm that there's stickiness between the client and backend Amazon EC2 instance, run the following command to check for an AWSALB cookie;

curl -vko /dev/null name-id.elb.region.amazonaws.com

Note: Replace name with your load balancer name, id with your account ID, and region with your Region. If your load balancer uses host-based routing rules, then add the -H "Host: your-domain.com" flag to the preceding command. Replace your-domain with your domain name.

Example output:

...
< Set-Cookie: AWSALB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/
...

If the load balancer didn't generate an AWSALB cookie, then make sure that you meet the sticky session requirements.

To confirm that the client sends the cookie in subsequent requests, take a packet capture of the client. To retrieve the cookie information in the request header, use a browser web debugging tool, tcpdump on the tcpdump website, or Wireshark utility on the Wireshark website.

If the client doesn't include the AWSALB cookie, then check the client-side application for issues. For example, check the code logic handling cookies and the logic of related libraries.

Check the duration that you configured on the load balancer. If the cookie expired, then client sessions no longer stick to the registered target until the load balancer issues new cookie.

For duration-based stickiness, activate sticky session on only one Application Load Balancer. If your request passes through multiple load balancers and more than one load balancer generates a cookie, then the load balancer replaces the original cookie. As a result, stickiness fails.

For Classic Load Balancers, see How can I troubleshoot the Classic Load Balancer session stickiness feature?

To troubleshoot stickiness issues with AWS Support, create a HAR file to gather required traffic information. Make sure to include load balancer stickiness cookies and your application's stickiness cookie.

Important: HAR files can capture sensitive credentials. Before you share the HAR file, remove authentication tokens, login credentials, API tokens, and session tokens that grant account access.

Related information

Why is Elastic Load Balancing unequally routing my load balancer traffic?

Configure sticky sessions for your Classic Load Balancer

How do I set up weighted target groups for my Application Load Balancer?

AWS OFFICIALUpdated 4 days ago