Answers A & D are incorrect because the question states to keep costs to a minimum. This means, NOT running 20 instances from the start. Answers B & C are both a better options. The problem in the morning is not that there should have been 20 instances running and that they are not running. The problem is that the auto scaling is not responding fast enough to the increase in demand. That is why decreasing the cool down period will make the auto scaling more aggressive (and responsive) but will still run less than 20 instances from the get go, and therefore will cost less money. Also, AWS recommends using target scaling as much as possible. https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html “We strongly recommend that you use a target tracking scaling policy to scale on...” So between B & C, the recommend AWS option is answer C.

why not A, since our main issue is the time, hence we schedule to solve the issue

Also just to note this is a multi AZ situation! have a think of that as well.

I agree that this action should be scheduled, as they mention they need performance when people start using this internal application, this again comes down to the company if this is application provides value for them then they will spend no matter the cost if they want their staff to be able to perform their jobs,,, especially if this a highly used application. end of story lol

Option B suggests implementing a step scaling action triggered at a lower CPU threshold and decreasing the cooldown period. This approach allows the Auto Scaling group to dynamically adjust the number of instances based on CPU utilization. By scaling up the number of instances proactively when CPU utilization starts to increase, the application can better handle the workload during peak hours, potentially addressing the staff complaints about slowness. Moreover, decreasing the cooldown period allows the Auto Scaling group to scale more responsively, ensuring faster adjustments to workload changes. This option not only addresses the staff complaints but also aims to optimize costs by scaling the instances based on actual demand.

I think C

A/D are constly. C is recommended by AWS even in referenced document.

C is correct

While that doesn't sound like a good use case for scheduled action, both responses using scheduled action have 20 instances running regardless of the actual need. A cost-effective option is to use an action track target that launches every time the CPU goes low. In this scenario scaling will occur before CPU utilization drops to a point where performance begins to suffer. The result will solve performance problems while reducing costs. Using a reduced cooldown period also helps to quickly terminate unnecessary instances, further reducing costs.

it can not be B or C. becaue if for example we use target scaling based of low CPU usage. this ploicy will work all teh time. and we will have many instances running all over the day with low CPU usage. on the other hand using schedule policy for short period is most cost effective then it resumes normal scaling cpu value.

C, keep the cost low and decrease cool down to spin up machines faster. The keyword is cost. Spinning 20 ec2 instance at the beginning of the day unnecessarily increases cost. Users will not complain as we are monitoring cpu and spinning up machines quickly.

The answer is C. Target tracking scaling helps to improve application availability and reduce costs. For example, you can use Auto Scaling to automatically launch EC2 instances for your Auto Scaling group when demand increases to help maintain performance, and terminate instances when demand drops to save money. https://aws.amazon.com/about-aws/whats-new/2017/07/introducing-target-tracking-scaling-policies-for-auto-scaling/

A is the answer due to many things: - The question never mentioned that the auto scaling is happening because of CPU utilization, it could be anything else like RAM or Network throughput. so assuming that CPU is the reason to scale out is wrong. - We know the desired number of instances that keeps the application running in a good performance so making a scheduled rule to initialize this number of instances when the office starts makes sense. - Those who say we should scale gradually didn't fix the main issue which is the application is slow at when work starts hence the number of instances are not enough.

C should be the answer

Target tracking scaling policies = can then scale out your group (add more instances). Step and simple scaling policies = Metrics that decrease when capacity increases and increase when capacity decreases can be used to proportionally. ********************* There is an objective tracking scaling, the idea is to improve with the cooldown period.

Answer is A. If we go with C and scale out using a little CPU threshold maybe in the Full use the ASG can scale out to more than 20 instances. For example. I know that the workload runs fine with 50% CPU using 20 instances. If I configure to autoscale to scale out with more than 30% use of CPU to satisfy users in the morning then during the mid day probably I will have 22 or 23 instances running. So the cost will go UP. Did you get it ?

Ans is A. EC2 cooldown by default is just 300s/5mins, will this make big difference to stop the staff complains? I don't think so. However, in the question statement itself already told the ASG will scale up to 20 in the work hours. Right now option A is just move the open hour bit earlier. I think the correct ans is A.