Session Affinity and Sticky Sessions – Load Balancing – ANS-C01 Study Guide

Session Affinity and Sticky Sessions

The application load balancer distributes connections to the backend servers based on the chosen load balancing algorithm such as round-robin or least connections. This may not work in applications that require the source to be bound to a specific server for the duration of the session. An example of this would be in an e-commerce deployment where the shopping cart is on a particular server and the client must remain connected to that server until the checkout process has been completed. If the load balancer were to move the connection to other servers during the session, then the shopping cart could be on a different server with the client no longer having access to it. The method to get around this is to implement sticky session, or often called session affinity, to make sure that the client always connects to the same server during the session. This guarantees that all connections are sent to the same target to maintain a steady-state user experience.

Sticky sessions require that you use the application load balancer and have a healthy instance in each availability zone in your deployment. Since sticky sessions require the use of cookies, the client browser must support cookie use.

The ALB supports two modes of stickiness, duration and application based. You enable the sticky feature at the target group level and can combine different methods such as duration, application, and none across different target groups. The duration value gets reset with every new request. When the cookie duration expires, the session is no longer sticky and is handled as a normal connection by the load balancer.

Sticky session cookies map the client source to the server destination and can be from an application that has its own cookies for application-based stickiness or cookies that are generated by the load balancer. In this case, the load balancer tracks the duration in the application cookie. If the load balancer generates the cookie and not the application, it will specify the session duration of the cookie generated by the load balancer. AWS encrypts the load balancer cookies it generates, and you are not able to decrypt or modify them. The name of the AWS-generated cookie is always AWSALB.

When the WebSockets protocol is used, there is no need to enable sticky sessions as this function is inherent to WebSockets and always enabled.

The initial connection from the client to the target server is handled normally by the ALB based on its configuration. After the session is created, the ALB will generate a cookie named AWSALB that includes information such as the target server’s identity. The cookie is encrypted and sent to the client by the ALB. The cookie expiration value is 7 days and cannot be modified in the AWS configuration. All requests after this initial exchange require that the client include the AWSALB cookie so the ALB can forward the session to the specified backend server. If the server should fail, or deregister, the ALB will select a new server and update the cookie it returns to the client.

With application-generated cookies, the ALB will generate a new cookie locally that includes the stickiness values for each target group configured to use application-based stickiness. The session will use both the application and ALB cookies and expects the client to return both during the session. The ALB will reference its own cookie, and the application will process its cookie.

The ALB supports cookies sized up to 16KB. However, many browsers can support only 4KB cookies. If this is the case for a session, the ALB will spread the 16KB cookie into multiple 4KB shards named AWSALBAPP-0, AWSALBAPP-1, etc.

When cross-origin resource sharing (CORS) is being used, the ALB will generate a second cookie to note the second URL. This cookie will be named AWSALBCORS and adds the SameSite=None; attribute. The client will now have two cookies from the ALB.

The sticky feature is enabled in the ALB configuration console on the Attributes tab in the Targets section, as shown in Figure 4.8.

FIGURE 4.8 Sticky feature configuration