How to Prevent Session Loss During Auto Scaling Events
A company runs a web application on EC2 instances in an Auto Scaling group. The application stores session data locally on the EC2 instances. The operations team reports that after scaling events, users lose their sessions. Which TWO actions should the Solutions Architect take to resolve this issue?
Quick Answer
The correct answer is to enable sticky sessions on the Application Load Balancer and place the ElastiCache for Redis cluster outside the Auto Scaling group. Sticky sessions, also known as session affinity, ensure that a user’s requests are routed to the same EC2 instance during its lifetime, while keeping ElastiCache external to the Auto Scaling group guarantees the session data persists even when instances are terminated or replaced during scaling events. This combination directly addresses session loss after scaling events because the external Redis store remains available regardless of instance churn. On the AWS Certified Solutions Architect Professional SAP-C02 exam, this scenario tests your understanding of stateful application design in elastic environments—a common trap is assuming that ElastiCache replication alone prevents session loss, but replication does not protect against cache deletion when the cluster is tied to terminating instances. A useful memory tip: “Stick the session, persist the cache” reminds you to pair ALB stickiness with a durable, external data store like ElastiCache outside the ASG.
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
✓
Enable sticky sessions (session affinity) on the Application Load Balancer.
Options B and C are correct. Enabling sticky sessions (session affinity) on the Application Load Balancer ensures that requests from the same user are sent to the same EC2 instance while it is healthy, preventing session loss during scale-in events. However, sticky sessions do not protect against instance termination. Moving session data storage from the EC2 instances to Amazon ElastiCache for Redis externalizes the session store so it persists independently of any individual instance. Option A is incorrect because a Network Load Balancer does not support application-layer sticky sessions. Option D is incorrect because DynamoDB is not required when ElastiCache for Redis is used. Option E is incorrect because replication in ElastiCache provides high availability, not protection against session loss from Auto Scaling instance replacement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a Network Load Balancer instead of an Application Load Balancer.
Why it's wrong here
NLB does not have session affinity features.
- ✓
Enable sticky sessions (session affinity) on the Application Load Balancer.
Why this is correct
Sticky sessions route user to same instance.
- ✓
Move session data storage from the EC2 instances to Amazon ElastiCache for Redis.
Why this is correct
External store like ElastiCache persists across scaling.
- ✗
Store session data in Amazon DynamoDB.
Why it's wrong here
DynamoDB is an option but not required; ElastiCache can work if configured correctly.
- ✗
Enable replication in the ElastiCache cluster to handle failover.
Why it's wrong here
Replication doesn't prevent session loss during scale-in.
Visual reference
Go deeper
Related to this question
About these practice questions
This SAP-C02 question is part of Courseiva's 984-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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 has a web application behind an Application Load Balancer that uses sticky sessions. The application is deployed on EC2 instances in an Auto Scaling group. During a deployment, the team notices that users are experiencing errors after new instances are launched. What is the MOST likely cause?
hard- A.The target group's deregistration delay is too short.
- B.The stickiness duration is set too long, causing requests to be routed to terminated instances.
- ✓ C.The Auto Scaling group's scale-in policy is terminating instances with active sessions.
- D.The ALB health check is not configured for the new instances.
Why C: The most likely cause is that the Auto Scaling group's scale-in policy is terminating instances that still have active sessions. When an instance is terminated, the sticky sessions are lost, and users are routed to new instances where their session state may not exist, causing errors. The deregistration delay should allow in-flight requests to complete, but if the instance is terminated abruptly, sessions are disrupted.
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.