Scheduled scaling for a predictable morning EC2 traffic spike

SAA-C03 By islever Editorial Last updated

Design high-performing and elastic compute solutions. Design cost-optimized compute solutions.

Short answer

A Use a scheduled scaling action to raise the Auto Scaling group's desired capacity to 20 shortly before office hours so the browser-based application is warm before staff arrive.

Question

A company runs an internal browser-based application. The application runs on Amazon EC2 instances behind an Application Load Balancer. The instances run in an Amazon EC2 Auto Scaling group across multiple Availability Zones. The Auto Scaling group scales up to 20 instances during work hours, but scales down to 2 instances overnight. Staff are complaining that the application is very slow when the day begins, although it runs well by mid-morning.
How should the scaling be changed to address the staff complaints and keep costs to a minimum?
  1. Implement a scheduled action that sets the desired capacity to 20 shortly before the office opens. Correct Answer
  2. Implement a step scaling action triggered at a lower CPU threshold, and decrease the cooldown period.
  3. Implement a target tracking action triggered at a lower CPU threshold, and decrease the cooldown period.
  4. Implement a scheduled action that sets the minimum and maximum capacity to 20 shortly before the office opens.

Key Takeaways

This item tests whether you can distinguish predictable scheduled scaling from reactive step or target-tracking policies; the trap is assuming a lower CPU threshold and shorter cooldown will prevent the morning cold-start slowdown.

Scheduled scaling is the right control for a predictable morning login surge on an EC2 Auto Scaling fleet; the answer is to raise desired capacity to 20 before office hours, not wait for reactive CPU policies.

Common mistake: The most tempting wrong answer is C: lowering the target-tracking CPU threshold and cooldown still waits for the morning traffic to raise CPU before adding instances, so the two-instance overnight fleet remains slow during the initial burst.

Expert Analysis

Predictable morning ramp The decisive fact is that the slowdown happens at the same point every workday and clears by mid-morning. That is a scheduled, predictable demand ramp, not an unpredictable spike. AWS Auto Scaling guidance recommends scheduled scaling for predictable traffic patterns; the group can add capacity before the load arrives rather than after users already feel latency. Option A does exactly that: it sets desired capacity to 20 shortly before the office opens, so the target group has warm instances behind the ALB when staff begin logging in.

Why reactive policies miss the symptom Options B and C adjust reactive policies. Step scaling and target tracking both wait for a CloudWatch alarm or target breach; only then does the ASG launch instances. A lower CPU threshold and shorter cooldown may make the reaction faster, but they cannot eliminate the initial cold-start interval, and a lower threshold can keep extra instances running longer, undermining the cost constraint. Commenters who favor C focus on faster reaction, but the question is about the predictable start-of-day ramp, where pre-scaling is the documented remedy.

Why A over D Option D sets both minimum and maximum capacity to 20. That guarantees 20 instances, but it also pins the group at 20 and removes flexibility; it is a heavier, less cost-aware control than changing desired capacity. Option A raises the desired count before demand, while leaving the ASG's existing min/max and policies to manage capacity later. It keeps the overnight two-instance baseline and only pays for the larger fleet immediately before it is needed, which matches the requirement to address complaints and keep costs minimum.

Verdict Correct answer: A. Use scheduled scaling to pre-warm the EC2 Auto Scaling group ahead of the known morning login ramp.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When a stem describes a recurring, clock-driven slowdown—every morning, every Monday, or at shift change—treat it as a predictable load pattern and look for a scheduled action first. Reactive policies such as step or target tracking cannot add capacity before demand appears, so a lower CPU threshold only shortens the symptom, not the cold-start delay. Compare scheduled options by whether they only set desired capacity (flexible, cost-aware) or pin min/max (rigid and likely more expensive).

Frequently Asked Questions

Why does target tracking with a shorter cooldown still leave the morning slowdown?

Target tracking is reactive, so it starts launching instances only after CPU rises when staff begin using the application. The two overnight instances still absorb the first burst while the new instances boot and register with the ALB.

Why not set the Auto Scaling group's minimum and maximum capacity to 20 before office hours?

Pinning both bounds to 20 guarantees capacity but keeps the group rigid at 20 and can cost more than necessary. Setting desired capacity to 20 pre-warms the fleet while preserving the existing min/max controls for later scaling.

How should the scheduled action coexist with the overnight scale-down?

Keep the existing overnight action that lowers capacity to 2, and add a recurring scheduled action shortly before office hours that raises desired capacity to 20. The two actions create a predictable daytime and overnight cadence.

More SAA-C03 FAQ →

Community Votes

A
71%
C
16%
B
12%

71% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 53 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 53

  1. asoli 👍 37 Answered C
    At first, I thought the answer is A. But it is C. It seems that there is no information in the question about CPU or Memory usage. So, we might think the answer is A. why? because what we need is to have the required (desired) number of instances. It already has scheduled scaling that works well in this scenario. Scale down after working hours and scale up in working hours. So, it just needs to adjust the desired number to start from 20 instances. But here is the point it shows A is WRONG!!! If it started with desired 20 instances, it will keep it for the whole day. What if the load is reduced? We do not need to keep the 20 instances always. That 20 is the MAXIMUM number we need, no the DESIRE number. So it is against COST that is the main objective of this question. So, the answer is C
  2. mandragon 👍 10
    If it stars with 20 instances it will not keep it all day. It will scale down based on demand. The scheduled action in Option A simply ensures that there are enough instances running to handle the increased traffic when the day begins, while still allowing the Auto Scaling group to scale up or down based on demand during the rest of the day. https://docs.aws.amazon.com/autoscaling/ec2/userguide/scale-your-group.html
  3. meowruki 👍 7 Answered C
    C. Implement a target tracking action triggered at a lower CPU threshold, and decrease the cooldown period. Here's the reasoning: Target Tracking Scaling Policy: With a target tracking scaling policy, you can set a target value for a specific metric, such as CPU utilization. The Auto Scaling group then adjusts the capacity to maintain that target. Lower CPU Threshold: By triggering the target tracking action at a lower CPU threshold, the Auto Scaling group can proactively add instances when the workload increases, helping to address the slowness at the beginning of the day. Decrease Cooldown Period: Reducing the cooldown period allows the Auto Scaling group to scale in and out more rapidly, making adjustments quicker in response to changing demand.
  4. kruasan 👍 5 Answered C
    This option will scale up capacity faster in the morning to improve performance, but will still allow capacity to scale down during off hours. It achieves this as follows: • A target tracking action scales based on a CPU utilization target. By triggering at a lower CPU threshold in the morning, the Auto Scaling group will start scaling up sooner as traffic ramps up, launching instances before utilization gets too high and impacts performance. • Decreasing the cooldown period allows Auto Scaling to scale more aggressively, launching more instances faster until the target is reached. This speeds up the ramp-up of capacity. • However, unlike a scheduled action to set a fixed minimum/maximum capacity, with target tracking the group can still scale down during off hours based on demand. This helps minimize costs.
  5. pentium75 👍 5
    There is a cooldown period in the auto-scaling group, which helps 'keeping costs to a minimum' as instances would be removed sooner.
