SAA-C03 practice question: EC2 Auto Scaling (3 of 3)

Design Resilient Architectures A free question from our original SAA-C03 practice exam. Try it, then open the answer to see why each option is right or wrong.

A travel booking website runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer. Login sessions and shopping baskets are held in each instance's memory. When the group scales in at night, or replaces an instance that fails its health checks, the customers on that instance are logged out and lose their baskets. Sessions must survive the removal of any instance without adding noticeable latency to each request. Which change meets these requirements?

Choose one answer.

A. Turn on duration-based sticky sessions on the target group, so that each customer is always routed to the same instance.
B. Increase the target group's deregistration delay, so that instances finish serving their customers before they are removed.
C. Move session and basket data into an Amazon ElastiCache cluster with replicas, and have the application read sessions from it.
D. Turn on instance scale-in protection for every instance in the group, so that Auto Scaling cannot terminate instances that hold sessions.

Show the answer and explanation

Answer: C

A. Wrong: Stickiness keeps a customer on one instance, but the session still lives only in that instance's memory. When the instance is deregistered or becomes unhealthy, the load balancer sends the customer to a new target, where the session does not exist. Learn more: Sticky sessions for your Application Load Balancer (opens in a new tab)
B. Wrong: The deregistration delay lets in-flight requests complete before a target is removed. It does not move session data anywhere, so customers still lose their sessions when the instance terminates, and it does nothing for an instance that fails suddenly. Learn more: Edit target group attributes for your Application Load Balancer (opens in a new tab)
C. Right: Correct. Moving session state off the instances makes the web tier stateless, so any instance can serve any customer and instances can be removed at will. An in-memory cache keeps session lookups fast, and the replicas hold a second copy of the session data. Learn more: REL05-BP06 Make systems stateless where possible (opens in a new tab)
D. Wrong: Scale-in protection stops the group from removing protected instances during scale-in, so the group could no longer shrink at night and costs rise. It also does not protect instances from health check replacement, so sessions would still be lost when an instance fails. Learn more: Use instance scale-in protection to control instance termination (opens in a new tab)

Explanation

The root cause is session state held on individual instances, which Auto Scaling must be free to remove. Storing sessions in a shared, fast store such as ElastiCache makes instances interchangeable. Sticky sessions, deregistration delay and scale-in protection all leave the session on the instance, so it is still lost when the instance goes.

Study

REL05-BP06 Make systems stateless where possible

SAA-C03 practice question: EC2 Auto Scaling (3 of 3)

Explanation

Study

Keep practising