Sticky Sessions (Session Affinity): Concept, Benefits, limitations and Use cases

 

Sticky Sessions (Session Affinity)

Sticky Sessions, also known as Session Affinity, is a load balancing technique that ensures a user's requests are consistently routed to the same backend server during the lifetime of a session.

 Concept

When session affinity is enabled, the load balancer "remembers" the association between a client and a backend server, typically using:

• Cookies (e.g., AWS ALB uses AWSALB cookie)
• Source IP (less common, less reliable with NAT/proxies)

This ensures the same backend server handles all requests from a particular client until the session expires or the server is unavailable.

 Benefits

Benefit	Explanation
Stateful Session Management	Useful when session data (like login state or cart items) is stored in-memory on the server, not in a shared store.
Performance	Reduces overhead from repeatedly syncing or fetching session data from external stores like Redis or databases.
Simplified App Logic	Easier to manage user state without implementing distributed session storage mechanisms.

 Common Use Cases

Use Case	Example
E-commerce	A user's cart stays consistent while shopping if they're always routed to the same backend.
Authentication Portals	Avoids re-authentication or session loss when the user is redirected between steps.
Legacy Applications	Older systems that store sessions in local memory instead of shared caches.
Multistep Forms	Keeps a user's progress in sync during a form wizard or checkout process.

Limitations

• Poor Load Distribution: If one server gets more users, it can become overloaded.
• Reduced Fault Tolerance: If a sticky backend goes down, user session might be lost unless failover handling is built-in.
• Scalability Concerns: Not ideal for autoscaling architectures unless sessions are externalized (e.g., using Redis, Memcached).

Best Practices

• Use sticky sessions sparingly and only when necessary.
• Consider external session storage (like Redis or DynamoDB) for scalability.
• For microservices or stateless apps, avoid sticky sessions altogether.

Types of sticky session in aws

In AWS, sticky sessions (session affinity) are supported in Elastic Load Balancing (ELB) services and can be configured in different ways depending on the type of load balancer used.

Here are the types of sticky sessions in AWS based on the load balancer:

 1. Application Load Balancer (ALB) – Cookie-Based Stickiness

 Type: Application-controlled or Load balancer–generated cookie

• How it works:
  Stickiness is achieved using HTTP cookies. ALB supports:
• Application-based cookie: Your app sets the cookie.
• Load balancer–generated cookie: ALB automatically sets a cookie (named AWSALB).

 Configuration Options:

• Duration: You can set a timeout (1 second to 7 days).
• Stickiness only applies to HTTP/HTTPS listeners.

 Use Case:

• Useful when sessions are stored in server memory, and requests need to be routed to the same backend.

 2. Classic Load Balancer (CLB) – Cookie-Based Stickiness

 Type: Application-controlled or Load balancer–generated cookie

• Similar to ALB, CLB supports:
• LB-generated cookie: Named AWSELB
• App-generated cookie: You specify a cookie name, and CLB honors it

 Configuration Options:

• You can define a stickiness policy with expiration duration.
• Works for HTTP/HTTPS traffic.

Use Case:

• Still used in legacy or older environments.

 3. Network Load Balancer (NLB) – Source IP Affinity (IP Stickiness)

 Type: Source IP-based Stickiness

• How it works:
  NLB uses the client's source IP address to route all requests to the same target.

 Configuration Options:

• You enable client IP preservation using the target group configuration (preserve_client_ip and stickiness.enabled).
• Stickiness duration can be set from 1 to 604800 seconds (7 days).

Use Case:

• Ideal for TCP/UDP traffic where cookies are not applicable.
• Works well for apps needing low-level access (e.g., gaming, VoIP, custom protocols).
  

Summary Table:

Load Balancer	Stickiness Type	Protocols Supported	Identifier	Notes
ALB	Cookie-based (LB/app)	HTTP/HTTPS	AWSALB	Best for web apps
CLB	Cookie-based (LB/app)	HTTP/HTTPS	AWSELB	Legacy use cases
NLB	Source IP-based	TCP/UDP	Source IP	No cookies; best for raw traffic

Types of cookie names in aws with respect to sticky sessions

In AWS, the types of cookie names used for sticky sessions (session affinity) depend on the type of load balancer and whether the cookie is managed by the application or by the load balancer.

Here's a breakdown of the types of cookie names in AWS for sticky sessions:

 1. Application Load Balancer (ALB)

 a. Load Balancer–Generated Cookie

• Cookie Name: AWSALB
• Set By: AWS ALB
• Purpose: ALB sets this automatically to maintain stickiness when using LB-managed cookie stickiness.
• Expiration: You can configure the duration (1 second to 7 days).

 b. Application-Generated Cookie

• Cookie Name: Custom (you define it)
• Set By: Your backend application
• Configured In: Target group attributes (you specify the name to look for)
• Purpose: ALB tracks the custom cookie and routes traffic accordingly.
• Use Case: When your app already manages session cookies (e.g., JSESSIONID, PHPSESSID).

 2. Classic Load Balancer (CLB)

a. Load Balancer–Generated Cookie

• Cookie Name: AWSELB
• Set By: AWS CLB
• Purpose: Used when you configure an LB-generated stickiness policy.
• Expiration: Configurable duration (default is 0, meaning session lasts for the browser session only).

b. Application-Generated Cookie

• Cookie Name: Custom (you define it)
• Set By: Your backend application
• Use Case: You create a stickiness policy that uses your app’s cookie (e.g., SESSIONID, AUTHID).

 3. Network Load Balancer (NLB)

• ❌   No cookies used
• Stickiness Type: Source IP affinity
• Mechanism: Uses source IP to persist traffic to the same backend target.

Summary Table

Load Balancer	Cookie Type	Cookie Name	Set By	Notes
ALB	LB-generated	AWSALB	ALB	Auto-created for stickiness
ALB	App-generated	e.g., JSESSIONID	Application	ALB uses the cookie for routing
CLB	LB-generated	AWSELB	CLB	Auto-created when stickiness enabled
CLB	App-generated	e.g., SESSIONID	Application	CLB uses your cookie for routing
NLB	N/A (no cookie)	N/A	N/A	Uses source IP-based stickiness

Project: Hand-on

How twtech enables sticky sessions

Go to target group and edit attributes:twtech-nlb-tg

Edit target group attributes:twtech-nlb-tg

Target selection configuration

Stickiness: turn it on

Stickiness allows the load balancer to bind a user's session to a specific target within the target group

Save changes:

With Stickiness enabled on the target group, traffic can only be routed to the same target (instance). Therefore, refreshing the load balancer won’t change the IP-address.

Therefore, for twtech to get traffic routed to all the targets,  stickiness should be unenable on the target group.

And:

How twtech visualizes the Get-requests on google chrome: Open Chrome and press F12

How twtech configures the frequency of routing on the target group:

Edit target group attributes:twtech-nlb-tg

From: Deregistration delay (draining interval). As of May 2025,this settings vary from 0 - 3600 seconds

The time to wait for in-flight requests to complete while deregistering a target. During this time, the state of the target is draining.

To: