Understanding Sticky Sessions in AWS Elastic Load Balancer: How to Keep Users with the Same Server

After building and scaling his web app behind an Application Load Balancer (ALB), Arjun started getting unusual complaints:

“Sometimes I log in, and then on the next click, I’m logged out!”

He realized the problem wasn’t his app—it was how requests were being spread across backend servers.

That’s when Arjun discovered the concept of Sticky Sessions, also known as Session Affinity.

---

🧠 What Are Sticky Sessions?

By default, load balancers (like ALB or NLB) distribute traffic evenly across backend instances. That means:

• Request 1 from a user may go to EC2 Instance A

• Request 2 from the same user may go to EC2 Instance B

This works fine for stateless apps, but not for apps that store session data (like login info) on a specific server.

✅ Sticky Sessions fix this:

They "stick" a user to the same backend server for a period of time, using a special cookie.

So if Arjun’s app runs on 2 EC2 instances:

• Client 1 → Always routed to Instance A

• Client 2 → Always routed to Instance B

---

🍪 How Sticky Sessions Work

Let’s say a user (like Arjun) visits your website for the first time. Here’s what happens behind the scenes with sticky sessions enabled:

🔁 Step-by-Step Flow:

1. First Request:

   • The user’s browser sends a request to your Application Load Balancer (ALB).

   • The ALB picks one of your EC2 instances (say, Server A) to handle the request.

2. Sticky Cookie Is Set:

   • ALB generates a special cookie (e.g., AWSALB=SomeEncryptedValue) and includes it in the response headers sent back to the user’s browser.

3. Second Request (and all future ones):

   • The browser now automatically includes that cookie in each request.

   • When the ALB sees this cookie, it knows:

     “Ah! This user is already tied to Server A.”

   • So it routes all those requests to Server A again, until the cookie expires.

🔐 Key Point:

This cookie is what makes the “stickiness” work. It’s how the load balancer remembers which backend the user was assigned to—without your app doing anything extra.

Think of it like a fast pass with a booth number printed on it. When the user returns, the system sees the pass and sends them back to the same booth.

---

🍪 Types of Sticky Session Cookies

When you enable sticky sessions in an Elastic Load Balancer (ELB), AWS uses cookies to tie users to specific backend servers. There are two main types of cookies:

---

1️⃣ Duration-Based Cookie (Generated by Load Balancer)

• Automatically created by:

  • Application Load Balancer (ALB)

  • Classic Load Balancer (CLB)

• Cookie includes an expiration time (after which stickiness ends)

• Cookie names:

  • AWSALB → Used by ALB

  • AWSELB → Used by CLB

✅ The load balancer manages everything—you don’t need to write any custom logic.

---

2️⃣ Application-Based Cookie (Generated by Your Application)

• Created by your backend application (like a login server or custom web app)

• The Application Load Balancer (ALB) reads and uses this cookie to maintain session affinity

• You specify the cookie name in your target group settings

• ❌ You must not use reserved names like:

  • AWSALB, AWSALBAPP, or AWSALBTG (reserved for AWS use)

✅ This gives you more customization and control over how long a session lasts and what data the cookie carries.

---

📘 SAA Tip: Always remember:

• AWSALB → Duration-based cookie for Application Load Balancer

• AWSELB → Duration-based cookie for Classic Load Balancer

• AWSALBAPP → Application-based cookie for ALB

---

✅ Sticky Sessions Supported In:

---

⚖️ Pros and Cons of Sticky Sessions

Arjun made this handy chart to weigh the benefits:

“If one user opens 30 tabs and they’re sticky… that server’s gonna sweat!”

---

🔧 When Should You Use Sticky Sessions?

Use it if:

• Your app stores session data in memory on the server

• You haven’t yet implemented centralized session storage

• You need quick compatibility with legacy systems

Avoid it if:

• You’re running a stateless, microservices-based architecture

• You use Redis / DynamoDB / RDS for shared session state

---

🚀 Arjun’s Final Setup

Arjun enabled sticky sessions on his ALB target group using duration-based cookies with a 10-minute timeout.

This fixed the “random logout” issue and gave users a consistent experience—without redesigning his app logic.

---

More AWS SAA Articles

• AWS Network Load Balancer

• Complete Overview of AWS Application Load Balancer

• How ELB Manages Traffic with Precision

• AWS Route 53 Explained

• Amazon EFS Made Easy: The File System That Scales With You

• EBS Multi-Attach: The Power of Shared Storage in AWS

• EBS Volume Types

• What is Elastic Network Interface?

• What is AWS EC2 Placement Groups?

• Why You Must Handle IAM API Keys with Extreme Care in AWS?

• AWS Security Groups

• EC2 Instance Types

• AWS IAM Best Practice

• AWS IAM Security Tools

• IAM Roles for Services

• AWS IAM User, Root User and Groups

• AWS IAM Policies and their structure

Follow me for more such content

• My YouTube Channel

• My Site

• My Blogs

• LinkedIn

• Instagram

• Twitter

• Stackoverflow

• Github

• Dev