AWS autoscaling documentation change
Summary
Updated references from 'Auto Scaling' to 'Amazon EC2 Auto Scaling' for product name consistency across documentation links and terminology
Security assessment
The changes are purely branding/naming convention updates to ensure proper product terminology. No security-related content was added or modified. The updates focus on clarifying service names in documentation links and group references without introducing security features or addressing vulnerabilities.
Diff
diff --git a/autoscaling/plans/userguide/best-practices-for-scaling-plans.md b/autoscaling/plans/userguide/best-practices-for-scaling-plans.md index d2a324211..275e42580 100644 --- a//autoscaling/plans/userguide/best-practices-for-scaling-plans.md +++ b//autoscaling/plans/userguide/best-practices-for-scaling-plans.md @@ -11 +11 @@ The following best practices can help you make the most of scaling plans: - * When you create a launch template or launch configuration, enable detailed monitoring to get CloudWatch metric data for EC2 instances at a one-minute frequency because that ensures a faster response to load changes. Scaling on metrics with a five-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 five-minute intervals. For an additional charge, you can enable detailed monitoring to get metric data for instances at a one-minute frequency. For more information, see [Configure monitoring for Auto Scaling instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/enable-as-instance-metrics.html) in the _Amazon EC2 Auto Scaling User Guide_. + * When you create a launch template or launch configuration, enable detailed monitoring to get CloudWatch metric data for EC2 instances at a one-minute frequency because that ensures a faster response to load changes. Scaling on metrics with a five-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 five-minute intervals. For an additional charge, you can enable detailed monitoring to get metric data for instances at a one-minute frequency. For more information, see [Configure monitoring for Amazon EC2 Auto Scaling instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/enable-as-instance-metrics.html) in the _Amazon EC2 Auto Scaling User Guide_. @@ -13 +13 @@ The following best practices can help you make the most of scaling plans: - * 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. For more information, see [Monitoring CloudWatch metrics for your Auto Scaling groups and instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-cloudwatch-monitoring.html) in the _Amazon EC2 Auto Scaling User Guide_. + * We also recommend that you enable Amazon EC2 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. For more information, see [Monitoring CloudWatch metrics for your Amazon EC2 Auto Scaling groups and instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-cloudwatch-monitoring.html) in the _Amazon EC2 Auto Scaling User Guide_. @@ -15 +15 @@ The following best practices can help you make the most of scaling plans: - * Check which instance type your Auto Scaling group uses and be wary of using a burstable performance instance type. Amazon EC2 instances with burstable performance, such as 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html). To configure these instances as `unlimited`, see [Using an Auto Scaling group to launch a burstable performance instance as Unlimited](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-how-to.html#burstable-performance-instances-auto-scaling-grp) in the _Amazon EC2 User Guide_. + * Check which instance type your Amazon EC2 Auto Scaling group uses and be wary of using a burstable performance instance type. Amazon EC2 instances with burstable performance, such as 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html). To configure these instances as `unlimited`, see [Using an Auto Scaling group to launch a burstable performance instance as Unlimited](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-how-to.html#burstable-performance-instances-auto-scaling-grp) in the _Amazon EC2 User Guide_. @@ -24 +24 @@ The following best practices can help you make the most of scaling plans: -If you use scaling plans only for predictive scaling, we strongly recommend that you set predictive scaling policies directly on your Auto Scaling resources instead. This option offers more features, such as using metrics aggregations to create new custom metrics or retain historical metric data across blue/green deployments. For more information about Amazon EC2 Auto Scaling, see [Predictive scaling for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html) in the _Amazon EC2 Auto Scaling User Guide_. For more information about Application Auto Scaling, see [Predictive scaling for Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-predictive-scaling.html) in the _Application Auto Scaling User Guide_. +If you use scaling plans only for predictive scaling, we strongly recommend that you set predictive scaling policies directly on your Amazon EC2 Auto Scaling resources instead. This option offers more features, such as using metrics aggregations to create new custom metrics or retain historical metric data across blue/green deployments. For more information about Amazon EC2 Auto Scaling, see [Predictive scaling for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html) in the _Amazon EC2 Auto Scaling User Guide_. For more information about Application Auto Scaling, see [Predictive scaling for Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-predictive-scaling.html) in the _Application Auto Scaling User Guide_. @@ -32 +32 @@ Keep the following additional considerations in mind: - * 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. + * 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 Amazon EC2 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. @@ -47 +47 @@ An "ActiveWithProblems" error can occur when a scaling plan is created, or resou -Usually, this happens because a resource already has a scaling policy or an Auto Scaling group does not meet the minimum requirements for predictive scaling. +Usually, this happens because a resource already has a scaling policy or an Amazon EC2 Auto Scaling group does not meet the minimum requirements for predictive scaling. @@ -51 +51 @@ If any of your resources already have scaling policies from various service cons -With predictive scaling, 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, then the scaling plan can't generate a forecast until the next forecast period, after the group has collected the required amount of data. However, you can also edit and save the scaling plan to restart the forecast process as soon as the 24 hours of data is available. +With predictive scaling, we recommend waiting 24 hours after creating a new Amazon EC2 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, then the scaling plan can't generate a forecast until the next forecast period, after the group has collected the required amount of data. However, you can also edit and save the scaling plan to restart the forecast process as soon as the 24 hours of data is available.