Amazon Web Services best practices tell us to build for stateless systems, in a perfect world any server can serve any function with absolutely no impact to customers. Sounds great, but unfortunately reality interjects into our perfect world and we find many websites and applications are not so perfectly stateless. So how can we make use of the strengths of AWS in areas like elasticity and auto scaling without completely re-writing applications to conform? After all, one of the key benefits to moving into the Cloud is cost savings which get eaten away by spending development resources rewriting code.
The solution is thankfully built-in to Amazon’s Elastic Load Balancer (ELB), so those that require sessions to remain open for a customer can enable that “sticky” option. This keeps transactions processing, real time communication alive, and businesses from needing to redesign such code or give up auto scaling. So how does it work?
The first option is to create duration-based session stickiness. This is enabled at the ELB under port configuration. From there, the “stickiness” option can be enabled, and the ELB will generate a session cookie with a limited duration (default is 60 seconds). So long as the client checks in with the ELB before the cookie expires, the session is held on that instance and that instance will not be terminated by auto scaling. The second option is to enable application-controlled stickiness. This requires more development effort unless the existing platform already makes use of custom cookies; however this gives far more control to application developers than a basic number of seconds before timeout. By using application control a web developer can keep a client connection directed to a specific instance through the ELB with no fear that a required instance will be terminated prematurely.
-Keith Homewood, Cloud Architect