How To Configure Sticky Sessions In Application Load Balancer

How To Configure Sticky Sessions In Application Load Balancer

How To Configure Sticky Sessions In Application Load Balancer

Hello Everyone

Welcome to CloudAffaire and this is Debjeet.

In the last blog post, we have discussed the Application Load Balancer Target Groups health check.

In this blog post, we will discuss sticky sessions in Application Load Balancer.

How To Configure Sticky Sessions In Application Load Balancer:

What is Sticky Sessions?

Sticky sessions are a mechanism to route requests to the same target in a target group. This is useful for servers that maintain state information in order to provide a continuous experience to clients. To use sticky sessions, the clients must support cookies.

When a load balancer first receives a request from a client, it routes the request to a target, generates a cookie named AWSALB that encodes information about the selected target, encrypts the cookie, and includes the cookie in the response to the client. The client should include the cookie that it receives in subsequent requests to the load balancer. When the load balancer receives a request from a client that contains the cookie, if sticky sessions are enabled for the target group and the request goes to the same target group, the load balancer detects the cookie and routes the request to the same target. If the cookie is present but cannot be decoded, or if it refers to a target that was deregistered or is unhealthy, the load balancer selects a new target and updates the cookie with information about the new target.

Application Load Balancers support load balancer-generated cookies only. The contents of these cookies are encrypted using a rotating key. You cannot decrypt or modify load balancer-generated cookies. WebSockets connections are inherently sticky. If the client requests a connection upgrade to WebSockets, the target that returns an HTTP 101 status code to accept the connection upgrade is the target used in the WebSockets connection. After the WebSockets upgrade is complete, cookie-based stickiness is not used. You enable sticky sessions at the target group level. You can also set the duration for the stickiness of the load balancer-generated cookie, in seconds. The duration is set with each request. Therefore, if the client sends a request before each duration period expires, the sticky session continues.

Sticky Sessions Demo:

Step 1: Create a custom VPC for your ALB.

Step 2: Create two EC2 instances for your Application Load Balancer.

Step 3: Create your Application Load Balancer.

Step 4: Configure Sticky Sessions for your Application Load Balancer.

Step 5: Cleanup.

Hope you have enjoyed this article, In the next blog post, we will discuss Application Load Balancer monitoring using Access Logs.

All the public cloud providers are changing the console user interface rapidly and due to this some of the screenshots used in our previous AWS blogs are no longer relevant. Hence, we have decided that from now onwards most of the demo will be done programmatically. Let us know your feedback on this in the comment section.

To get more details on AWS ELB, please refer below AWS documentation


This Post Has One Comment

  1. I really liked your article !, question, what happens with sticky sessions if you have multiple EC2 instances across different AZs and Cross-Zone is not enabled in your Classic Load Balancer ? it sounds like if a request was sticked to a particular instance to keep session data in subsequent request, will not work if the next request goes to a different LB node in other AZ .. ?

Leave a Reply

Close Menu