Taking the final AWS CSA 2018 practice exam here, at Linux Academy, I found an interesting exam question that initially, looks like an easy to answer, but, I decided to go for a research and readings time, to know more about that. The question is the one I add below:
"You have recently worked with a development team to implement a resilient web application running on four EC2 instances behind a load balancer. Performance is great, and limited failover testing occurred with good feedback. A number of days ago a real-life failover happened where the host where an EC2 instance was running failed. Customers connected via the load balancer to alternative instances, but they had to login in the system/application again. What suggestions can you make to resolve this inconvenience?"
The possible answers:
A. Ask the developers to migrate the "session state component" of the application off the individual EC2 instances to DynamoDB. (my option, https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/service_dynamodb-session-handler.html)
B. Use application generated cookies.
C. Configure the Load Balancer with sticky sessions so you can resolve this in case of an instance fails.
And others I options I don't have now. By the way, the above options can give us a good moment to review this question and its answer.
The question context tries to trick you with too much context. If you focus on the real problem, you know that you need to keep sessions open and avoid customers to have to log in again in case one of the instances fail - keep sessions independent of where the application is running. So, sessions cannot be handled using application cookies as they are located in instances. The option B is out.
And then, what is sticky sessions and why it's not the answer?
By default, a Classic Load Balancer routes each request independently to the registered instance with the smallest load. However, you can use the sticky session feature (also known as session affinity), which enables the load balancer to bind a user's session to a specific instance. This ensures that all requests from the user during the session are sent to the same instance.
The key to managing sticky sessions is to determine how long your load balancer should consistently route the user's request to the same instance. If your application has its own session cookie, then you can configure Elastic Load Balancing so that the session cookie follows the duration specified by the application's session cookie. If your application does not have its own session cookie, then you can configure Elastic Load Balancing to create a session cookie by specifying your own stickiness duration.
Elastic Load Balancing creates a cookie, named AWSELB, that is used to map the session to the instance.
My comment here is, although the cookie (AWSELB) is created on client's browser side to map requests to a specific instance, if that sticky instance dies, requests will be routed to other instances running the applications - customers need to log in again.
Interesting AWS Forum threads:
Why is letter A correct?
If you really want your sessions to persist even through scaling-down events, you need to go back to basics: your application will need to store the sessions independently, as it did before sticky sessions were supported. In this case, sticky session support can provide an added optimization, allowing you to cache the session locally on each application server and only retrieve it from the central session store (the DB?) if it’s not in the local cache. Such cache misses would happen when application servers are removed from the load balancing pool but otherwise would not impact performance. Note that this technique can be used equally well with ELB and with other load balancers.
Am I missing something here? Any additional comments?