Addressing Morning Slowness Issue with EC2 Instances and Autoscaling Group

Answer - C.

The AWS Documentation mentions the following.

Scaling based on a schedule allows you to scale your application in response to predictable load changes.

For example, every week, the traffic to your web application starts to increase on Wednesday, remains high on Thursday, and starts to decrease on Friday.

You can plan your scaling activities based on the predictable traffic patterns of your web application.

Option A is incorrect because simple scaling increases or decreases the group's current capacity based on a single scaling adjustment.

Option B is incorrect because Step Scaling increases or decreases the group's current capacity based on a set of scaling adjustments, known as step adjustments, that vary based on the size of the alarm breach.

Option D is incorrect since Static scaling policy doesn't exist.

For more information on scaling policies for Auto scaling, please refer to the below URL's-

https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scale-based-on-demand.html#as-scaling-types https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html

The issue of slow application performance during specific times suggests that there is a sudden increase in traffic to the application during that period. The current architecture, which uses an EC2 Autoscaling group, can help with handling increases in traffic, but it may not be configured properly to handle such sudden surges.

A. Adding a Simple scaling policy to the Autoscaling group means that the group will automatically adjust the number of instances based on CPU utilization or any other metric that is specified. This policy may not be effective in handling sudden surges of traffic since it may take time to spin up new instances, and this could cause the application to continue to be slow during the morning period.

B. A step scaling policy would allow the Autoscaling group to adjust the number of instances based on the metric in a predefined set of steps, which would be faster than a simple scaling policy. This policy may be helpful, but it may not be ideal if the surge in traffic is not predictable or if the number of instances required during the surge varies widely.

C. A scheduled scaling policy allows the Autoscaling group to adjust the number of instances based on a predetermined schedule. This policy may be ideal for addressing the morning slowdown issue since it allows for preemptive scaling before the expected surge in traffic. By adding a scheduled scaling policy to the Autoscaling group, it is possible to have the group automatically spin up additional instances before the morning period, ensuring that there are enough resources available to handle the surge in traffic.

D. A static scaling policy means that the number of instances in the Autoscaling group is fixed, and it does not change based on any metric or schedule. This policy may not be effective in handling the morning slowdown issue since it does not allow for additional resources to be added during the expected surge in traffic.

Therefore, the best option for ensuring that the issue is not encountered during the morning period is to add a scheduled scaling policy to the Autoscaling group (Option C).