The Sticky Mess of Load Balancer Stickiness

If you’ve ever played around with AWS Load Balancers and stumbled upon the term stickiness, you’ve probably had the same reaction as most people: What the hell is this, and why should I care? Well, stick around (pun absolutely intended), and let’s break it down while I try my best that you do not fall asleep in next 5 minutes.

---

What Even Is Stickiness?

Imagine you’re binge-watching an anime series, but every time you start a new episode, Netflix forgets what you were watching and randomly throws you into a different show. That’s what happens when a load balancer distributes your requests across different backend servers without remembering where it sent you last time. Stickiness ensures that once a user (you) connects to a particular backend server, they keep going back to that same server for a while, so they don’t get dumped into chaos.

But not all stickiness is the same! AWS gives you two options, and if you pick the wrong one, you might end up with users getting mysteriously logged out or your backend servers having a meltdown.

---

Load Balancer-Generated Cookie Stickiness (AWS Controls It, You Just Watch)

The laziest, most hands-off way to handle this is to let AWS do it for you. When you enable this, AWS magically creates a cookie (let’s call it AWSALBAPP because AWS loves unreadable names). Every time you send a request, AWS checks if you have this cookie. If you do, it sends you back to the same server. Simple, right?

Here’s the catch: AWS decides that this cookie lasts seven days—no ifs, no buts, no configuration options. If your app’s session dies in three days, tough luck, because AWS will keep sending requests to that server even after it forgets about the user.

When should you use this?

• If your application doesn’t store sessions and is completely stateless.

• If you just want basic load balancer persistence without modifying your application.

• If you don’t care about session expiration mismatches because your app doesn’t track users anyway.

When does this go horribly wrong?

Let’s say you’re playing an online game, and the server gives you a session for 30 minutes. But AWS decides you’re sticking to that same server for seven days. Guess what happens when your session expires? You get kicked out, but AWS stubbornly keeps sending you back to that same dead-end server. Frustration levels: maximum.

• If your app has session-based authentication and the session expires before seven days, ALB will still send requests to the same backend, but the server won’t recognize the user.

• If your app stores sessions in memory, a backend restart will make ALB’s stickiness useless because the session data is lost.

• If you want to control session length, too bad! AWS controls the seven-day expiration.

So yeah, if your app actually manages user sessions, this option can create more problems than it solves.

---

Application-Based Cookie Stickiness (You Control It, AWS Follows Along)

This one gives your application some say in the matter. If your app already uses its own session cookie (like session_id), the ALB notices it and decides, Alright, I’ll play along. It then creates its own cookie (AWSALBAPP), but here’s the cool part: it only maintains stickiness as long as your application keeps sending that session cookie.

When should you use this?

• If your application already generates session cookies and stores session data in memory, cache, or database.

• If you need control over session expiration instead of being stuck with ALB’s arbitrary seven-day rule.

• If you don’t want ALB to keep sending users to a backend that has already forgotten them.

How does it work in reality?

Picture a fast-food joint where you get a receipt (session cookie). As long as you have that receipt, you can pick up your order. ALB is like an overenthusiastic manager who sees your receipt and says, Oh, they ordered from counter #3! Keep sending them there! But the moment you lose your receipt (session expires), ALB stops directing you to that counter.

1. Your application sets a session cookie, let’s say session_id, with an expiration time.

2. ALB reads this cookie and says, Got it! I’ll make a copy.

3. ALB creates its own AWSALBAPP cookie and ties the user to the same backend.

4. If the app stops sending the session_id, ALB stops stickiness too.

This method avoids the session expiration mismatch problem because ALB stops stickiness when the app session is over.

---

The Expiration Conflict – When Things Get Messy

Alright, now imagine your application generates a session cookie that expires in three days. Meanwhile, ALB’s Load Balancer-generated cookie stickiness lasts seven days. What happens when the application cookie expires but ALB’s stickiness is still active?

Well, ALB keeps directing requests to the same backend, but the backend has no idea who the user is anymore. This can lead to:

• Users getting mysteriously logged out but still hitting the same backend.

• The backend server frantically looking for a session that doesn’t exist in memory, cache, or database.

• Unexpected errors if the backend was expecting a valid session but finds nothing.

This is like being at a hotel reception where you had a three-day booking, but the receptionist (ALB) insists you still have a room because their system says your reservation lasts seven days. Meanwhile, housekeeping (Application) already cleared out your stuff. Now you're standing there with no room(no session) and a very confused receptionist who still insists that you have a room but they just can’t find where it is.

That’s why Application-Based Cookie Stickiness is the smarter choice if your app actually handles sessions.

---

So Which Stickiness Option Should You Choose?

Use Load Balancer-Generated Cookie Stickiness if:

• Your app doesn’t track user sessions.

• Your backend doesn’t store session data anywhere.

• You just need users to stick to a server for convenience, but session tracking isn’t an issue.

Use Application-Based Cookie Stickiness if:

• Your app already has session management and stores sessions in memory, cache, or database.

• You want control over session expiration and don’t want AWS enforcing a seven-day stickiness.

• You need to ensure ALB stops stickiness when your app session expires.

If you hate dealing with stickiness entirely, go stateless!

• Use JWTs, API tokens, or other authentication methods that don’t require session storage.

• Stateless apps don’t care about stickiness because every request is self-contained.

---

Stickiness can be great when used correctly, but if you blindly enable it without understanding the consequences, you’ll end up debugging random user logouts and server overloads at 3 AM. Choose wisely, and may your sessions always be remembered!