ALB Sticky Sessions: Duration-Based vs Application-Based Cookies and When to Avoid Them

What sticky sessions do and why you'd want them

By default, ALB distributes each request to a healthy target using the configured load balancing algorithm (round-robin or least outstanding requests). The same client's second request can go to a completely different target than the first.

For stateless backends, this is fine — any target can handle any request. For stateful backends that store session data in local memory (not in a shared database or cache), the client must return to the same target to access their session state.

Sticky sessions instruct ALB to route a client's subsequent requests to the same target they initially connected to, using a cookie to identify the target.

Duration-based stickiness: ALB manages the cookie

The simplest option. ALB creates the AWSALB cookie on the first request and uses it to route subsequent requests to the same target:

resource "aws_lb_target_group" "app" {
  name     = "app"
  port     = 8080
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  stickiness {
    type            = "lb_cookie"       # duration-based (ALB cookie)
    cookie_duration = 86400             # seconds (1 day); 1-604800 range
    enabled         = true
  }
}

The client receives Set-Cookie: AWSALB=<hash>; ... on the first response. ALB reads this cookie on subsequent requests to route back to the same target. The hash encodes the target identity — clients cannot forge it.

Application-based stickiness: app controls the cookie

Your application sets a named cookie when a session begins. ALB reads that cookie to determine which target to route to:

stickiness {
  type            = "app_cookie"
  cookie_name     = "SESSIONID"       # the cookie your app sets
  cookie_duration = 3600              # ALB's stickiness duration (separate from app cookie TTL)
  enabled         = true
}

When ALB sees a request with Cookie: SESSIONID=abc123, it routes to the target that handled the request where SESSIONID was first set. ALB also issues its own AWSALBAPP cookie as a routing reference.

Application-based stickiness is appropriate when your application already manages session cookies and you want stickiness to align with your application's session lifecycle rather than a fixed time duration.

When stickiness creates problems

Uneven load distribution: if some clients have long sessions, targets get stuck with them. A target serving 10 long-running sessions can be at 100% CPU while others are idle. The load balancer appears to be working but isn't actually balancing.

Target replacement complications: during rolling deployments, new tasks replace old ones. Clients stuck to old tasks keep hitting them until the task is drained and deregistered. Reducing deregistration_delay helps, but clients may experience session loss when their sticky target is removed.

False sense of statefulness: stickiness works until it doesn't — if a target fails, the client gets a new target and loses their local session state. Stickiness is not a session persistence guarantee.

import redis
import uuid
import json

redis_client = redis.Redis(host=os.environ['REDIS_HOST'], port=6379)

def create_session(user_data: dict) -> str:
    session_id = str(uuid.uuid4())
    redis_client.setex(
        f"session:{session_id}",
        3600,   # TTL: 1 hour
        json.dumps(user_data)
    )
    return session_id

def get_session(session_id: str) -> dict:
    data = redis_client.get(f"session:{session_id}")
    if data:
        return json.loads(data)
    return None

Stickiness for specific use cases that genuinely need it

Some legitimate uses for sticky sessions:

WebSocket connections: WebSocket connections are persistent — once established, requests on the same connection must stay with the same backend. ALB handles WebSocket connections correctly, and stickiness ensures the connection upgrade and subsequent messages reach the same target.

Long-running computation: if a client initiates a multi-step workflow with intermediate state on the backend (e.g., multi-step file upload with server-side state), stickiness ensures steps reach the same process.

Canary/weighted deployments: weighted forwarding with stickiness ensures a client gets a consistent experience from one target group (v1 or v2), not a mix.

For most standard web application requests, if you need sticky sessions, that's a signal to move state to Redis or a database rather than adding stickiness to the load balancer.