AWS Certified Solutions Architect - Associate SAA-C03 Exam - Question 275

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?

Examice · Accepted Answer

The application experiences poor performance at the start of the workday due to the insufficient number of EC2 instances handling the initial surge in demand. To address this issue, a target tracking action can dynamically adjust the number of instances based on actual CPU utilization. This method ensures that instances are added as needed, reacting swiftly to increased load, while the auto-scaling group can scale down during periods of lower demand, optimizing costs. Decreasing the cooldown period allows the system to respond more rapidly to changes in demand, enhancing responsiveness and further reducing unnecessary costs. Therefore, implementing a target tracking action with a lower CPU threshold and a decreased cooldown period is the best approach.

asoli · Answer

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

meowruki · Answer

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.

kruasan · Answer

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.

NolaHOla · Answer

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.

FourOfAKind · Answer

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

TariqKipkemei · Answer

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.

[Removed] · Answer

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

pentium75 · Answer

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

zTopic · Answer

Answer is C

feddo · Answer

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

Mia2009687 · Answer

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.

Ramdi1 · Answer

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.

wearrexdzw3123 · Answer

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

Mikado211 · Answer

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.

ChymKuBoy · Answer

A for sure.

LuckyAro · Answer

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.

KZM · Answer

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.

kraken21 · Answer

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.

DrWatson · Answer

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.

kapalulz · Answer

C. Implement a target tracking action triggered at a lower CPU threshold, and decrease the cooldown period

BrijMohan08 · Answer

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.

Uzbekistan · Answer

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

maryam_sh · Answer

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.

AbhiBK · Answer

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.

[Removed] · Answer

I will go with A based on this "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."
Setting the instances to 20 before the office hours start should address the issue.

Dr_Chomp · Answer

I'm going with A - it tells us that 20 instances is the normal capacity during the work day - so scheduling that at the start of the work day means you don't need to put load on the system to trigger scale-out.  So this is like a warm start.  Cool down has nothing to do with anything and it doesn't mention anything about CPU/resources for target setting.

justhereforccna · Answer

Have to go with A on this one

xmark443 · Answer

There may be days when the demand is lower. So schedule scaling is more cost than target tracking.

Konb · Answer

I think the "cost" part that talks against A is a catch. No information why the EC2s are slow - maybe it's not CPU?

On the other hand we know that  "Auto Scaling group scales up to 20 instances during work hours". A seems to be the only option that kinda satisfies requirements.

LazyTs · Answer

It's A, C will not be fast enough with the sudden influx of the users, if C is fast enough then the original scenario should already be good enough as the 20 is already the max which set to start at working hours(when CPU starts to spin up)

Uzbekistan · Answer

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

wearrexdzw3123 · Answer

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.

Cyberkayu · Answer

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.

foha2012 · Answer

Answer is A. Makes more sense to me.

LeonSauveterre · Answer

Exam-wise, you gotta choose A.

The problem is explicitly described as slowness at the start of the day, which implies a predictable traffic pattern. Option C argues for a responsive approach (reacting dynamically to real-time demand changes) rather than a predictive approach (pre-scaling based on a known schedule).

Also, option A can minimize costs compared to option D as well, because the desired capacity is a flexible number that the Auto Scaling group targets at specific times but doesn’t enforce as a hard minimum.

If the emphasis is on handling varying traffic patterns throughout the day, Option C could be considered viable.

zdi561 · Answer

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

AWS Certified Solutions Architect - Associate SAA-C03 Exam - Question 275

Discussion