AWS Session State and Sticky Sessions – SAP-C02 Study Guide

Purpose of This Lesson

Auto Scaling and load balancing work best when application instances are interchangeable. Session state, uploaded files, local databases, and other instance-specific data can break that model because a request routed to a different instance may not find the information created by the original instance.

This lesson covers two approaches:

• Externalize session state and application data so any healthy instance can retrieve it.
• Use load balancer sticky sessions to keep a client associated with one target temporarily.

For highly available and scalable designs, externalizing state is generally the preferred strategy. Sticky sessions can be useful in specific legacy or compatibility scenarios, but they introduce important tradeoffs.

Key Concepts

Stateful versus stateless application instances

A stateless application instance does not depend on data stored only in its local memory or storage. Any instance can process any request because shared data is stored in a durable, accessible service.

Examples of state that should usually be externalized include:

• Authentication tokens, login state, and shopping carts
• User preferences and workflow progress
• Relational application data
• Uploaded images, videos, and documents
• Shared configuration or generated artifacts

If state remains only on one EC2 instance, an Auto Scaling event, instance failure, deployment, or health-check replacement can make that state unavailable.

Externalizing session state

A common architecture places an Elastic Load Balancer in front of multiple application instances. The instances read and write shared state in services such as:

• Amazon DynamoDB for highly available key-value or document-style session records
• Amazon ElastiCache for very low-latency, frequently accessed session data and caches
• Amazon Aurora or Amazon RDS when session data must be stored in a relational database or is already part of a relational transaction
• Amazon S3 for durable object data such as uploads and media; it is not normally the primary low-latency session database
• Amazon EFS when multiple instances require a shared POSIX-compatible file system

The application typically stores a session identifier in the client cookie and uses that identifier to retrieve the corresponding record from the shared store. If the original instance fails, another instance can load the session and continue processing the request.

Sticky sessions

Sticky sessions, also called session affinity, cause a load balancer to route a client repeatedly to the same target for the duration of a configured cookie or application session.

With an Application Load Balancer, stickiness can be configured using:

• Duration-based stickiness, where the load balancer issues a cookie.
• Application-based stickiness, where the application generates the session cookie and the load balancer uses it to maintain affinity.

Classic Load Balancer also supports sticky sessions. Network Load Balancer does not provide cookie-based application stickiness; it routes connections using flow-based load balancing.

Sticky sessions reduce the chance that a request reaches a different instance, but they do not make local state highly available. If the target fails, subsequent requests can go to another target, where locally stored session data is absent.

Why external state is usually preferable

Externalizing state provides several advantages:

• Any healthy instance can serve the request.
• Instance replacement does not inherently destroy the session.
• Scaling out and in is more predictable.
• Deployments and blue/green releases are easier to operate.
• Load can be distributed more evenly across targets.

The external store becomes a critical dependency and must be designed for appropriate availability, capacity, latency, encryption, access control, and backup or recovery requirements.

Exam-Relevant Takeaways

• Do not store important session state only in EC2 instance memory or ephemeral local storage when instances are behind a load balancer or Auto Scaling group.
• Use DynamoDB for durable, highly available key-value session records when relational features are unnecessary.
• Use ElastiCache when extremely low-latency access is required and the application can tolerate cache-oriented behavior or has a durable backing store.
• Use S3 for objects, not as a general-purpose session store.
• Use EFS when multiple instances need shared file-system semantics, not merely because the application has session data.
• Sticky sessions are a routing behavior, not a replication or persistence mechanism.
• A failed sticky-session target can still cause session loss if the session exists only locally.
• Externalized state allows instances to remain interchangeable, which is a core property of resilient Auto Scaling architectures.
• If the question requires users to remain logged in after an instance failure, choose shared session storage or a managed identity/session design rather than sticky sessions alone.
• Evaluate the session store’s throughput, latency, expiration mechanism, encryption, and failure behavior; selecting a service solely because it is external is insufficient.

Architecture Decision Guide

