The correct answer is: Leverage Amazon ElastiCache to store and manage session data externally.

This approach decouples session state from individual EC2 instances and centralizes it in a fast, managed in-memory data store like Redis or Memcached. This allows any EC2 instance behind the load balancer to access session information regardless of where the user was initially connected. This architecture supports horizontal scaling and is ideal for distributed environments where sessions must persist across instance changes.

Why the other options are incorrect:

Enable sticky sessions (session affinity) on the Application Load Balancer is not ideal for dynamic scaling environments. Sticky sessions bind a user session to a specific instance, but when instances scale in or out, the session may be lost or unavailable. This method also introduces uneven load distribution over time.

Use Session Manager from AWS Systems Manager to handle session tracking is unrelated to application-level session management. Session Manager is designed for remote shell access and auditing, not for managing user sessions in web applications.

Use AWS STS's GetSessionToken API to manage session lifecycle is focused on temporary credentials and identity federation, not user session state in web applications. Its not suitable for application-level session tracking.

Why this question is important: It tests your understanding of state management in horizontally scaled architectures. Many AWS exam questions require knowing when to externalize state to achieve elasticity. Recognizing when a service like ElastiCache fits into distributed systems is key.

Hint for solving this type of question: If an application is scaling across instances or zones, assume local state cannot be relied on. Look for options that move state to shared, external services.

Full AWS Practitioner Certification Question