简体   繁体   中英

How can I configure an AWS Network Load Balancer to achieve end-to-end HTTPS encryption while maintaining session affinity?

I have a VPC with two EC2 instances in different availability zones. Clients connect to my application via HTTPS. I've been attempting to set up load balancing between the two application nodes, which require session affinity.

Initially I used an Application Load Balancer with sticky sessions. This worked, but I recently found out that the project I'm working on requires unbroken end-to-end encryption from client to application node. Because the ALB has to decrypt the connection to perform cookie based routing, it's unable to fulfil this requirement. Even if I reencrypted the connection between ALB and EC2, it's still not end-to-end.

After some investigation, I've determined that the Network Load Balancer may be able to provide end-to-end encryption, but I'm unsure as to how I'd obtain session affinity. I've read that it can be done by hashing the client connection details and continuing to route all future connections to the same node until a timeout value is reached, but this question seems to state that it's flat out not possible, but doesn't really go in to detail.

How would I go about obtaining session affinity in a Network Load Balancer? If this can't be achieved, how would I go about establishing end-to-end encryption with an AWS load balancer?

Edit: NLB now supports sticky sessions .

Old answer: You can't. NLB does not support sticky sessions , and while you could also use a classic load balancer in TCP mode to terminate TLS at your application, classic load balancers require HTTP/HTTPS mode for stickiness . If strict E2E is an actual requirement, you'll need to design your application to work without session affinity.

It could be a typo, but the bottom of Target Groups for Your Network Load Balancers states:

Sticky sessions are supported only in the following Regions: Europe (Paris), Europe (Ireland), Europe (Stockholm), and US West (Oregon).

This strikes me as a very strange list. Some other possible explanations (besides a typo) is (1) brand new and coming soon and (2) required by an EU regulation (but originally developed in US West).

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM