Dynamic Scaling and Scheduled Scaling

Dynamic scaling

• When you configure dynamic scaling, you define how to scale the capacity of your Auto Scaling group in response to changing demand.

  • E.g. You have a web application that currently runs on two instances, and you want the CPU utilization of the Auto Scaling group to stay at around 50 percent when the load on the application changes.

    • This gives you extra capacity to handle traffic spikes without maintaining an excessive number of idle resources.

• You can configure your Auto Scaling group to scale dynamically to meet this need by creating a scaling policy.

  • Scale out your group (add more instances) to deal with high demand at peak times.

  • Scale in your group (run fewer instances) to reduce costs during periods of low utilization.

• Scaling policy:

  • It instructs EC2 Auto Scaling to track a specific CloudWatch metric and what action to take.

  • 3 types:

    • Target tracking scaling:

      • Simplest and easiest to set up.

      • With target tracking scaling policies, you select a scaling metric and set a target value.

      • EC2 Auto Scaling creates and manages the CloudWatch alarms that trigger the scaling policy and calculates the scaling adjustment based on the metric and the target value.

      • The scaling policy adds or removes capacity as required to keep the metric at, or close to, the specified target value.

      • For example, you can use target tracking scaling to:

        • Keep the average aggregate CPU utilization of your Auto Scaling group at 40 percent.

        • Keep the request count per target of your Application Load Balancer target group at 1000 for your Auto Scaling group.

    • Step/Simple scaling:

      • You choose scaling metrics and threshold values for the CloudWatch alarms that trigger 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.

Step Scaling vs Simple Scaling Policies

• Both require you to create CloudWatch alarms for the scaling policies.

• Both require you to specify the high and low thresholds for the alarms.

• Both require you to define whether to add or remove instances, and how many, or set the group to an exact size.

• The main difference between the policy types is the step adjustments that you get with step scaling policies.

  • When step adjustments are applied, and they increase or decrease the current capacity of your Auto Scaling group, the adjustments vary based on the size of the alarm breach.

• In most cases, step scaling policies are a better choice than simple scaling policies, even if you have only a single scaling adjustment.

• The main issue with simple scaling is that after a scaling activity is started, the policy must wait for the scaling activity or health check replacement to complete and the cooldown period to expire before responding to additional alarms.

  • However, with step scaling, the policy can continue to respond to additional alarms, even while a scaling activity or health check replacement is in progress.

Scheduled scaling

• Scheduled scaling allows you to set your own scaling schedule.

• 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 actions based on the predictable traffic patterns of your web application.

  • Scaling actions are performed automatically as a function of time and date.

• To configure your Auto Scaling group to scale based on a schedule, you create a scheduled action.

  • The scheduled action tells EC2 Auto Scaling to perform a scaling action at specified times.

  • To create a scheduled scaling action, you specify the start time when the scaling action should take effect, and the new minimum, maximum, and desired sizes for the scaling action.