AWS Session State and Session Stickiness

Purpose of This Lesson

This lesson explains how session state affects applications running behind a load balancer. The central design decision is whether to keep session information on a specific EC2 instance using sticky sessions or move that information to an external service such as Amazon DynamoDB or Amazon ElastiCache.

The distinction matters because a load balancer can route a user’s subsequent request to a different instance. If that instance cannot access the user’s existing session information, the user may be required to authenticate again or may lose application state.

Key Concepts

Session State

Session state is information associated with a user’s interaction with an application. In the lesson’s example, the application receives a session token after the user authenticates. That token is cached on the EC2 instance handling the session.

Session state can include authentication-related information or other dynamic application data that must remain available across requests.

Session Stickiness

Sticky sessions, also called session affinity, cause a client to remain associated with a particular backend instance for as long as the relevant cookie remains valid. The load balancer uses the cookie to route the client back to the same EC2 instance.

This can prevent repeated authentication when the session token is stored locally on the original instance.

Externalized Session State

Instead of keeping session information only on an EC2 instance, the application can store it in an external data service. The lecture identifies Amazon DynamoDB and Amazon ElastiCache as options for session-state storage.

With externalized state, any suitable application instance can retrieve the user’s session information. The application is therefore less dependent on the continued availability of one particular EC2 instance.

Session State and Load Balancer Behavior

Consider two EC2 instances behind a load balancer:

1. A user connects to the load balancer.
2. The load balancer forwards the request to one EC2 instance.
3. The user authenticates, potentially through a directory service such as Microsoft Active Directory.
4. The application receives a session token and caches it on the selected instance.
5. The user disconnects and later reconnects.
6. The load balancer may select the other EC2 instance.

Without sticky sessions or shared session storage, the second instance does not have the cached token. The user may therefore need to authenticate again.

Option 1: Sticky Sessions

With sticky sessions enabled, a cookie binds the client to the original EC2 instance while the cookie remains valid. When the user reconnects during that period, the load balancer sends the client back to the same instance, allowing the locally cached session token to be reused.

This can improve the user experience, but it does not remove the dependency on the original instance. If that instance fails or becomes unavailable, the session information stored there is also unavailable to the application.

Option 2: External Session Storage

With external session storage, the application stores session information in a service such as DynamoDB or ElastiCache. When a request reaches any application instance, that instance retrieves the required session data from the external store.

This approach allows the load balancer to distribute requests among instances without requiring the client to remain tied to one particular backend.

Combining Both Techniques

Sticky sessions and external session storage are not mutually exclusive. The lecture notes that both techniques can be used together. The appropriate combination depends on how the application handles state and what behavior is required during instance changes or failures.

Exam- or Assessment-Relevant Takeaways

• If session information is cached only on one EC2 instance and the next request reaches another instance, the user may have to authenticate again.
• Sticky sessions use a client cookie to keep a user associated with the same backend instance while the cookie remains valid.
• Sticky sessions improve continuity but retain a dependency on the availability of the selected instance.
• Externalizing session state to DynamoDB or ElastiCache allows different application instances to retrieve the same session information.
• When a scenario emphasizes avoiding dependence on one instance or supporting instance changes, external session storage is the important design consideration.
• When a scenario specifically describes a cookie binding a client to one backend, the relevant feature is session stickiness.
• The lesson presents DynamoDB and ElastiCache as external session-state options; the correct choice depends on the application’s session-storage requirements, which are not detailed further in the lecture.

Tool / Feature Decision Guide

Situation	Relevant approach	Reasoning	Main limitation or consideration
The application keeps session tokens locally and users should return to the same instance	Sticky sessions	A valid cookie directs the client back to the instance holding the cached session	The instance remains a dependency and may fail
Requests may be handled by different instances	External session storage	Each instance can request the session data from DynamoDB or ElastiCache	The application must use the external store for session information
The application needs cookie-based affinity but also wants session data outside the instance	Combine sticky sessions with external storage	Both techniques can be used together	The design still needs clear handling of cookie validity and external state
A user reconnects after the original instance is no longer available	Prefer an externalized-state design	Another instance can retrieve the session information from the shared store	The lecture does not define failover or data-retention settings for the store

Common Traps / Misconceptions

• Sticky sessions are the same as shared session storage: They are not. Sticky sessions keep the client connected to one instance; shared storage makes session data available to multiple instances.
• Sticky sessions eliminate the availability risk: They do not. If the instance containing the local session state fails, the session may no longer be available.
• A load balancer automatically shares application memory: It does not. If state exists only in an instance’s local cache, another instance cannot use it unless the application stores it externally or the client remains sticky.
• The session cookie itself makes the application stateless: It does not. The cookie supports routing affinity, while the session token remains cached on the selected instance in the example.
• External storage is limited to authentication tokens: The lesson uses tokens as an example but applies the concept to other dynamic application session data as well.
• DynamoDB and ElastiCache are interchangeable in every design: The lecture identifies both as options but does not state that they have identical behavior or are suitable for every workload.

Real-World Engineer / Analyst Notes