Requirement	Preferred approach	Why	Important caveat
Durable key-value session records	DynamoDB	Highly available and scalable key-value access with TTL support	Design keys, capacity, IAM, encryption, and consistency appropriately
Extremely low-latency temporary session or cache data	ElastiCache	In-memory access with very low latency	Plan for node failure and decide whether data can be recreated
Relational session data or transactional consistency	RDS or Aurora	Supports SQL and relational transactions	Adds database scaling and connection-management considerations
User uploads and media	Amazon S3	Durable, scalable object storage	Access objects through application authorization or controlled URLs
Shared files requiring file-system semantics	Amazon EFS	Shared mountable file system for multiple instances	Consider throughput, latency, cost, and mount/network configuration
Compatibility with a legacy app that requires one target	Sticky sessions	Minimal application changes	Uneven load, weaker failover behavior, and reduced elasticity
Session continuity after instance failure	Externalized session state	A replacement instance can retrieve the session	The external store must itself be highly available

Common Exam Traps

• Treating sticky sessions as a backup mechanism: Stickiness only influences routing. It does not copy local memory or disk data to another target.
• Assuming the cookie contains the complete session: A load balancer cookie generally identifies or maintains affinity to a target; it does not automatically replicate the application’s session data.
• Using S3 for low-latency session lookups: S3 is excellent for objects but is not a substitute for a purpose-built session key-value store.
• Choosing EFS for every shared-data problem: EFS is appropriate for shared file access, not necessarily for high-volume key-value session lookups.
• Ignoring target failure: A sticky client can be reassigned when its target becomes unhealthy. Any data stored only on that target may be lost.
• Assuming all load balancers support the same stickiness model: Confirm whether the scenario uses ALB, CLB, or NLB and whether cookie-based affinity is available.
• Making every session store durable by default: ElastiCache is often used for low-latency state, but the design must account for node replacement and whether the data can be reconstructed.
• Keeping a local database on an Auto Scaling instance: A database or uploaded file stored only on one instance will not scale or fail over correctly with the application tier.

Real-World Engineer Notes

• Keep session records small. Store a session identifier in the browser and keep the authoritative data in the server-side store.
• Set expiration or TTL values so abandoned sessions do not grow without limit. DynamoDB TTL is useful for eventual cleanup, but it should not be treated as an exact-time deletion mechanism.
• Encrypt session data in transit and at rest. Use least-privilege IAM policies for application access to DynamoDB, S3, or other stores.
• Avoid placing sensitive authentication material directly in client-controlled cookies. Use secure, appropriately scoped cookies and validate session identifiers server-side.
• Monitor session-store latency, throttling, errors, connection counts, cache evictions, and capacity utilization.
• If using ElastiCache, determine whether the session can be rebuilt from a durable source. If losing the cache forces users to log in again, the design should explicitly accept or mitigate that behavior.
• Sticky sessions can create uneven target utilization when some clients generate substantially more traffic than others. They also make scale-in and rolling deployments more complicated.
• For modern applications, token-based authentication can reduce server-side session state, but token revocation, expiration, size, and security requirements still need deliberate design.

Quick Reference Summary

• Best general pattern: load balancer plus interchangeable application instances plus an external session store.
• DynamoDB: durable, scalable key-value or document session data.
• ElastiCache: very low-latency in-memory state or cache data.
• RDS/Aurora: relational session requirements.
• S3: durable objects and uploads.
• EFS: shared file-system access.
• Sticky sessions: route a client to the same target temporarily; do not replicate state or guarantee failover continuity.
• Failure test: ask what happens to the user’s session when the selected instance is terminated. If the answer is “the data disappears,” the design is not resilient unless that loss is acceptable.

Flashcards

1. What is session state?

Data associated with a user’s interaction or workflow that a later request may need, such as authentication status, a cart, or preferences.

2. Why is local session state a problem in an Auto Scaling group?

A later request may reach a different instance, and instance replacement or termination can destroy locally stored state.

3. What is the preferred scalable design for session state?

Store the state in a shared external service so any healthy application instance can retrieve it.

4. Which AWS service is a common durable key-value session store?

Amazon DynamoDB.

