Sticky Sessions with ALB: My Sweet Mistake While Load Balancing Cookies

“Let’s make it scale!” I told myself before diving into AWS. But when I added sticky sessions to my ALB setup… things got sticky in a whole different way.

💡 Why I Chose ALB

As a beginner exploring AWS, I was building a simple web app and wanted to distribute traffic across multiple EC2 instances. AWS offers multiple load balancers: Classic (ELB), Network (NLB), and Application (ALB). Since I needed to route HTTP requests based on paths (like /api and /home), ALB was the perfect choice.

🍪 Enter Sticky Sessions (aka Session Affinity)

Sticky sessions ensure that once a user connects to one backend instance, all future requests from them go to the same instance. It’s super helpful if the server stores session data locally (e.g., in memory).

In ALB, I enabled “Target Group Stickiness” using Application-based cookies.

❌ The Mistake I Made

I thought enabling sticky sessions would make user experience smoother, but I forgot one crucial thing: my backend wasn’t designed to depend on session affinity.

• I was running a simple app on two EC2 instances.

• Each one kept user sessions in local memory.

• Once traffic increased, sessions started breaking when the cookie expired or the instance failed.

• I didn’t have any fallback — no shared cache like Redis, and no database session persistence.

So even with sticky sessions, if the instance went down, the user was logged out and confused.

✅ What I Learned

• Sticky sessions are a band-aid, not a long-term solution for session handling.

• Always consider external session storage if your app needs session persistence.

• ALB sticky sessions use either:

  • Duration-based stickiness (ELB-issued cookie)

  • Application-based cookies (your app sets a cookie)

🛠 Tip for Beginners

Use sticky sessions carefully. If you’re just testing or building MVPs, they’re fine. But for production, go stateless or use shared session stores.