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.