4.45 Adhesion to load balencer

This lesson explains stickiness — also called session affinity — on AWS load balancers. The principle: once a client lands on an instance behind the load balancer, subsequent requests from the same client are routed to the same instance for the duration of the sticky session. This is implemented on Classic Load Balancers (CLB) and Application Load Balancers (ALB) by storing an extra cookie with an expiration delay. The most common use case is preserving an HTTP session between two requests so the user does not lose their cart or auth state.

Trade-off and lab

  • Stickiness breaks even distribution: traffic from a heavy user remains stuck on one instance.
  • It is a session-level pattern, not a replacement for shared session storage (Redis, ElastiCache, RDS).
  • For CLBs, stickiness is configured on the load balancer itself; for ALBs, it is configured on the target group.

In the AWS console we open our load balancer and the related target group. Without stickiness enabled, refreshing the public DNS rotates between the registered instances — visible by the changing private IP printed by each web server. We then edit the target group's Attributes, enable stickiness, and set a duration (for example 2 minutes). After applying the change and refreshing the page, every subsequent request from the same browser session lands on the same backend instance.

Stickiness is therefore a per-target-group setting on ALBs, and a per-load-balancer setting on CLBs. Use it when your application stores session state locally; combine it with a session expiration policy that matches your business needs. Whenever possible, prefer externalizing session state to ElastiCache or another shared store so you can keep traffic spread evenly across instances and tolerate per-instance failures without losing user sessions.

Summary

Load balancer adhesion (also called stickiness or session persistence) ensures that client requests are always routed to the same backend instance during an active session. While this solves the problem of preserving user state across multiple requests, it introduces load imbalance because all traffic from one client concentrates on a single instance. Adhesion is configured at the target group level in AWS with an adjustable duration (typically a few minutes).

Key points

  • Adhesion routes requests from the same client to the same backend instance throughout the session
  • Primary use case is maintaining user session state across multiple requests without losing data
  • Tradeoff: improves session preservation but can cause uneven load distribution if one client makes many requests
  • In AWS, adhesion is configured at the target group level with a configurable duration (e.g., 2 minutes)
  • When enabled, subsequent requests from the same client are guaranteed to reach the same instance until the adhesion duration expires
  • Without adhesion, each request could be routed to a different instance, potentially losing session context

FAQ

What is load balancer adhesion and why use it?

Adhesion (or stickiness) ensures all requests from a single client are routed to the same backend instance during a session. This prevents users from losing their session state between requests, which is critical for applications that maintain user login, shopping carts, or other session-dependent data.

What is the downside of enabling adhesion?

Adhesion can cause uneven load distribution. If one user makes many requests, all that traffic concentrates on a single instance while other instances remain underutilized. This reduces the effectiveness of load balancing and can create bottlenecks.

How long does adhesion last?

Adhesion duration is configurable at the target group level in AWS. In the example shown, it is set to 2 minutes, meaning once a client connects to an instance, all subsequent requests within that 2-minute window will route to the same instance.