3

Our ALB is registered with multiple target groups. Each target group is a separate web application serving a different portion of the website under the same domain.

Here's snippet from AWS docs about sticky session cookie encoding practice

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.

Here's a summary of what we are facing

  • When a client makes parallel requests, the session stickiness will not work because none of the requests have the AWSALB cookie yet.

  • When a client makes a single blocking request followed by multiple parallel requests, the stickiness will work only with the target group that served the initial blocking request. If the rest of the parallel requests are intended for other target groups, there's no stickiness here because their target-group's info is not encoded in the AWSALB cookie yet.

One solution here is to make a series of sequential requests to different urls in order to hit different target groups so that we establish stickiness with each target group. However, this is not practical because making the sequential blocking requests will slowdown the client.

I was wondering if there's a way to tell ALB to encode session-stickiness information about all target groups in a single request? In this case, the stickiness is established for all target groups so that the follow up requests are sticky among respective target groups.

phanin
  • 5,327
  • 5
  • 32
  • 50
  • You [can't modify](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions) ALB generated cookies: "You cannot decrypt or modify load balancer-generated cookies. " if this is what you want to do. – Marcin May 14 '20 at 00:41
  • Yep, we cannot understand AWSALB cookies. Not sure which part of the question was referring to an ability to do so. The question is about sending a request to ALB for it to send back a complete AWSALB cookie with stickiness info on all target groups. – phanin May 14 '20 at 00:43
  • I don't know the answer... Where is your session data being stored? In case of my application, the session data is stored in a cookie, so even if the request hits a different server, the session data is always available... – Hooman Bahreini May 19 '20 at 01:14
  • In our case it's on server side. If you don't me asking, how big does your session data cookie get? – phanin May 20 '20 at 21:53

1 Answers1

0

Try using subdomains for the different parts of the application. Let's say every target group has its own subdomain, but all subdomains are actually pointed to the same load balancer. All subdomains can actually be a CNAME of your real domain, but for the load balancer it is different and the cookie will be set for that domain and used independently.

Something like

  • api1.yourdomain.com -> CNAME of api.yourdomain.com -> ALB -> target group 1 -> cookie for target group 1 set for api1.yourdomain.com
  • api2.yourdomain.com -> CNAME of api.yourdomain.com -> ALB -> target group 2 -> cookie for target group 2 set for api2.yourdomain.com etc.

Regardless, I wouldn't rely much on this cookie and the session stickiness since it is not always reliable, and you should always assume that there is not much control in the way an ALB balances the traffic, and even if this is a nice approach to facilitate servers to be somehow stateful and assure smooth user experience, it is always better to put the efforts on achieving a full stateless application to the extent needed not to worry about session stickiness at all

Carlos Robles
  • 10,828
  • 3
  • 41
  • 60