How does session stickiness work on an AWS Application Load Balancer, what are the two types it offers, and what tends to break when a system depends on it?

## Where it lives and what it does Session affinity on an Application Load Balancer is a property of the **target group**, which surprises people who go looking for it on the listener or the rule. It is switched on with the target group attribute `stickiness.enabled` and shaped by `stickiness.type`, which takes one of two values. **`lb_cookie` - duration-based.** The ALB generates its own cookie named `AWSALB` and sets it on the response. Inside it, encrypted, is a reference to the target that served the request. Any later request presenting that cookie is routed to the same target until the cookie's lifetime expires; the lifetime comes from `stickiness.lb_cookie.duration_seconds` and is a fixed timer measured from issue, not a sliding idle window. Because the ALB owns the cookie, this works without a single line of application code. You may also see a companion `AWSALBCORS` cookie: it carries the same value with `SameSite=None; Secure` so that affinity survives cross-origin requests in browsers that would otherwise drop the plain cookie. **`app_cookie` - application-based.** You tell the target group the name of a cookie your application already issues, such as a session identifier. The ALB then issues an `AWSALBAPP` cookie of its own for the routing state and keys affinity to the presence of your cookie. The point is lifetime alignment: when your application's session expires or is invalidated on logout, the stickiness expires with it, instead of a load-balancer timer that knows nothing about your session model. In both modes the cookie contents are encrypted and meaningless to the target - do not try to parse them, and never treat them as an identity. ## Why anyone turns it on Usually one of three reasons. The application keeps session state in process memory, so a user bouncing between targets loses their cart or their login. Or an expensive per-user cache warms on one target and a different target has to rebuild it. Or a long-lived protocol - a WebSocket, a multi-step upload - genuinely needs the same peer for its duration, though a persistent connection already sticks to a target for its own lifetime without help. ## What actually breaks **A target going away discards the guarantee.** Affinity is best-effort, not durable. When a target is deregistered, fails a health check, or is replaced during a rolling deploy, its pinned clients are rerouted to a different target and whatever lived only in the old process is gone. Any deploy, scale-in, or instance replacement is therefore a partial session outage - which is exactly the event stickiness was adopted to avoid. **Load skews.** New targets from a scale-out receive only new clients, because existing clients keep their pin. Right when you added capacity because the fleet was hot, the hot instances stay hot. In the worst case one target holds a disproportionate share of heavy sessions and you cannot rebalance without breaking sessions on purpose. **Non-browser clients never stick.** A mobile app, a service-to-service caller, or a load-test tool that ignores `Set-Cookie` distributes across the fleet as if stickiness were off. If a feature depends on affinity, it will work in the browser and fail everywhere else - a bug that survives QA and appears in production. **It hides the real defect and calcifies it.** Every month of stickiness makes the in-memory session harder to remove, because more behaviour quietly assumes it. ## The alternative, and when stickiness is still right The durable answer is to make targets stateless: move session state to a shared store - a managed cache or a key-value database - and let any target serve any request. Then a deploy is invisible, scale-out rebalances immediately, and target replacement costs nothing. Stickiness remains legitimate as a bridge while that refactor happens, for a vendor application you cannot change, or as an optimisation where the consequence of losing affinity is a slower request rather than a broken one. Treat it that way explicitly - and if it is enabled, set the duration to the shortest value that works, so the fleet has a natural rebalancing rhythm. ## One detail worth knowing Stickiness on a target group pins a client to a target *within* that group. When a listener rule forwards to several weighted target groups - a canary or blue/green split - there is a separate target-group stickiness setting on the forward action, which keeps a client on the same *group* for a configured period. They are different controls: one chooses the version, the other chooses the instance. Enable both if a user must neither switch versions mid-session nor lose an in-memory session.