• First identify where session state currently resides: local instance memory, local cache, or an external service.
• When diagnosing repeated logins, check whether requests are being routed to different instances and whether the new instance can access the original session state.
• Treat sticky sessions as an affinity mechanism, not as a complete solution for resilient state management.
• If the application must continue using session data when traffic moves to another instance, separate that state from the individual EC2 instance.
• Document the cookie-validity dependency when relying on sticky sessions; the affinity applies only while the cookie remains valid.
• Evaluate the entire application flow, including the authentication directory service and the session-state store, rather than focusing only on the load balancer.

Quick Reference Summary

• No stickiness and local session state: A request routed to a different instance may require reauthentication.
• Sticky sessions: A valid cookie routes the client back to the original instance.
• Sticky-session risk: The original instance remains a single-instance dependency for that session.
• External session state: Store session data in DynamoDB or ElastiCache so multiple instances can access it.
• Combined approach: Sticky sessions and external session storage can be used together.
• Core decision: Choose between instance affinity and shared, externally accessible session state based on the application’s continuity and availability needs.

Flashcards

Q: A user authenticates on EC2 instance A, but a later request is sent to instance B. What problem occurs if the session token is stored only on instance A?

A: Instance B cannot access the locally cached token, so the user may need to authenticate again.

Q: Which feature keeps a client associated with the same backend instance while a cookie remains valid?

A: Sticky sessions, also called session affinity. The cookie allows the load balancer to route the client back to the original instance.

Q: When is external session-state storage preferable to relying only on sticky sessions?

A: It is preferable when requests should be able to reach different instances or when the application should not depend on the availability of one instance.

Q: What is the decisive difference between sticky sessions and externalized session state?

A: Sticky sessions preserve the client-to-instance relationship, while externalized state makes the session information accessible to multiple application instances.

Q: An application caches authentication tokens on EC2 instances and users report repeated logins after reconnecting. What design issue should be investigated first?

A: Determine whether the load balancer is sending reconnecting users to different instances that do not have the original cached session token.

Q: What does the cookie used by sticky sessions accomplish?

A: It binds the client to a particular EC2 instance for as long as the cookie remains valid, helping the client reuse locally cached session information.

Q: Why do sticky sessions not fully solve the availability problem for locally stored session data?

A: The session remains tied to the selected instance. If that instance fails, the application may lose access to the session state.

Q: Which AWS services does the lesson identify as external session-state stores?

A: Amazon DynamoDB and Amazon ElastiCache.

Q: What type of data, besides authentication tokens, might be externalized from an EC2 instance?

A: Other dynamic application session-state information can be stored externally so it is not dependent on one instance.

Q: Can sticky sessions and external session storage be used together?

A: Yes. The lecture explicitly identifies them as techniques that can be combined.

Q: A user must be able to reconnect to any healthy application instance without repeating authentication. Which general design direction fits this requirement?

A: Externalize the session state to a shared service such as DynamoDB or ElastiCache so any instance can retrieve it.

Q: What happens when the sticky-session cookie is no longer valid?

A: The client is no longer guaranteed to remain bound to the original instance, so a subsequent request may reach another instance.

Practice Questions

Question 1

A Microsoft application runs on two EC2 instances behind a load balancer. After authentication, the session token is cached only on the instance that handled the login. A user disconnects and reconnects, and the load balancer sends the request to the other instance. What is the most likely result?

A. The load balancer automatically copies the token to the second instance
B. The user may need to authenticate again
C. The directory service is permanently unavailable
D. The session token is converted into a DNS record

Correct answer: B

The second instance does not have the locally cached session token, so the user may need to repeat authentication.

Question 2

An application team wants a reconnecting client to return to the same EC2 instance that holds its cached session token, provided the routing information has not expired. Which feature addresses this requirement?

A. External session storage in DynamoDB
B. Sticky sessions
C. Directory-service authentication
D. Replacing EC2 with a different compute service

Correct answer: B

Sticky sessions use a cookie to bind the client to the original instance while the cookie remains valid.

Question 3

A workload must tolerate requests being routed to different EC2 instances, and session information should remain available even if the original instance fails. Which approach best matches the lesson?

A. Cache all session information only in the original instance
B. Use only a client cookie and ignore the session token
C. Store session state in an external service such as DynamoDB or ElastiCache
D. Disable authentication after the first request

Correct answer: C

Externalizing session state allows another application instance to retrieve the information instead of depending on the original instance’s local cache.

Question 4

Which statement best describes the main limitation of sticky sessions in the lesson’s design?

A. They prevent all clients from using the load balancer
B. They make the session independent of the backend instance
C. They retain a dependency on the instance where the session is cached
D. They eliminate the need for a session token

Correct answer: C

Sticky sessions improve continuity by returning the client to the same instance, but failure of that instance can still affect the locally stored session.

WordPress Metadata

Suggested Slug:
aws-session-state-session-stickiness-soa-c03

Meta Description:
Understand how sticky sessions and external session-state storage affect authentication continuity, load balancing, availability, and AWS architecture decisions.

Tags:
AWS, AWS Certified CloudOps Engineer, SOA-C03, session state, sticky sessions, Elastic Load Balancing, DynamoDB, ElastiCache, EC2, high availability