5. Which AWS service is commonly chosen for very low-latency in-memory session data?

Amazon ElastiCache.

6. What do sticky sessions do?

They use load-balancer or application cookies to keep a client associated with the same target for a configured period or session.

7. Do sticky sessions replicate local instance state?

No. They affect routing only.

8. What happens if a sticky-session target fails?

The load balancer can route the client to another healthy target, but locally stored session data may be unavailable.

9. Is S3 normally a session database?

No. S3 is primarily object storage and is better suited to uploads, media, and other durable objects.

10. When is EFS a better choice than DynamoDB?

When multiple instances need shared file-system semantics, such as access to common files through a mounted file system.

11. Which load balancer commonly supports cookie-based stickiness for HTTP applications?

Application Load Balancer; Classic Load Balancer also supports sticky sessions.

12. Does Network Load Balancer provide cookie-based application stickiness?

No. NLB uses flow-based connection routing rather than HTTP cookie-based session affinity.

Practice Questions

Question 1

A web application runs on an Auto Scaling group behind an Application Load Balancer. Users are occasionally forced to log in again when an instance is replaced. The application stores authentication session data in instance memory. Which change best improves resilience with minimal impact to request routing?

A. Enable ALB sticky sessions and leave the session data in memory.

B. Store the session records in DynamoDB and allow requests to reach any healthy instance.

C. Store the session data in Amazon S3 and retrieve it for every request.

D. Increase the ALB idle timeout.

Correct answer: B

Explanation: DynamoDB provides a shared, highly available key-value store that any replacement instance can access. Sticky sessions do not preserve memory when a target fails, S3 is not intended for low-latency session lookups, and an idle-timeout change does not address lost state.

Question 2

A legacy application cannot be modified immediately and stores its session in local memory. The business accepts that users may need to log in again if a target fails, but wants normal requests from a user to reach the same target. Which solution best fits these constraints?

A. Enable ALB sticky sessions.

B. Store all session data in S3.

C. Use an NLB and configure an application cookie.

D. Store the session in the instance’s ephemeral disk and disable health checks.

Correct answer: A

Explanation: ALB sticky sessions provide temporary client-to-target affinity and require fewer application changes. They do not provide failover preservation, which the scenario explicitly accepts. NLB does not use application cookies for this purpose, and disabling health checks is unsafe.

Question 3

A media-processing application uses multiple EC2 instances. Users upload large video files, and any processing instance must be able to access those files. The files must remain available when instances scale in. Which service is the most appropriate primary storage location?

A. Instance memory

B. Amazon S3

C. ALB sticky-session cookies

D. DynamoDB session records

Correct answer: B

Explanation: Amazon S3 provides durable, scalable object storage for large uploads and is independent of the lifecycle of the EC2 instances. Sticky sessions and DynamoDB are not appropriate primary storage mechanisms for large video objects.

Question 4

An application requires sub-millisecond access to temporary session data. Losing the data during a cache failure is acceptable because users can authenticate again and the data can be rebuilt. Which option is most appropriate?

A. ElastiCache, with an explicit cache-failure and reauthentication strategy

B. S3, because it is highly durable

C. EFS, because it is a shared file system

D. Local instance memory with no load balancer

Correct answer: A

Explanation: ElastiCache is designed for very low-latency in-memory access. The design must explicitly handle node failure and cache misses. S3 prioritizes durable object storage, EFS provides file-system semantics, and local memory does not support a resilient multi-instance architecture.

Question 5

A solutions architect must ensure that a user’s shopping cart remains available after the EC2 instance serving the user is terminated. Which statement is correct?

A. Sticky sessions guarantee that the cart will be available on the replacement instance.

B. The cart should be externalized to a shared data service; sticky sessions alone are insufficient.

C. The cart should be stored in an ALB cookie without size or security considerations.

D. The Auto Scaling group should use only one instance.

Correct answer: B

Explanation: The cart must be stored outside the individual instance, commonly in DynamoDB, ElastiCache, or an appropriate relational store depending on durability and consistency needs. Sticky sessions cannot recover data that existed only on a terminated target.