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 provides a managed caching service that can be used to store session data in a distributed manner. It supports both Redis and Memcached, allowing multiple EC2 instances to access shared session data, making it ideal for applications that scale horizontally.
Using session affinity (sticky sessions) means that a user’s session is tied to a specific instance. This approach does not support scaling well because it can lead to uneven load distribution and single points of failure, which is not suitable for a distributed architecture.
Session Manager from AWS Systems Manager is designed for managing EC2 instances and facilitating remote access. It is not meant for managing application session data, thus making it unsuitable for distributed session management in this context.
The GetSessionToken API operation in AWS Security Token Service (AWS STS) is used for obtaining temporary security credentials. It does not manage session data for applications, making it irrelevant for the purpose of distributed session data management.
I systematize that the answer is:
Use Amazon ElastiCache to manage and store session data.