AWS Auto Scaling
User Guide

Best Practices for AWS Auto Scaling

The following best practices can help you make the most of AWS Auto Scaling:

  • Wherever possible, you should scale on Amazon EC2 instance metrics with a 1-minute frequency because that ensures a faster response to utilization changes. Scaling on metrics with a 5-minute frequency can result in a slower response time and scaling on stale metric data. By default, EC2 instances are enabled for basic monitoring, which means metric data for instances is available at 5-minute intervals. For an additional charge, you can enable detailed monitoring to get metric data for instances at a 1-minute frequency. For more information, see Configure Monitoring for Auto Scaling Instances in the Amazon EC2 Auto Scaling User Guide.

  • We also recommend that you enable Auto Scaling group metrics. Otherwise, actual capacity data is not shown in the capacity forecast graphs that are available on completion of the Create Scaling Plan wizard. To enable Auto Scaling group metrics, open an Auto Scaling group in the Amazon EC2 console, and from the Monitoring tab, choose Enable Group Metrics Collection. These metrics describe the group rather than any of its instances. For more information, see Enable Auto Scaling Group Metrics in the Amazon EC2 Auto Scaling User Guide.

  • Check which instance type your Auto Scaling group uses. Amazon EC2 instances with burstable performance, which are T3 and T2 instances, are designed to provide a baseline level of CPU performance with the ability to burst to a higher level when required by your workload. Depending on the target utilization specified by the scaling plan, you could run the risk of exceeding the baseline and then running out of CPU credits, which limits performance. For more information, see CPU Credits and Baseline Performance for Burstable Performance Instances. To configure these instances as unlimited, see Using an Auto Scaling Group to Launch a Burstable Performance Instance as Unlimited in the Amazon EC2 User Guide for Linux Instances.

  • We recommend waiting 24 hours after creating a new Auto Scaling group to configure predictive scaling. At minimum, there must be 24 hours of historical data to generate the initial forecast. If the group has less than 24 hours of historical data and predictive scaling is enabled, this results in the scaling plan being unable to generate a forecast until the next forecast period after the group has collected the required amount of data.

Other Considerations

Keep the following additional considerations in mind:

  • Predictive scaling uses workload forecasts to schedule capacity in the future. The quality of the forecasts varies based on how cyclical the workload is and the applicability of the trained forecasting model. Predictive scaling can be run in forecast only mode to assess the quality of the forecasts and the scaling actions created by the forecasts. You can set the predictive scaling mode to Forecast only when you create the scaling plan and then change it to Forecast and scale when you're finished assessing the forecast quality. For more information, see Predictive Scaling Settings and Monitoring and Evaluating Forecasts.

  • If you choose to specify different metrics for predictive scaling, you must ensure that the scaling metric and load metric are strongly correlated. The metric value must increase and decrease proportionally to the number of instances in the Auto Scaling group. This ensures that the metric data can be used to proportionally scale out or in the number of instances. For example, the load metric is total request count and the scaling metric is average CPU utilization. If the total request count increases by 50 percent, the average CPU utilization should also increase by 50 percent, provided that capacity remains unchanged.

  • You can create scaling policies from various AWS consoles, but AWS Auto Scaling does not overwrite these other scaling policies or create new ones by default. You can optionally replace the existing scaling policies with target tracking scaling policies created from the AWS Auto Scaling console by enabling the Replace external scaling policies setting in the scaling plan. For more information, see Dynamic Scaling Settings.

  • Before creating your scaling plan, you should delete any previously scheduled scaling actions that you no longer need by accessing the consoles they were created from. AWS Auto Scaling does not create a predictive scaling action that overlaps an existing scheduled scaling action.

  • Your customized settings for minimum and maximum capacity, along with other settings used for dynamic scaling, show up in other consoles. However, we recommend that after you create a scaling plan, you do not modify these settings from other consoles because your scaling plan does not receive the updates from other consoles.

  • Your scaling plan can contain resources from multiple services, but each resource can be in only one scaling plan at a time.

On this page: