Sticky Session¶
Sticky sessions ensure that requests from a client always get routed to the same backend server before a session elapses.
Here is an example that describes how sticky session works. Assume that you have logged in to a server. After a while, you send another request. If sticky sessions are not enabled, the request may be routed to another server, and you will be asked to log in again. If sticky sessions are enabled, all your requests are processed by the same server, and you do not need to repeatedly log in.
Differences Between Sticky Sessions at Layer 4 and Layer 7¶
The following table describes the differences of sticky sessions at Layer 4 at Layer 7.
OSI Layer | Listener Protocol | Sticky Session Type | Stickiness Duration | Scenarios Where Sticky Sessions Become Invalid |
---|---|---|---|---|
Layer 4 | TCP or UDP | Source IP address: The source IP address of each request is calculated using the consistent hashing algorithm to obtain a unique hashing key, and all backend servers are numbered. The system allocates the client to a particular server based on the generated key. This allows requests from the same IP address are forwarded to the same backend server. |
|
|
Layer 7 | HTTP or HTTPS |
|
|
|
Constraints and Limitations¶
You have selected Weighted round robin or Weighted least connections for Load Balancing Algorithm.
If you use Direct Connect or VPN to access ELB, you must select Source IP hash as the load balancing algorithm and disable sticky sessions for ELB.
Dedicated load balancers support two types of sticky session: Source IP address and Load balancer cookie.
Shared load balancers support three types of sticky session: Source IP address, Load balancer cookie, and Application cookie.
Note
For HTTP and HTTPS listeners, enabling or disabling sticky sessions may cause few seconds of service interruption.
If you enable sticky sessions, traffic to backend servers may be unbalanced. If this happens, disable sticky sessions and check the requests received by each backend server.