A company is running a stateful web application on EC2 instances in an Auto Scaling group behind an ALB. The application stores session data locally on the instance. The company notices that users are frequently logged out and lose session data during scaling events. What is the MOST operationally efficient way to preserve session state?
Externalizing session state ensures data persists across instance replacements.
Why this answer
Option A is correct because migrating session state to ElastiCache for Redis provides a centralized, external, and highly available session store that persists independently of EC2 instance lifecycles. This ensures that when instances are terminated or added during Auto Scaling events, session data remains intact and accessible from any instance, eliminating user logouts and data loss. It is operationally efficient as it requires minimal application code changes and leverages a fully managed, in-memory data store optimized for low-latency access.
Exam trap
The trap here is that candidates often choose sticky sessions (Option D) thinking it solves session persistence, but they overlook that sticky sessions only route traffic to the same instance and do not protect against data loss when that instance is terminated during scaling events.
How to eliminate wrong answers
Option B is wrong because pre-populating a custom AMI with session data from S3 is impractical and inefficient: session data is dynamic and changes constantly, so a static AMI cannot reflect real-time session states, and this approach would require frequent AMI rebuilds and complex synchronization. Option C is wrong because increasing the cooldown period to 600 seconds only delays scaling events but does not prevent session loss when instances are eventually terminated; it also reduces the Auto Scaling group's ability to respond to load changes, potentially impacting availability. Option D is wrong because enabling sticky sessions (session affinity) on the ALB only binds a user's session to a specific instance, but if that instance is terminated during a scale-in event, the session data is still lost; it does not provide a durable, shared session store.