Auto Scaling Policies to Optimize Cost and Performance for Web Servers | SysOps Administrator Exam Prep

Optimizing Auto Scaling Policies for Cost and Performance

Question

You are working for an electronic company having an online store.

Due to new discount schemes initiated by Marketing Team, large traffic is expected on web servers.

For high availability, web servers are launched in multiple AZ.

For launching web servers, the Auto Scaling simple scaling policy is configured.

You observe many instances are getting launched during busy hours & are getting terminated only post-peak time.

Due to this, high cost is incurred for web servers.

Which of the following options would help you to resolve this?

Answers

Explanations

Click on the arrows to vote for the correct answer

A. B. C. D.

Correct Answer: B.

Health Check grace period defines a time after which the Auto-Scaling group will perform health checks on an instance after a new instance is launched.

Cooldown timers that ensure the Auto-scaling group do not launch or terminate a new instance before a last scaling out/scaling is complete.

In the above case, several instances are launched, as the scaling group initiated a new instance before the earlier instance is fully into service.

Cooldown timers can be less for scale-in as they will quickly terminate instances during off-peak hours.

Cooldown timers for scale-out can be marked as default timers in a simple scaling policy so that the scaling group will wait for 300 secs before launching a new instance.

Option A & Dare incorrect as scale up / scale down is involved with vertical scaling & not for horizontal scaling with Auto-Scaling.

Option C is incorrect as the health check grace period will be time before the Auto-Scaling group starts checking the health of an instance.

For more information on Cooldown timers, refer to the following URLs-

https://docs.aws.amazon.com/autoscaling/ec2/userguide/Cooldown.html

In this scenario, the company is using Auto Scaling to launch web servers in multiple availability zones for high availability. However, the simple scaling policy used is resulting in many instances getting launched during busy hours and incurring high costs for the company. To resolve this issue, the Auto Scaling configuration needs to be modified to optimize the scaling policy.

Option A suggests creating a health check grace period of 300 seconds for scaling up and a period of 120 seconds for scaling down. The health check grace period is the time period that Auto Scaling waits after launching or terminating an instance before checking its health. During this time, the instance is initializing and may not be fully operational. By configuring a longer grace period for scaling up, Auto Scaling will wait for new instances to be fully operational before scaling out. However, a shorter grace period for scaling down may result in instances being terminated before they have completed their tasks, leading to potential data loss.

Option B suggests creating a cooldown period of 300 seconds for scaling out and a cooldown period of 120 seconds for scaling in. The cooldown period is the time Auto Scaling waits after launching or terminating an instance before allowing further scaling activity. During this time, Auto Scaling will not launch or terminate additional instances. By configuring a longer cooldown period for scaling out, Auto Scaling will wait longer before launching additional instances, reducing the likelihood of launching too many instances. Similarly, a shorter cooldown period for scaling in will allow instances to be terminated more quickly once the load decreases.

Option C suggests creating a health check grace period of 300 seconds for scaling out and a period of 120 seconds for scaling in. This is similar to Option A, but with different grace periods for scaling up and scaling down.

Option D suggests creating a cooldown period of 300 seconds for scaling up and a cooldown period of 120 seconds for scaling down. This is similar to Option B, but with different cooldown periods for scaling up and scaling down.

In this scenario, Option B is the best option as it provides a longer cooldown period for scaling out, reducing the likelihood of launching too many instances during peak hours. Additionally, a shorter cooldown period for scaling in allows instances to be terminated more quickly once the load decreases, reducing costs.