Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 275 discussion

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

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.

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.

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.

A for sure.

Answer is A. Makes more sense to me.

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'.

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.

A. since only a boot storm issue at 9am and settle down in mid morning, 20 instance is enough to support the workload NOT C. Reduce threshold to trigger (lets say 50% from 80% utilization) and lower cool down period, will still take time to ramp up to max 20 instance.

I would go with A. Autoscaling is still there and the problem is clearly in morning.

My mistake, I should have chosen c. A lower threshold can expand in advance, and lowering cooling can increase the expansion frequency.

I choose option A because the root of the problem is the inability of the scaling speed in the morning to meet the demand, rather than what criteria to use for scaling.

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.

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.

A. Implement a scheduled action that sets the desired capacity to 20 shortly before the office opens.

CHATGPT says Answers is A A. Implement a scheduled action that sets the desired capacity to 20 shortly before the office opens.

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.