Solving Session Data Loss During Auto Scaling Events
A company runs a critical e-commerce platform on AWS. The application consists of an Application Load Balancer (ALB) that distributes traffic to an Auto Scaling group of EC2 instances running a web server. The web servers store session data locally on the instance's ephemeral storage. The Auto Scaling group is configured with a min of 2, max of 10, and desired of 2. Recently, during a flash sale, traffic surged and the Auto Scaling group scaled out to 10 instances. However, many users reported that their shopping carts were lost and they were logged out during the event. The Cognito user pool was used for authentication, and the application uses cookies to maintain session state. The ALB's stickiness is enabled. The team observed that the ALB's RequestCountPerTarget metric was well below the instance's capacity, but the error rate increased. The CloudWatch logs show that the web server returned 503 errors for a subset of requests. After the flash sale ended, the Auto Scaling group scaled back to 2 instances, and the issue disappeared. The team wants to prevent this from happening in future events. Which solution should the Solutions Architect recommend?
Quick Answer
The correct solution is to modify the application to store session data in an Amazon ElastiCache for Redis cluster instead of local ephemeral storage. This directly addresses the root cause of session data loss during auto scaling events: when an EC2 instance is terminated during scale-in or replacement, any session data stored on its ephemeral storage is permanently lost, even with ALB stickiness enabled. On the SAP-C02 exam, this scenario tests your understanding of stateless application design and the pitfalls of relying on instance-local state for stateful workloads. A common trap is assuming that increasing the minimum instance count or adjusting health checks will prevent data loss, but these measures do not decouple session persistence from the instance lifecycle. The key insight is that ElastiCache provides a centralized, durable session store that survives scaling events, ensuring users remain logged in and their shopping carts are preserved. Memory tip: think “state should never live on the instance—keep it in a cache.”
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Modify the application to store session data in an Amazon ElastiCache for Redis cluster instead of local ephemeral storage.
The root cause is that session data stored on ephemeral storage is lost when instances are terminated or replaced. Even with ALB stickiness, if an instance is terminated (e.g., due to scaling in or health check failure), the session data is gone. Option C solves this by storing sessions externally in ElastiCache, which persists independently of EC2 instances, ensuring sessions survive scaling events. Option A would prevent scaling in but does not address data loss if instances become unhealthy or replaced. Option B would make the problem worse because without stickiness, requests could go to different instances, causing session loss even without termination. Option D only delays health checks and does not solve data loss.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the minimum size of the Auto Scaling group to 10 to handle the surge without scaling down.
Why it's wrong here
This would increase cost and does not solve the session loss on instance termination during scale-in.
- ✗
Disable stickiness on the ALB so that any instance can handle any request.
Why it's wrong here
Without stickiness, sessions would be lost even without scaling, as requests are distributed randomly.
- ✓
Modify the application to store session data in an Amazon ElastiCache for Redis cluster instead of local ephemeral storage.
Why this is correct
This decouples sessions from instances, making them persistent across scaling events and instance replacements.
- ✗
Increase the health check interval on the ALB to prevent instances from being marked unhealthy too quickly.
Why it's wrong here
This does not address session storage; sessions are still lost when instances are terminated.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
One of 1,660 original SAP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on SAP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company runs a stateless web application on EC2 instances behind an Application Load Balancer (ALB). During peak traffic, some instances become unhealthy and are replaced by Auto Scaling, but users experience errors. What is the MOST likely cause?
hard- A.The EC2 instances are of a burstable performance type.
- B.The Auto Scaling group's minimum size is too small.
- ✓ C.The health check target path or port is misconfigured.
- D.The health check interval is too long.
Why C: If the health check target path or port is misconfigured, healthy instances may fail health checks and be replaced, causing errors during peak traffic. Option A is incorrect because burstable performance instances are not directly related to health check failures; health checks depend on the configured endpoint. Option B is incorrect because a small minimum size affects capacity, not the accuracy of health checks. Option D is incorrect because a longer health check interval delays detection of unhealthy instances but does not cause healthy instances to be mistakenly replaced.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAP-C02 exam.