CODEWITHSUNDEEP
amazon-web-servicesamazon-elb
vrtx54234
vrtx54234

Reputation: 2316

Application ELB - sticky sessions based on consistent hashing

I couldn't find anything in the documentation but still writing to make sure I did not miss it. I want all connections from different clients with the same value for a certain request parameter to end up on the same upstream host. With ELB sticky session, you can have the same client connect to the same host but no guarantees across different clients.

This is possible with Envoy proxy, see: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancers#ring-hash

We already use ELB so if the above is possible with ELB then we can avoid introducing another layer in between with envoy.

UPDATE: Use-case - in a multi-tenant cloud solution, we want all clients from a given customer account to connect to the same upstream host.

Upvotes: 7

Views: 2481

Answers (1)

Chris Williams
Chris Williams

Reputation: 35213

Unfortunately this is not possible to be performed in an ALB.

An application load balancer controls all the logic over which host receives the traffic with features such as ELB sticky sessions and pattern based routing.

If there is no work around then you could look at a Classic Loadbalancer which has support for the application setting the sticky session cookie name and value.

From best practice ideally your application should be stateless, is it possible to look at rearchitecting your app instead of trying work around. Some suggestions I would have are:

  • Using DynamoDB to store any session based data, moving from a disk based session (if that's what your application does).
  • Any disk based files that need to persist could be shared between all hosts either using EFS for your Linux based hosts, or FSX on Windows.
  • Medium/Long term persisting files could be migrated to S3, any assets that rarely change could be stored here and then your application could use S3 rather than disk.

It's important to remember that as I stated above, you should keep your application as stateless as you can. Assume that your EC2 instances could fail, by preparing for this it will make it easier to recover.

Upvotes: 3

Related Questions