Optimizing Costs and Preserving Elasticity in Auto-Scaling

Answer - B and C.

The Auto Scaling cooldown period is a configurable setting for your Auto Scaling group that helps to ensure that Auto Scaling doesn't launch or terminate additional instances before the previous scaling activity takes effect.

After the Auto Scaling group dynamically scales using a simple scaling policy, Auto Scaling waits for the cooldown period to complete before resuming scaling activities.

When you manually scale your Auto Scaling group, the default is not to wait for the cooldown period, but you can override the default and honor the cooldown period.

Note that if an instance becomes unhealthy, Auto Scaling does not wait for the cooldown period to complete before replacing the unhealthy instance.

For more information on Autoscale cool down timers please visit the URL:

http://docs.aws.amazon.com/autoscaling/latest/userguide/Cooldown.html

You can also modify the Cloudwatch triggers to ensure the thresholds are appropriate for the scale down policy.

For more information on Autoscaling user guide please visit the URL:

http://docs.aws.amazon.com/autoscaling/latest/userguide/as-scale-based-on-demand.html

When an application scales out and in multiple times in the same hour, it could indicate that the Auto Scaling policy is not optimized for cost efficiency. Each scaling event can result in additional infrastructure resources being added or removed, which can lead to increased costs.

To optimize for costs while preserving elasticity, the design choice would be to modify the Auto Scaling policy to use scheduled scaling actions. This approach would enable the application to scale out and in based on a predefined schedule, which would allow for better predictability and cost management.

Scheduled scaling actions would allow you to define when the application should scale out or in based on factors such as time of day or day of the week. For example, if the application experiences high traffic during business hours, you could schedule the Auto Scaling policy to scale out during those hours and scale in during non-business hours. This approach would enable you to optimize for costs while still ensuring that the application has the necessary resources to handle traffic spikes.

In contrast, modifying the Auto Scaling Group cooldown timers would not necessarily address the issue of multiple scaling events in the same hour. Cooldown timers are used to prevent additional scaling events from occurring too soon after a previous event, which can help ensure that the application has time to stabilize before additional resources are added or removed.

Modifying the Amazon Cloudwatch alarm period that triggers the AutoScaling scale-down policy would also not necessarily address the issue of multiple scaling events in the same hour. The alarm period determines how long an alarm condition must exist before an Auto Scaling policy is triggered. Changing the alarm period could result in longer or shorter periods between scaling events, but it would not address the underlying issue of multiple scaling events in the same hour.

Similarly, modifying the Auto Scaling group termination policy to terminate the newest instance first would not necessarily address the issue of multiple scaling events in the same hour. The termination policy determines which instance to terminate when scaling in, but it does not address the underlying issue of the application scaling in and out multiple times in the same hour.