Show 25 more comments
  1. NolaHOla 👍 4
    I would personally go for C, Implementing a target tracking scaling policy would allow the Auto Scaling group to adjust its capacity in response to changes in demand while keeping the specified metric at the target value https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-strategies.html Option A is not the best solution because it sets the desired capacity to 20 shortly before the office opens, but it does not take into account the actual demand of the application. This means that the company will be paying for 20 instances all the time, even during the off-hours, which will result in unnecessary costs. Additionally, there may be days when the demand is lower or higher than expected, so it is not a scalable solution.
  2. pentium75 👍 4 Answered C
    A is not cost effective, it would set the number of instances to maximum even before the first employee arrives. D is not cost effective, it would cause the permanent use of 20 instances B could almost work, but if you configure small steps then it scales too slowly in the morning; if you configure big steps (like "add 8 instances at a time") it would scale in the morning but not be cost-efficient during the day. C would address the requirement, it would scale to meet a certain CPU utilization. Decreasing the cooldown period (which is not possible for the scaling policy itself but for the auto-scaling group) would help 'keeping costs to a minimum'.
  3. TariqKipkemei 👍 4
    To keep costs to a minimum target tracking is the best option. For example the scaling metric is the average CPU utilization of the EC2 auto scaling instances, and their average during the day should always be 80%. When CloudWatch detects that the average CPU utilization is beyond 80% at start of day, it will trigger the target tracking policy to scale out the auto scaling group to meet this target utilization. Once everything is settled and the average CPU utilization has gone below 80% at night, another scale in action will kick in and reduce the number of auto scaling instances in the auto scaling group.
  4. FourOfAKind 👍 4 Answered C
    With step scaling and simple scaling, you choose scaling metrics and threshold values for the CloudWatch alarms that invoke the scaling process. You also define how your Auto Scaling group should be scaled when a threshold is in breach for a specified number of evaluation periods. We strongly recommend that you use a target tracking scaling policy to scale on a metric like average CPU utilization or the RequestCountPerTarget metric from the Application Load Balancer. https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html
  5. Clouddon 👍 3 Answered A
    A. Implement a scheduled action that sets the desired capacity to 20 shortly before the office opens. 🔍 Explanation: The issue is that Auto Scaling reacts to demand. When the day begins, the Auto Scaling group starts with only 2 instances. It takes time to scale up to 20, and in the meantime, users experience slow performance. To fix this: You want to proactively scale up before demand starts. This ensures that the full capacity is already in place by the time staff begin using the application. Scheduled scaling is ideal for this use case because the workload is predictable (e.g., work hours are known).
  6. feddo 👍 3 Answered A
    I vote for A The desired capacity does not statically fix the size of the group. Desired capacity: Represents the initial capacity of the Auto Scaling group at the time of creation. An Auto Scaling group attempts to maintain the desired capacity. It starts by launching the number of instances that are specified for the desired capacity, and maintains this number of instances as long as there are no scaling policies or scheduled actions attached to the Auto Scaling group. https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html
  7. Mia2009687 👍 3 Answered C
    I was in team A. But from the definition of desired capacity, it seems once we set it as 20, it will try to keep it as 20 which is not saving cost. Desired capacity: Represents the initial capacity of the Auto Scaling group at the time of creation. An Auto Scaling group attempts to maintain the desired capacity. It starts by launching the number of instances that are specified for the desired capacity, and maintains this number of instances as long as there are no scaling policies or scheduled actions attached to the Auto Scaling group.
  8. TheFivePips 👍 3
    From what I can tell, you must specify an end time, or else it will run indefinitly. So I think A would be right, if they specified an end time. Otherwise C is more cost effective https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html
  9. srcntpc 👍 3 Answered A
    Why A is Correct: Scheduled scaling action increases capacity to 20 instances shortly before office hours. Ensures instances are already running and warm when employees start using the app. This avoids delays caused by dynamic scaling and instance warm-up.
  10. Ramdi1 👍 3 Answered A
    I am going A based on it stating upto 20 so you already know what they maximum they use which is n a sense consistent. however i can see why people have put C. I think they need more clarification on the questions.
  11. Mikado211 👍 3 Answered A
    The question 369 is exactly the same problem, Since a scheduled scaling doesn't disable the autoscaling later in the day the A works perfectly well.
  12. wearrexdzw3123 👍 3
    My mistake, I should have chosen c. A lower threshold can expand in advance, and lowering cooling can increase the expansion frequency.
  13. xdkonorek2 👍 3
    This is right, setting desired capacity doesn't turn off autoscaling policies
  14. ChymKuBoy 👍 3 Answered A
    A for sure.
  15. zTopic 👍 3 Answered C
    Answer is C
  16. BrijMohan08 👍 2 Answered A
    Scaling Out: In the morning when you schedule the AWS EC2 scaling to have a minimum and maximum of 20 instances, if the load on your application increases beyond the current number of instances, AWS Auto Scaling will automatically launch new instances to meet the demand up to the maximum of 20 instances. Scaling In: As the load on your application decreases in the afternoon or night, AWS Auto Scaling will continuously monitor the health and load of your instances. If the instances are underutilized and can be terminated without affecting your application's performance, AWS Auto Scaling will automatically scale in by terminating excess instances, Why not D? If you specify the min instance, AWS will always keep the minimum number of instances (20 in this case) running.
  17. DrWatson 👍 2 Answered A
    https://docs.aws.amazon.com/autoscaling/ec2/userguide/consolidated-view-of-warm-up-and-cooldown-settings.html DefaultCooldown Only needed if you use simple scaling policies. API operation: CreateAutoScalingGroup, UpdateAutoScalingGroup The amount of time, in seconds, between one scaling activity ending and another one starting due to simple scaling policies. For more information, see Scaling cooldowns for Amazon EC2 Auto Scaling (https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scaling-cooldowns.html) Default: 300 seconds.
  18. AbhiBK 👍 2
    Question is about cost effectiveness hence Use target tracking scaling policies to maintain a specific metric, such as CPU utilization or request count per target. This allows the Auto Scaling group to dynamically adjust the number of instances based on real-time demand. We do not need to have 20 instances up and running during start of the day.
  19. maryam_sh 👍 2 Answered A
    Not C because: target tracking scaling attempts to maintain a target metric (like average CPU utilization). While more responsive, it would still react to increased load rather than pre-scaling. The initial slow period would persist as the scaling reacts to the increased demand rather than anticipating it.
  20. KZM 👍 2
    C: target tracking may be a better option for ensuring the application remains responsive during high-traffic periods while also minimizing costs during periods of low usage. The target tracking can be used without CloudWatch alarms, as it relies on CloudWatch metrics directly.
  21. zdi561 👍 2 Answered A
    Decreasing cpu threshold could cause more running instance(might have more than two at night) therefore higher cost. Schedule at desired to 20 minutes before the day will solve the issue that the app is very slow at begininng of the day
  22. kraken21 👍 2 Answered C
    How should the scaling be changed to address the staff complaints and keep costs to a minimum? "Option C" scaling based on metrics and with the combination of reducing the cooldown the cost part is addressed.
  23. NolaHOla 👍 2
    Honestly not completely sure, but the rest of the options either don't think for the MOST Cost effective solution (as when directly placed on 20 this will generate cost|) or are irrelevant
  24. meowruki 👍 2
    Options A and D involve scheduled actions, which are time-based and may not be as responsive to immediate changes in demand. They also do not dynamically respond to varying workloads.
  25. LuckyAro 👍 2 Answered C
    Between closing and opening times there'll be enough "cooling down" period if necessary, however, I don't see it's relationship with the solution.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

S3 Multi-Region Access Point and Replication Strategy

S-grade

Securing NLB with Security Groups for Minimal Change

S-grade

Most Cost-Effective 7-Year Retention for EBS Snapshots?

S-grade

AWS Forecast vs SageMaker for Time-Series Prediction

S-grade

Practice All SAA-C03 Questions

Access 120 questions with complete answers and detailed explanations.

View Full SAA-C03 Practice Test →

← Back to SAA-C03 Study Guide