A developer runs a web application on several EC2 instances behind an Application Load Balancer in an Auto Scaling group. The application currently keeps each user's logged-in session in memory on the instance that first served them, so scale-in events log users out. The developer wants the application to be stateless so any instance can serve any request. Where should the session data be stored?
- AIn an Amazon ElastiCache for Redis cluster that all instances read and write, keying each session by a token in the user's cookie. Correct
- BOn a shared Amazon EBS volume mounted by every instance so each request reads and writes the same on-disk session files.
- CIn the local instance store of each instance, with sticky sessions on the load balancer pinning each user to one instance for their lifetime.
- DIn a process-level in-memory cache replicated by a background thread that gossips session entries to the other running instances.
Why A is correct: Externalising session data to a shared ElastiCache for Redis store makes every instance stateless, so any instance can serve any request and scale-in no longer drops sessions.
Why B is wrong: A single EBS volume cannot be attached read-write to many instances at once, so this neither shares sessions reliably nor removes the per-instance state the requirement targets.
Why C is wrong: Sticky sessions keep state on one instance, so a scale-in or failure of that instance still loses the session and leaves the application stateful as before.
Why D is wrong: Custom in-memory gossip replication is fragile, races during scale events, and still keeps authoritative state inside instances rather than in an external shared store.