EC2 Auto Scaling: SAA-C03 study notes and practice questions
What to know about EC2 Auto Scaling for the SAA-C03 exam, from the Design Resilient Architectures domain (26% of the exam guide), then 3 free questions to test it. Part of the SAA-C03 study guide.
EC2 Auto Scaling questions are about two things: keeping capacity healthy and keeping it right-sized. The details of how a group decides when to scale are where the questions hide.
Key facts
A group spans Availability Zones and rebalances across them. Two or more zones is the baseline for high availability.
Launch templates (not the older launch configurations) define the AMI, instance type, security groups and user data. They support mixing On-Demand and Spot and several instance types.
Health checks: by default the group only uses EC2 status checks. Turn on ELB health checks so an instance whose application is hung, but whose OS is fine, gets replaced.
Stateless instances: keep session state in ElastiCache or DynamoDB, not on the instance, so scaling in doesn’t log users out.
Scaling policies
Policy
Use it when
Target tracking
You want a metric held near a value, such as 50% CPU or 1,000 requests per target. The default choice
Step scaling
You need different-sized responses to different breach sizes
Scheduled actions
Load changes at known times (every weekday at 9:00, or a one-off event date)
Predictive scaling
Load follows a daily or weekly pattern; it forecasts and launches capacity ahead of time
Other settings that show up
Instance warm-up and default instance warm-up stop new instances’ metrics from skewing scaling decisions before they’re ready.
Warm pools keep pre-initialized instances stopped and ready, for applications with long boot times.
Lifecycle hooks pause an instance while launching or terminating so you can run setup, or copy logs off before it goes.
Scaling on an SQS backlog: track a custom metric of messages per instance, not raw queue length.
Common traps
Relying on EC2 status checks for application failures. Add ELB health checks.
Reactive scaling for a known spike with slow-booting instances. Use a scheduled action (or predictive scaling) so capacity is ready before the spike.
Sticky sessions as a fix for lost sessions. It hides the problem; move session state off the instances.
An online learning platform runs its web application on two Amazon EC2 instances in a single Availability Zone behind an Application Load Balancer (ALB).
Sometimes the application on one instance stops responding, although the instance keeps passing its EC2 status checks. The ALB stops sending it traffic, but the instance stays in place until an engineer replaces it, and the site runs at half capacity.
The company wants the application to survive the loss of an Availability Zone and to replace failed instances automatically.
Which TWO actions should a solutions architect take? (Choose two.)
Choose two answers.
AA. Create an Auto Scaling group that uses subnets in at least two Availability Zones, and enable the same zones on the ALB.
BB. Configure the Auto Scaling group to use Elastic Load Balancing health checks in addition to the default EC2 status checks.
CC. Create a CloudWatch alarm on each instance's StatusCheckFailed_System metric that runs the EC2 recover action when it fails.
DD. Lower the target group's health check interval and unhealthy threshold so that failed instances are taken out of service sooner.
EE. Launch both instances into a spread placement group so that each one runs on a separate rack with its own network and power.
B. Right: Correct. By default, Auto Scaling looks only at EC2 status checks, which a hung application still passes. With ELB health checks turned on, an instance that the load balancer reports as unhealthy is marked unhealthy and replaced automatically. Learn more: About the health checks for your Auto Scaling group (opens in a new tab)
C. Wrong: The recover action moves an instance to new hardware when the system status check fails because of an AWS infrastructure problem. Here the instance passes its status checks while the application hangs, so the alarm never fires. It also does nothing for an Availability Zone outage. Learn more: Configure CloudWatch action based recovery on an EC2 instance (opens in a new tab)
E. Wrong: A spread placement group reduces correlated hardware failures, but it does not replace instances whose application has hung. Keeping both instances in the same zone still leaves the site exposed to a zone outage. Multi-AZ Auto Scaling covers both needs. Learn more: Placement strategies for your placement groups (opens in a new tab)
Explanation
Two separate gaps need closing. An Auto Scaling group across at least two Availability Zones handles the loss of a zone. Turning on ELB health checks for that group handles the hung application: EC2 status checks alone would keep reporting the instance as healthy, so Auto Scaling would never replace it, while the ALB on its own only routes around failed targets.
A university runs its online exam portal on Amazon EC2 instances in an Auto Scaling group with a target tracking policy on CPU use.
Exams take place on dates published a month in advance, with no regular weekly pattern, and thousands of students log in at exactly 09:00 on those days. New instances take about 8 minutes to boot and load the application, so students see errors at the start of each exam.
Enough capacity must be in service before 09:00 on exam days.
What should a solutions architect do?
Choose one answer.
AA. Create one-time scheduled actions that raise the group's minimum and desired capacity at 08:30 on each exam date and lower them afterwards.
BB. Add a predictive scaling policy in forecast and scale mode, so Auto Scaling learns the login pattern and launches instances ahead of it.
CC. Add a warm pool of stopped, pre-initialized instances to the group, so that instances launched by the scaling policy enter service faster.
DD. Lower the target tracking policy's CPU target from 60% to 30%, so that the group keeps more spare instances running all the time.
Show the answer and explanation
Answer: A
A. Right: Correct. Scheduled actions can run once at a set date and time, so the group can be scaled out before the known 09:00 login rush and scaled back in after the exam. The target tracking policy still handles any load above the scheduled capacity. Learn more: Scheduled scaling for Amazon EC2 Auto Scaling (opens in a new tab)
B. Wrong: Predictive scaling forecasts load from recurring daily and weekly patterns in up to 14 days of history. Exams on irregular dates do not form such a pattern, so the forecast would not reliably add capacity before 09:00. Known one-off dates suit scheduled actions. Learn more: How predictive scaling works (opens in a new tab)
The load spike is known in advance but does not repeat on a regular schedule, and instances take 8 minutes to become ready. One-time scheduled actions put capacity in service before 09:00 on each exam date. Predictive scaling needs a recurring pattern, and warm pools and lower targets still react only after the load arrives.
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.
AA. Turn on duration-based sticky sessions on the target group, so that each customer is always routed to the same instance.
BB. Increase the target group's deregistration delay, so that instances finish serving their customers before they are removed.
CC. Move session and basket data into an Amazon ElastiCache cluster with replicas, and have the application read sessions from it.
DD. 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)
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)
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.
Want more on EC2 Auto Scaling? The 5 full-length practice sets have 10 more EC2 Auto Scaling questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →