AWS web socket and retrieving session data w/ Tomcat

I am trying to get my Tomcat 7 application working on AWS. Unfortunately AWS load balancer does not allow web socket traffic to pass through the load balancer unless the protocol mode is set to TCP. However, if the load balancer uses TCP instead of HTTP, it cannot retrieve header information from the user and this breaks functionality like sticky sessions. As I am storing various information about the user in the session, and do not want to use session replication, I think having sticky sessions is vital for my application.

As a work around, I was able to update my application to determine which instance the user is on and have the web socket connection connect directly to that instance. Unfortunately because the instance is on Amazon's domain, when the web socket connection is established, it cannot retrieve any of the previous session information for the user because the cookie exists on my domain, not Amazon's.

I have come up with a few ideas to handle this situation, but I'm not sure what's best or if there is a more obvious solution I haven't thought of. One thing to note: while the information in the HTTP session is confidential, the information being passed via the web socket is NOT confidential, so there is no security risk if someone were to hijack this session or snoop on the communication.

1) Create a subdomain for each instance - I believe this will solve the problem as I should be able to retrieve the session information for a sub-domain of my domain. Drawback is we would have to scale up to the maximum number of instances we plan to use and add DNS records for them ahead of time. If the DNS were to ever change for any of these, the application would stop working.

2) Persistent sessions - I don't know much about this, but I know it is possible to persist a session into the database instead of keeping it in memory. A drawback would be more database reads required, and maybe some other issues that I am not aware of. Would this be a viable option?

3) Pass the jesssion id as part of the websocket connection string - this seems like a very bad idea as it would make us very prone to session hijacking.

4) An improvement over the previous idea would be that when the session is established, create a one-time use security token and associate it with the session ID in the database. Pass the security token as part of the web socket connection string and I should be able to associate the user with their HTTP session. A downside to this is I believe I'd need to keep an in-memory map of all the sessions in order to access that specific user's session, plus a bit more database utilization.

These are the best ideas I have been able to come up with so far. Out of these options, which is the best, or is there a better solution available that I'm missing?

Any feedback is greatly appreciated!

Thank you