What should the solutions architect do to ensure that the architecture supports distributed session data management?
Use Amazon ElastiCache to manage and store session data.
Use session affinity (sticky sessions) of the ALB to manage session data.
Use Session Manager from AWS Systems Manager to manage the session.
Use the GetSessionToken API operation in AWS Security Token Service (AWS STS) to manage the session.
Explanations:
Amazon ElastiCache is a fully managed in-memory caching service that can be used to store session data across multiple instances. It provides low-latency access to session data and supports various caching strategies, making it ideal for distributed session management in applications that require frequent scaling.
Session affinity (sticky sessions) with ALB routes all requests from a user to the same instance, which can lead to issues in a distributed architecture where instances frequently scale up and down. This method does not support session data management across multiple instances and can result in loss of session data when instances terminate.
Session Manager from AWS Systems Manager is primarily used for securely managing EC2 instance sessions. It is not designed for managing application-level session data. It does not provide a scalable way to store session information for a distributed application.
The GetSessionToken API operation in AWS STS is used for obtaining temporary security credentials for AWS services, not for managing session data in web applications. It does not address the requirement for distributed session management.
As far as I’m aware, the answer is:
Use Amazon ElastiCache to manage and store session data.
From what I’ve seen, the answer is:
Use Amazon ElastiCache to manage and store session data.