Amazon ELB HTTPS Stickiness

Stickiness is needed in most of the complex applications when scaled up in cloud. Say one user logs in. Now his information should be attached to him. If not, each time, he would be routed to a random instance, which will not identify him. Attaching a session id would provide the stickiness, where a particular user can be forwarded to the particular instance. 

I tried using amazon elb-api commands using terminal to enable stickiness for the elastic load balancer. it gave error when trying to apply the stickiness for the port 443, and works fine for 80.

Create Stickiness Policy
pradeeban@pradeeban:~/pem$ elb-create-app-cookie-stickiness-policy wso2cloud1-as -p my-app-cookie-lb-policy -c jsessionid -K KEY.pem -C CERT.pem
OK-Creating App Stickiness Policy

Setting the Policy to the Listener - Fails for port 443
pradeeban@pradeeban:~/pem$ elb-set-lb-policies-of-listener wso2cloud1-as --lb-port 443 --policy-names my-app-cookie-lb-policy -K KEY.pem -C CERT.pem
elb-set-lb-policies-of-listener: Service error: aws:Client.InvalidConfigurationRequest AWSRequestId:4b2c7fc3-4fbf-11e0-a778-d17858cabec6

Setting the Policy to the Listener - Works for port 80
pradeeban@pradeeban:~/pem$ elb-set-lb-policies-of-listener wso2cloud1-as --lb-port 80 --policy-names my-app-cookie-lb-policy -K KEY.pem -C CERT.pem
OK-Setting Policies

So it seemed, it was an issue with https/stickiness from the amazon's end. It was not giving any error when tried with amazon management console nevertheless, but simply not allowing to enable stickiness for the listener with the tcp protocol.

It works for --lb-port 80 --lb-port 443, but not for --lb-port 443 --lb-port 80 (since it picks the first entry only, it seems).

Tried the same with elb-create-lb-cookie-stickiness-policy (elb controlled stickiness) and the results was same.

So I felt, https/stickiness is not working for both application based or amazon elb based cookies, while it works for http.


But Amazon announced in Oct, 2010 that they have started supporting HTTPS stickiness.


I reported this in AWS forum, but later found that it (Setting stickiness policy) works. What we had to change was the protocol to https from tcp for the port 443.

--listener "lb-port=443,instance-port=9443,protocol=https"

HTTPS/Stickiness is fine with Amazon's, but not TCP/Stickiness. The TCP/Stickiness issue has already been discussed in another thread [1] in AWS forums. Hence we resolved the issue, by changing the protocol from TCP to HTTPS for the port 443. However we also noted that aiCache provides web application HTTPS acceleration and stickiness for TCP too.

[1] Service error when setting LB policies of listener
[2] Elastic Load Balancing with Sticky Sessions
[3] Amazon Makes the Cloud Sticky
[4] jmeter + amazon ec2 + load balancing (elb)
[5] How can I force "non-sticky" connections for my ELB? 
[6] Load Balancer (ELB) - port forwarding on the load balancer itself
[7] "Sticky connection" on ELB for https?  
[8] Using ELB to Serve Multiple Domains Over SSL on EC2 for Giggles and Unicorns
[9] Amazon Simple Monthly Calculator