AWS
Application Load Balancer Sticky Sessions

Application Load Balancer Sticky Sessions

Sticky sessions definition

Load balancers distribute traffic to ensure even distribution across backend resources, which helps balance the workload and optimize performance. This is a core function of load balancers. The traffic distribution mechanism is determined by the algorithm used by the load balancer. Different algorithms include round-robin, least connections, and IP hash, among others.

However, with Sticky Sessions (or Session Affinity), the load balancer routes a client’s connection consistently to the same backend target.

This post will focus on the ALB’s approach to Sticky Sessions (HTTP sessions), as it differs from the session affinity mechanism used by the NLB (TCP sessions).

Sticky sessions use-cases

The following are common use cases for ALB session affinity

Stateful applications

Stateful applications which maintain user-specific session data, such as shopping carts or user preferences. In such applications, the user typically expects to find the same session data every time they log in to the application.

Session-Based authentication

This approach reduces the overhead of re-authenticating when the user closes and opens the application multiple times.

Sticky sessions over-use

Overusing sticky sessions can lead to uneven load distribution across backend servers, which might cause some servers to become overburdened while others remain underutilized. Therefore the balance of time/duration of the connections stickiness is important when implementing sessions affinity.

How it’s implemented

In ALB, session affinity is implemented using cookies, there are two ways for this:

Application based cookies

The applications must generate and handle cookies for managing sessions, including setting the cookie, defining its properties (like expiration and security attributes), and managing it throughout the user’s session. This is common in web development where cookies are set and managed by the server-side application.

How it works

  1. When your application generates a session cookie for a user, it includes details such as session ID and expiration time.
  2. The ALB detects this cookie and generates its own session cookie, named AWSALB, to track the session.
  3. ALB’s sticky session duration matches that of the application’s session cookie.

Duration based cookies

This type of stickiness is implemented by the ALB itself, where it generates duration-based cookies that expire after a predefined period configured in the ALB settings.

Hands on

This is a simple demo on how to implement session affinity in ALB.

Edit the target group

In AWS console, go to EC2 > Target groups > target_group_name > Edit target group attributes, and select the desired stickiness type and duration. If you select “Application-based cookie” you need to specify the App cookie name that’s generated by the backend app.

⚠️
ALB reserves specific cookie names for managing session stickiness. Avoid using these names for your application’s cookies to prevent conflicts or unintended issues. See AWS documentation.

Edit Target Group

Click save and verify

After updating the Targets, you can inspect the cookies deposited by the ALB using the browser’s developer tools. Simply navigate to the ALB address in your browser and check the Storage (in Firefox) or Network (in Chrome) tab

Edit Target Group

The cookie section displays all the details such as name, validity duration, ID, and more. You can also verify that the session is consistently directed by the ALB to the same backend for the duration of the cookie.