SAA-C03 Practice Question 25: Session State ElastiCache
AWS Certified Solutions Architect – Associate (SAA-C03) · Test 3 · question 5 of 10
An online store runs on an Auto Scaling group of EC2 instances behind an Application Load Balancer. Each instance keeps logged-in sessions and shopping carts in its own memory, and sticky sessions are enabled on the target group so that each user keeps returning to the same instance.
Customers complain that they are randomly logged out and lose their carts. The complaints cluster around scale-in events and the replacement of unhealthy instances. What should the architect change to fix the problem permanently?
Show answer and explanation
Answer:
The root cause is that session state lives on instances that are designed to be disposable. When a user's instance is terminated by scale-in or replaced after a failed health check, its memory goes with it. Moving sessions and carts into a shared in-memory store such as Amazon ElastiCache makes the web tier stateless. Any instance can serve any request, and the session survives no matter which instance disappears. AWS describes this centralized session store as the way to keep sessions durable when the web fleet is elastic.
Option A doesn't help, because stickiness only decides where a request is routed. If the cookie points at a target that has been deregistered or is unhealthy, the load balancer picks a new target and updates the cookie. A longer duration still sends the user to an instance that never had their session.
Option C protects requests, not sessions. Deregistration delay gives in-flight requests time to finish, 300 seconds by default, before a target is removed. After that the instance still terminates and the in-memory sessions are still lost.
Option D changes only how stickiness is tracked. With either cookie type, the session data stays on one instance and is lost when that instance goes away.
References: Session management; Edit target group attributes for your Application Load Balancer