本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# Amazon EC2 Auto Scaling 的动态扩缩
动态扩缩会根据流量的变化扩展自动扩缩组的容量。
Amazon EC2 Auto Scaling 支持以下类型的动态扩缩策略：
+ **目标跟踪扩展**-根据 Amazon CloudWatch 指标和目标值增加和减少群组的当前容量。这与温控器保持家里温度的方式类似——您只需选择一个温度，剩余的工作将由温控器完成。
+ **Step scaling**（步进分步）– 通过一系列扩缩调整（也称*步进调整*）来增加和减少组的当前容量，具体调整因警报严重程度而异。
+ **Simple scaling**（简单扩缩）– 通过单次扩缩调整来增加和减少组的当前容量，每次扩缩活动之间有一个冷却时间。
强烈建议您使用目标跟踪扩缩策略，并选择一个与自动扩缩组容量变化成反比的指标。因此，如果将自动扩缩组的大小增加一倍，则该指标将降低 50%。这使指标数据能够准确触发按比例扩缩事件。其中包括平均 CPU 利用率或每个目标的平均请求数等指标。
使用目标跟踪时，自动扩缩组会根据应用程序的实际负载按比例扩缩。这意味着，除根据负载变化满足当前容量需求外，目标跟踪策略还可以适应持续的负载变化，例如由于季节性变化而导致的负载变化。
目标跟踪策略还无需手动定义 CloudWatch 警报和缩放调整。Amazon EC2 Auto Scaling 会根据您设置的目标自动处理此问题。
**Topics**
+ [
## 动态扩缩策略的工作方式
](#as-how-scaling-policies-work)
+ [
## 多个动态扩缩策略
](#multiple-scaling-policy-resolution)
+ [
# Amazon EC2 Auto Scaling 的目标跟踪扩缩策略
](as-scaling-target-tracking.md)
+ [
# 有关更多信息，请参阅 Amazon EC2 Auto Scaling 的步进和简单扩展策略
](as-scaling-simple-step.md)
+ [
# Amazon EC2 Auto Scaling 的缩放冷却时间
](ec2-auto-scaling-scaling-cooldowns.md)
+ [
# 基于 Amazon SQS 的扩缩策略
](as-using-sqs-queue.md)
+ [
# 验证 Auto Scaling 组的扩缩活动
](as-verify-scaling-activity.md)
+ [
# 禁用 Auto Scaling 组的扩缩策略
](as-enable-disable-scaling-policy.md)
+ [
# 删除自动扩缩组的扩缩策略
](deleting-scaling-policy.md)
+ [
# 的扩展策略示例 AWS CLI
](examples-scaling-policies.md)
## 动态扩缩策略的工作方式
动态扩展策略指示 Amazon EC2 Auto Scaling 跟踪特定 CloudWatch 指标，并定义当相关 CloudWatch 警报处于警报状态时要采取的操作。用于调用警报状态的指标是来自自动扩缩组中所有实例的指标聚合。（例如，假设您有一个 Auto Scaling 组，其中有两个实例，一个实例的 CPU 利用率为 60%，另一个实例的 CPU 利用率为 40%。CPU 平均利用率为 50%。） 策略生效后，在超过警报的阈值时，Amazon EC2 Auto Scaling 向上或向下调整组的所需容量。
如果调用动态扩缩策略，容量计算生成的数字超出了组的最小和最大大小范围，则 Amazon EC2 Auto Scaling 确保新容量永远不会超出最小和最大大小限制。容量通过以下两种方式衡量：使用您在以实例数设置所需容量时选择的相同单位；或者使用容量单位（如果应用了[实例权重](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)）。
+ 示例 1：Auto Scaling 组的最大容量为 3，当前容量为 2，并有增加 3 个实例的动态扩缩策略。调用此策略后，Amazon EC2 Auto Scaling 仅向组添加 1 个实例，以防止组超出其最大大小。
+ 示例 2：Auto Scaling 组的最小容量为 2，当前容量为 3，并有移除 2 个实例的动态扩缩策略。调用执行此策略后，Amazon EC2 Auto Scaling 仅从组中移除 1 个实例，以防止组小于其最小大小。
当所需容量达到最大大小限制时，向外扩展停止。如果需求下降并且容量下降，则 Amazon EC2 Auto Scaling 会再次扩展。
但使用实例权重时例外。在这种情况下，Amazon EC2 Auto Scaling 可以扩展超过最大大小限制，但上限为您的最大实例权重。其目的是尽可能接近新的所需容量，但仍然遵循为该组指定的分配战略。分配策略决定要启动的实例类型。权重根据实例类型确定每个实例向所需的组容量贡献的容量单位数。
+ 示例 3：Auto Scaling 组的最大容量为 12，当前容量为 10，并有增加 5 个容量单位的动态扩缩策略。向实例类型分配三个权重之一：1、4 或 6。调用策略后，Amazon EC2 Auto Scaling 根据分配策略，选择启动权重为 6 的实例类型。此横向扩展事件的结果是得到所需容量为 12、当前容量为 16 的组。
## 多个动态扩缩策略
在大多数情况下，目标跟踪扩缩策略就足以将您的 Auto Scaling 组配置为自动扩展和缩减。目标跟踪扩缩策略允许您选择所需结果，并让 Auto Scaling 组根据需要添加和删除实例以实现该结果。
对于高级扩缩配置，您的 Auto Scaling 组可以有多个扩缩策略。例如，您可以定义一个或多个目标跟踪扩展策略，一个或多个步进扩展策略，或者同时使用两种策略。这样可以更灵活地覆盖多种场景。
为了说明多个扩缩策略如何协同工作，请设想一个应用程序，它使用一个 Auto Scaling 组和 Amazon SQS 队列将请求发送到单个 EC2 实例。为了帮助确保应用程序性能达到最佳级别，有两个策略用于控制何时扩缩 Auto Scaling 组。一个是使用自定义指标、根据队列中的 SQS 消息数增加和移除容量的目标跟踪策略。另一种是分步扩展策略，当实例在指定时间长 CloudWatch `CPUUtilization`度内超过 90% 的使用率时，该策略使用 Amazon 指标来增加容量。
如果同时实施多个策略，各个策略可能会同时指示 Auto Scaling 组扩展（或缩减）。例如，在 SQS 自定义`CPUUtilization`指标达到峰值并突破自定义指标 CloudWatch 警报阈值的同时，指标可能会达到峰值并突破警报的阈值。
如果发生上述情况，Amazon EC2 Auto Scaling 会选择在扩展和缩减时都提供最大容量的策略。例如，假定 `CPUUtilization` 策略启动一个实例，而 SQS 队列的策略启动两个实例。如果同时满足两个策略的扩展条件，Amazon EC2 Auto Scaling 优先选择 SQS 队列策略。这会导致 Auto Scaling 组启动两个实例。
即使策略使用不同的扩展条件，使提供最大容量的策略具有优先级的方法也适用。例如，如果一个策略终止三个实例，另一个策略将实例数量减少 25%，且在缩减时组中有八个实例，则 Amazon EC2 Auto Scaling 会优先考虑为组提供最大数量实例的策略。这会导致 Auto Scaling 组终止两个实例（8 X 25% = 2）。目的是防止 Amazon EC2 Auto Scaling 删除过多实例。
不过，在将目标跟踪扩展策略与步进扩展策略结合使用时，我们建议您务必谨慎，因为这些策略之间的冲突可能会导致意外的行为。例如，如果步进扩缩策略在目标跟踪策略准备执行横向缩减之前启动横向缩减活动，则不会阻止横向缩减活动。在横向缩减活动完成后，目标跟踪策略可能会指示组重新横向扩展。
# Amazon EC2 Auto Scaling 的目标跟踪扩缩策略
目标跟踪扩缩策略根据目标指标值自动扩缩自动扩缩组的容量。可自动适应各个应用程序的独特使用模式。这使您的应用程序无需人工干预即可保持最佳性能，并保持 EC2 实例高使用率以提高成本效益。
通过目标跟踪，您可以选择一个指标和一个目标值，目标值用来表示应用程序的理想平均利用率或吞吐量水平。Amazon EC2 Auto Scaling 创建并管理在指标偏离目标时调用扩展事件的 CloudWatch 警报。举例来说，这与恒温器保持目标温度的方式类似。
例如，假设您当前有一个在两个实例上运行的 Web 应用程序，并希望在应用程序负载变化时将自动扩缩组的 CPU 利用率保持在 50% 左右。这为您提供额外容量以处理流量高峰，而无需维护过多的空闲资源。
创建一个将目标平均 CPU 利用率设置为 50% 的目标跟踪扩缩策略即可满足此需求。然后，当 CPU 使用率超过 50% 时，自动扩缩组将横向扩展或增加容量，以处理增加的负载。当 CPU 利用率降至 50% 以下时，该组将横向缩减或减少容量，以便在利用率低的时期优化成本。
**Topics**
+ [
## 多个目标跟踪扩缩策略
](#target-tracking-multiple-policies)
+ [
## 选择指标
](#target-tracking-choose-metrics)
+ [
## 定义目标值
](#target-tracking-define-target-value)
+ [
## 定义实例预热时间
](#as-target-tracking-scaling-warmup)
+ [
## 注意事项
](#target-tracking-considerations)
+ [
# 创建目标跟踪扩缩策略
](policy_creating.md)
+ [
# 使用高精度指标创建目标跟踪策略以加快响应速度
](policy-creating-high-resolution-metrics.md)
+ [
# 使用指标数学创建目标跟踪扩缩策略
](ec2-auto-scaling-target-tracking-metric-math.md)
## 多个目标跟踪扩缩策略
为帮助优化扩缩性能，您可以将多个目标跟踪扩缩策略组合使用，但前提是其中的每个策略都各自使用不同的指标。例如，利用率和吞吐量可能会相互影响。每当其中一个指标发生变化时，通常意味着其他指标也将受到影响。因此，使用多个指标可以提供有关自动扩缩组所承担负载的额外信息。这可以帮助 Amazon EC2 Auto Scaling 在确定要向组中添加多少容量时做出更明智的决策。
Amazon EC2 Auto Scaling 的目的是始终优先考虑可用性。如果任何目标跟踪策略已准备好横向扩展，则它将横向扩展自动扩缩组。仅在所有目标跟踪策略（已启用横向缩减部分）都准备好横向缩减时，才会进行横向缩减。
## 选择指标
您可以使用预定义的指标或自定义指标，创建目标跟踪扩展策略。预定义指标可让您更轻松地访问最常用的扩缩指标。自定义指标允许您根据其他可用 CloudWatch 指标进行扩展，包括以更精细的间隔发布[的高分辨率指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Resolution_definition)，这些指标在几秒钟左右的时间间隔内发布。您可以发布自有的高精度指标，也可以发布其他 AWS 服务发布的指标。
有关使用高精度指标创建目标跟踪策略的更多信息，请参阅[使用高精度指标创建目标跟踪策略以加快响应速度](policy-creating-high-resolution-metrics.md)。
目标跟踪支持以下预定义的指标：
+ `ASGAverageCPUUtilization`—Auto Scaling 组的平均 CPU 利用率。
+ `ASGAverageNetworkIn`—Auto Scaling 组在所有网络接口上收到的平均字节数。
+ `ASGAverageNetworkOut`—Auto Scaling 组在所有网络接口上发送的平均字节数。
+ `ALBRequestCountPerTarget` — Auto Scaling 组的每个目标的平均 Application Load Balancer 请求计数。
**重要**
有关 CPU 利用率、网络 I/O 和每个目标的 Application Load *Balancer 请求数等[ CloudWatch 指标的其他有价值的信息，可分别在 *Amazon EC2 用户指南*中的列出您的实例的可用CloudWatch ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html)[指标主题和应用程序负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)用户指南中的应用程序负载均衡*器指标主题中找到。
您可以 CloudWatch 通过指定自定义 CloudWatch 指标来选择其他可用指标或您自己的指标。有关使用为目标跟踪扩展策略指定自定义指标规范的示例 AWS CLI，请参阅[的扩展策略示例 AWS CLI](examples-scaling-policies.md)。
选择指标时请记住原则：
+ 我们建议您仅使用每隔一分钟或更短时间可用的指标，以帮助您更快地扩展以响应利用率变化。借助以较小间隔发布的指标，目标跟踪策略可检测自动扩缩组利用率的变化并更快地进行响应。
+ 如果选择 Amazon EC2 发布的预定义指标，例如 CPU 利用率，我们建议启用详细监控。默认情况下，所有 Amazon EC2 指标都以五分钟为间隔发布，但可以通过启用详细监控，配置为更短间隔（每隔一分钟）。有关如何启用详细监控的信息，请参阅[配置 Auto Scaling 实例的监控](enable-as-instance-metrics.md)。
+ 并非所有自定义指标都适用于目标跟踪。指标必须是有效的使用率指标，它用于描述实例的繁忙程度。指标值必须随着 Auto Scaling 组中的实例数按比例增加或减少。这样，指标数据可用于随实例数量按比例扩展或缩减。例如，如果某个 Auto Scaling 组的负载分布在各个实例上，则该 Auto Scaling 组的 CPU 使用率指标（即指标维度为 `AutoScalingGroupName` 的 Amazon EC2 指标 `CPUUtilization`）能够正常工作。
+ 以下指标不适用于目标跟踪：
+ Auto Scaling 组前面的负载均衡器收到的请求数（即，Elastic Load Balancing 指标 `RequestCount`）。负载均衡器收到的请求数不会根据 Auto Scaling 组的使用率而发生变化。
+ 负载均衡器请求延迟（即，Elastic Load Balancing 指标 `Latency`）。请求延迟可能会根据使用率增加而增加，但不一定按比例变化。
+ CloudWatch 亚马逊 SQS 队列指标。`ApproximateNumberOfMessagesVisible`队列中的消息数可能不会随着处理队列中的消息的 Auto Scaling 组的大小按比例发生变化。但是，用于测量消息数（自动扩缩组的每个 EC2 实例的队列中）的自定义指标能够正常工作。有关更多信息，请参阅 [基于 Amazon SQS 的扩缩策略](as-using-sqs-queue.md)。
+ 要使用 `ALBRequestCountPerTarget` 指标，您必须指定 `ResourceLabel` 参数以标识与该指标关联的负载均衡器目标组。有关使用为目标跟踪扩展策略指定`ResourceLabel`参数的示例 AWS CLI，请参阅[的扩展策略示例 AWS CLI](examples-scaling-policies.md)。
+ 当某个指标向 CloudWatch （例如`ALBRequestCountPerTarget`）发出实数 0 值时，当您的应用程序持续一段时间内没有流量时，Auto Scaling 组可以缩减到 0。要在没有请求路由时将自动扩缩组横向缩减至 0，组的最小容量必须设置为 0。
+ 您可以使用指标数学组合现有指标，而不必发布要在扩缩策略中使用的新指标。有关更多信息，请参阅 [使用指标数学创建目标跟踪扩缩策略](ec2-auto-scaling-target-tracking-metric-math.md)。
## 定义目标值
创建目标跟踪扩缩策略时，必须指定一个目标值。目标值表示自动扩缩组的最佳平均利用率或吞吐量。为了经济高效地使用资源，目标值的设置应尽可能高，并为流量的意外增加提供合的理缓冲。当应用程序针对正常流量进行最佳横向扩展时，实际指标值应等于或略低于目标值。
当扩缩策略基于吞吐量（例如，每目标的应用程序负载均衡器请求计数、网络 I/O 或其他计数指标）时，目标值表示单个实例在一分钟内的最佳平均吞吐量。
## 定义实例预热时间
您可以指定新启动实例的预热时间（单位为秒）。在指定的预热时间过期前，实例不会计入自动扩缩组的聚合 EC2 实例指标。
当实例处于预热时间时，仅当未预热实例的指标值大于策略的目标利用率时，您的扩缩策略才会横向扩展。
如果组再次横向扩展，则仍在预热的实例将计算为下一横向扩展活动所需容量的一部分。旨在持续 (但不过度) 扩大。
当横向扩展活动正在进行时，通过扩缩策略启动的所有横向缩减活动都将被阻止，直到实例完成预热。当实例完成预热后，如果发生横向缩减事件，那么在计算新的所需容量时，当前正在终止的任何实例都将计入该组的当前容量。因此不会从 Auto Scaling 组中删除更多实例。
**默认 值**
如果未设置任何值，则扩缩策略将使用默认值，即为该组定义的[默认实例预热](ec2-auto-scaling-default-instance-warmup.md)值。如果默认实例预热为空，则将回退到[默认冷却时间](ec2-auto-scaling-scaling-cooldowns.md#set-default-cooldown)值。建议使用默认实例预热，以便在预热时间发生变化时更轻松地更新所有扩缩策略。
## 注意事项
使用目标跟踪扩缩策略时，需要注意以下事项：
+ 请勿创建、编辑或删除与目标跟踪扩展策略一起使用的 CloudWatch 警报。Amazon EC2 Auto Scaling 创建和管理与您的目标跟踪扩展策略关联的 CloudWatch警报，并且可以在必要时对其进行编辑、替换或删除，以便为您的应用程序及其不断变化的利用模式自定义扩展体验。
+ 在流量波动时，目标跟踪扩缩策略会优先考虑可用性，在流量减少时以更缓步的方式横向缩减。若想获得更大的控制权，步进扩缩策略可能是一种更好的选择。您可以临时禁用目标跟踪策略的横向缩减部分。这有助于保持成功部署所需的最小实例数量。
+ 如果指标缺少数据点，则会导致 CloudWatch 警报状态更改为`INSUFFICIENT_DATA`。发生这种情况时，在找到新的数据点之前，Amazon EC2 Auto Scaling 无法扩展您的组。
+ 如果设计为很少报告指标，则指标数学可能会很有帮助。例如，要使用最新的值，则使用 `FILL(m1,REPEAT)` 函数，其中 `m1` 是指标。
+ 您可能会看到目标值与实际指标数据点之间存在差距。这是因为我们在确定需要添加或删除多少个实例时通过向上或向下取整来保守地进行操作，以免添加的实例数量不足或删除的实例数量过多。但是，对于实例较少的 Auto Scaling 组，组的使用率可能偏离目标值较远。
例如，假设您将 CPU 使用率的目标值设置为 50%，然后自动扩缩组超过了该目标。我们可以确定，添加 1.5 个实例会将 CPU 使用率降低到接近 50%。由于不可能添加 1.5 个实例，我们将该值向上取整，添加两个实例。这可能会将 CPU 使用率降至 50% 以下，但可确保应用程序具有充足的支持资源。类似地，如果我们确定移除 0.5 个实例可将 CPU 利用率提高到 50% 以上，那么在指标降低到我们认为横向缩减不会导致振荡之前，我们不会选择进行横向缩减。
对于包含更多实例的更大 Auto Scaling 组，使用率分布在更多实例上，在这种情况下，添加或删除实例会导致目标值与实际指标数据点之间的差距缩小。
+ 目标跟踪扩缩策略假设它应该在指定指标高于目标值时扩展 Auto Scaling 组。在指定指标低于目标值时，不能使用目标跟踪扩缩策略来横向扩展自动扩缩组。
# 创建目标跟踪扩缩策略
要为自动扩缩组创建目标跟踪扩缩策略，请使用以下方法之一。
在开始操作之前，请确认您的首选指标每隔 1 分钟可用（而 Amazon EC2 指标的默认间隔为 5 分钟）。
------
#### [ Console ]
**为新的自动扩缩组创建目标跟踪扩展策略**
1. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
1. 选择 **Create Auto Scaling group**（创建 Auto Scaling 组）。
1. 在步骤 1、2 和 3 中，根据需要选择选项，然后继续**步骤 4：配置组大小和扩缩策略**。
1. 在**扩缩**下，通过更新**最小容量**和**最大容量**来指定您想要在其间扩缩的范围。这两个设置允许您的 Auto Scaling 组动态扩缩。有关更多信息，请参阅 [为自动扩缩组设置扩缩限制](asg-capacity-limits.md)。
1. 在**自动扩缩**下，选择**目标跟踪扩缩策略**。
1. 要定义策略，请执行以下操作：
1. 指定策略的名称。
1. 对于 **Metric type**（指标类型）， 选择一个指标。
如果您选择了**每个目标的 Application Load Balancer 请求计数**，请在**目标组**中选择目标组。
1. 为指标指定 **Target value**（目标值）。
1. （可选）对于**实例预热**，请根据需要更新实例预热值。
1. （可选）选择 **Disable scale in to create only a scale-out policy**（禁用缩减以创建仅扩展策略）。这样，可以根据需要创建独立的其他类型的缩减策略。
1. 继续创建 Auto Scaling 组。您的扩展策略将在创建 Auto Scaling 组后创建。
**为现有 Auto Scaling 组创建目标跟踪扩展策略**
1. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
1. 选中您的自动扩缩组旁边的复选框。
这时将在页面底部打开一个拆分窗格。
1. 验证是否正确设置了扩缩限制。例如，如果您的组所需的容量已经是最大，则指定一个新的最大值才能向外扩展。有关更多信息，请参阅 [为自动扩缩组设置扩缩限制](asg-capacity-limits.md)。
1. 在 **Automatic scaling**（自动扩展）选项卡的 **Dynamic scaling policies**（动态扩展策略）中，选择 **Create dynamic scaling policy**（创建动态扩展策略）。
1. 要定义策略，请执行以下操作：
1. 对于 **策略类型**，保留默认的 **目标跟踪扩展**。
1. 指定策略的名称。
1. 对于 **Metric type**（指标类型）， 选择一个指标。您只能选择一种指标类型。要使用多个指标，请创建多个策略。
如果您选择了**每个目标的 Application Load Balancer 请求计数**，请在**目标组**中选择目标组。
1. 为指标指定 **Target value**（目标值）。
1. （可选）对于**实例预热**，请根据需要更新实例预热值。
1. （可选）选择 **Disable scale in to create only a scale-out policy**（禁用缩减以创建仅扩展策略）。这样，可以根据需要创建独立的其他类型的缩减策略。
1. 选择**创建**。
------
#### [ AWS CLI ]
要创建目标跟踪扩缩策略，可以使用以下示例来帮助您开始。将每个 *user input placeholder* 替换为您自己的信息。
**注意**
有关更多示例，请参阅[的扩展策略示例 AWS CLI](examples-scaling-policies.md)。
**创建目标跟踪扩缩策略（AWS CLI）**
1. 使用以下 `cat` 命令可以在您主目录的名为 `config.json` 的 JSON 文件中存储扩缩策略的目标值和预定义指标规范。以下是将 CPU 平均使用率保持在 50% 的示例目标跟踪配置。
```
$ cat ~/config.json
{
"TargetValue": 50.0,
"PredefinedMetricSpecification":
{
"PredefinedMetricType": "ASGAverageCPUUtilization"
}
}
```
有关更多信息，请参阅[PredefinedMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredefinedMetricSpecification.html)《*亚马逊 EC2 Auto Scaling API 参考*》。
1. 使用 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 命令以及在前面的步骤中创建的 `config.json` 文件创建扩展策略。
```
aws autoscaling put-scaling-policy --policy-name cpu50-target-tracking-scaling-policy \
--auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
--target-tracking-configuration file://config.json
```
如果成功，此命令将返回代表您创建的两个 CloudWatch 警报的 ARNs 和名称。
```
{
"PolicyARN": "arn:aws:autoscaling:us-west-2:123456789012:scalingPolicy:228f02c2-c665-4bfd-aaac-8b04080bea3c:autoScalingGroupName/my-asg:policyName/cpu50-target-tracking-scaling-policy",
"Alarms": [
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e",
"AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e"
},
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2",
"AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2"
}
]
}
```
------
# 使用高精度指标创建目标跟踪策略以加快响应速度
目标跟踪支持具有秒级数据点的高分辨率 CloudWatch 指标，这些数据点的发布间隔小于一分钟。配置目标跟踪策略，通过高分辨率 CloudWatch 指标监控需求模式不稳定的应用程序的利用率，例如客户服务 API、直播服务、电子商务网站和按需数据处理。为提高容量和需求的匹配精度，目标跟踪使用这种细粒度监控来更快地检测和响应 EC2 实例不断变化的需求和利用率。
有关如何以高分辨率发布指标的更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。要访问和发布 EC2 指标，例如高分辨率下的 CPU 利用率，您可能需要使用[CloudWatch 代理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)。
## AWS 区域
使用高分辨率指标的目标跟踪功能适用于 AWS 区域 除外 AWS GovCloud (US) Regions。
## 使用高精度指标的目标跟踪策略的工作原理
可通过定义要跟踪的指标以及该指标需要保持的目标值来创建目标跟踪策略。要根据高精度指标进行扩缩，需指定指标的名称，并将目标跟踪对该指标的观察周期设置为一个小于 60 秒的值。目前支持的最小间隔为 10 秒钟。您可以在更短的间隔内发布指标。
**注意**
不支持超过 60 秒的指标周期。
您可以对单个 CloudWatch 指标配置目标跟踪，也可以查询多个 CloudWatch 指标，并使用数学表达式根据这些指标创建新的单个时间序列。这两个选项都支持定义指标周期。
## 示例
**示例 1**
以下示例基于高分辨率 CloudWatch 指标创建目标跟踪策略。该指标以 10 秒级精度发布。您可以通过定义指标周期来启用目标跟踪，从而以 10 秒级粒度监控该指标。将每个 *user input placeholder* 替换为您自己的信息。
```
$ cat ~/config.json
{
"TargetValue": 100.0,
"CustomizedMetricSpecification": {
"MetricName": "MyHighResolutionMetric",
"Namespace": "MyNamespace",
"Dimensions": [
{
"Name": "MyOptionalDimensionName",
"Value": "MyOptionalMetricDimensionValue"
}
],
"Statistic": "Average",
"Unit": "None"
"Period": "10
}
}
```
**示例 2**
可使用指标的数学表达式将多个指标组合成单个时间序列以进行扩缩。指标数学对于将现有指标换算成单个实例的平均值特别有用。指标换算非常重要，因为目标跟踪假设该指标与自动扩缩组的容量成反比。因此，当容量增加时，该指标应以几乎相同的比例减小。
例如，假设您有一个指标代表应用程序要处理的待处理任务。您可以使用指标数学将待处理任务数除以自动扩缩组的运行容量。Auto Scaling 以 1 分钟的粒度发布容量指标，因此该指标在小于一分钟的间隔内不会有任何值。如果想使用更高的精度进行扩缩，这可能会导致容量与待处理任务指标之间出现周期不匹配。为避免出现这种不匹配，我们建议使用 FILL 表达式，用前一分钟时间戳中记录的容量数字填充缺失值。
以下示例使用指标数学，将待处理任务指标除以容量。对于周期，我们将两个指标的周期都设置为 10 秒。由于指标按 1 分钟的间隔发布，因此我们对容量指标使用 FILL 操作。
使用指标数学修改多个指标
```
{
"CustomizedMetricSpecification": {
"Metrics": [
{
"Label": "Pending jobs to be processed",
"Id": "m1",
"MetricStat": {
"Metric": {
"MetricName": "MyPendingJobsMetric",
"Namespace": "Custom",
},
"Stat": "Sum"
"Period": 10
},
"ReturnData": false
},
{
"Label": "Get the running instance capacity (matching the period to that of the m1)",
"Id": "m2",
"MetricStat": {
"Metric": {
"MetricName": "GroupInServiceInstances",
"Namespace": "AWS/AutoScaling",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
}
]
},
"Stat": "Average"
"Period": 10
},
"ReturnData": false
},
{
"Label": "Calculate the pending job per capacity (note the use of the FILL expression)",
"Id": "e1",
"Expression": "m1 / FILL(m2,REPEAT)",
"ReturnData": true
}
]
},
"TargetValue": 100
}
```
## 注意事项
使用目标跟踪和高精度指标时，请注意以下事项。
+ 为确保不会丢失可能导致不想要的自动缩放结果的数据点，您的 CloudWatch 指标必须以与您指定的时间段相同或更高的分辨率发布。
+ 将目标值定义为要为 Auto Scaling 组保留的 per-instance-per-minute指标值。如果所用指标的值会根据指标的周期而倍增，则设置适当的目标值至关重要。例如，任何基于统计的指标，例如使用 SUM 统计的请求计数或待处理任务数，会随着所选的周期而有不同的指标值。您仍然应该假设目标是根据每分钟的平均值设定的。
+ 尽管使用 Amazon EC2 Auto Scaling 不收取任何额外费用，但您必须为诸如 Amazon EC2 实例、 CloudWatch 指标和 CloudWatch 警报之类的资源付费。在前面的示例中创建的高分辨率警报的价格与标准 CloudWatch 警报的价格不同。有关 CloudWatch 定价的更多信息，请参阅 [Amazon CloudWatch 定价](https://aws.amazon.com/cloudwatch/pricing/)。
+ 目标跟踪要求指标代表 EC2 实例的平均每实例使用率。为实现这一点，可以在目标跟踪策略配置中采用[指标数学运算](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)。将指标除以自动扩缩组的运行容量。确保用于创建单个时间序列的每个指标都定义了相同的指标周期。如果这些指标以不同间隔发布，则对间隔较大的指标使用 FILL 操作，以填充缺失的数据点。
# 使用指标数学创建目标跟踪扩缩策略
使用指标数学，您可以查询多个 CloudWatch 指标，并使用数学表达式根据这些指标创建新的时间序列。您可以在 CloudWatch 控制台中可视化生成的时间序列并将其添加到仪表板中。有关指标数学的更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[使用指标数学](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)。
以下考虑因素适用于指标数学表达式：
+ 您可以查询任何可用的 CloudWatch 指标。每个指标都是指标名称、命名空间和零个或多个维度的唯一组合。
+ 您可以使用任何算术运算符 (\$1-\$1/^)、统计函数（例如 AVG 或 SUM）或其他支持的函数。 CloudWatch
+ 您可以在数学表达式的公式中同时使用指标和其他数学表达式的结果。
+ 指标规范中使用的任何表达式最终都必须返回一个单个时间序列。
+ 您可以使用 CloudWatch 控制台或 CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)API 验证指标数学表达式是否有效。
## 示例：每个实例的 Amazon SQS 队列积压
要计算每个实例的 Amazon SQS caling 队列积压，请获取可用于从队列中检索的消息的大致数量，然后将该数字除以自动扩缩组的运行容量，该数字即为处于 `InService` 状态的实例数量。有关更多信息，请参阅 [基于 Amazon SQS 的扩缩策略](as-using-sqs-queue.md)。
表达式的逻辑如下：
`sum of (number of messages in the queue)/(number of InService instances)`
那么您的 CloudWatch 指标信息如下所示。
| ID | CloudWatch 指标 | Statistic | 周期 |
| --- | --- | --- | --- |
| m1 | ApproximateNumberOfMessagesVisible | Sum | 1 minute |
| m2 | GroupInServiceInstances | 平均值 | 1 minute |
您的指标数学 ID 和表达式如下所示。
| ID | Expression |
| --- | --- |
| e1 | (m1)/(m2) |
下图阐明了此指标的架构：
![\[Amazon EC2 Auto Scaling 使用队列架构图\]](http://docs.aws.amazon.com/zh_cn/autoscaling/ec2/userguide/images/sqs-as-custom-metric-diagram.png)
**使用该指标数学来创建目标跟踪扩展策略 (AWS CLI)**
1. 将指标数学表达式作为自定义指标规范的一部分存储在名为 `config.json` 的 JSON 文件中。
使用下面的示例帮助您快速开始。将每个 *user input placeholder* 替换为您自己的信息。
```
{
"CustomizedMetricSpecification": {
"Metrics": [
{
"Label": "Get the queue size (the number of messages waiting to be processed)",
"Id": "m1",
"MetricStat": {
"Metric": {
"MetricName": "ApproximateNumberOfMessagesVisible",
"Namespace": "AWS/SQS",
"Dimensions": [
{
"Name": "QueueName",
"Value": "my-queue"
}
]
},
"Stat": "Sum"
},
"ReturnData": false
},
{
"Label": "Get the group size (the number of InService instances)",
"Id": "m2",
"MetricStat": {
"Metric": {
"MetricName": "GroupInServiceInstances",
"Namespace": "AWS/AutoScaling",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
}
]
},
"Stat": "Average"
},
"ReturnData": false
},
{
"Label": "Calculate the backlog per instance",
"Id": "e1",
"Expression": "m1 / m2",
"ReturnData": true
}
]
},
"TargetValue": 100
}
```
有关更多信息，请参阅[TargetTrackingConfiguration](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TargetTrackingConfiguration.html)《*亚马逊 EC2 Auto Scaling API 参考*》。
**注意**
以下是一些其他资源，可以帮助您查找指标名称、命名空间、维度和指标 CloudWatch统计信息：
有关 AWS 服务的可用指标的信息，请参阅《*亚马逊 CloudWatch 用户指南*》中[发布 CloudWatch 指标的AWS 服务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html)。
要使用获取指标的确切指标名称、命名空间和维度（如果适用） AWS CLI，请参阅[列表 CloudWatch ](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/list-metrics.html)指标。
1. 要创建此策略，请使用 JSON 文件作为输入运行[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html)命令，如以下示例所示。
```
aws autoscaling put-scaling-policy --policy-name sqs-backlog-target-tracking-scaling-policy \
--auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
--target-tracking-configuration file://config.json
```
如果成功，此命令将返回策略的 Amazon 资源名称 (ARN) 和代表您创建 ARNs 的两个 CloudWatch 警报中的一个。
```
{
"PolicyARN": "arn:aws:autoscaling:us-west-2:123456789012:scalingPolicy:228f02c2-c665-4bfd-aaac-8b04080bea3c:autoScalingGroupName/my-asg:policyName/sqs-backlog-target-tracking-scaling-policy",
"Alarms": [
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e",
"AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e"
},
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2",
"AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2"
}
]
}
```
**注意**
如果此命令引发错误，请确保已将 AWS CLI 本地版本更新到最新版本。
# 有关更多信息，请参阅 Amazon EC2 Auto Scaling 的步进和简单扩展策略
分步扩展和简单扩展策略可根据 CloudWatch 警报以预定义的增量扩展 Auto Scaling 组的容量。您可以定义单独的扩缩策略，以便在超过警报阈值时处理横向扩展（增加容量）和横向缩减（减少容量）。
自动扩缩组容量是以实例数来计量的，如果采用[实例权重](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)，则以容量单位计量。此外，所需容量和当前容量之间也存在差异。
+ 所需容量：您想在组中拥有的实例数（或容量单位）。所需容量可以手动调整，也可以使用扩缩策略自动调整。
+ 当前容量：组中已完成预热和冷却，目前正在运行并准备投入使用的实例数（或容量单位）。
通过步进缩放和简单扩展，您可以创建和管理调用扩展过程的 CloudWatch 警报。当警报被触发时，Amazon EC2 Auto Scaling 会启动与该警报关联的扩缩策略。
强烈建议您使用目标跟踪扩缩策略，根据类似于平均 CPU 利用率或每个目标的平均请求数等指标进行扩展。使用目标跟踪，可以通过在容量增加时减少以及在容量减少时增加的指标，按比例扩展或缩减实例数。这有助于确保 Amazon EC2 Auto Scaling 密切遵循应用程序的需求曲线。有关更多信息，请参阅 [目标跟踪扩展策略](as-scaling-target-tracking.md)。
**Contents**
+ [
## 分步扩缩策略的工作原理
](#step-scaling-how-it-works)
+ [
## 步进扩展的分步调整
](#as-scaling-steps)
+ [
## 扩展调整类型
](#as-scaling-adjustment)
+ [
## 实例预热
](#as-step-scaling-warmup)
+ [
## 注意事项
](#step-scaling-considerations)
+ [
# 为横向扩展创建步进扩缩策略
](step-scaling-create-scale-out-policy.md)
+ [
# 为横向缩减创建步进扩缩策略
](step-scaling-create-scale-in-policy.md)
+ [
# 简单扩展策略
](simple-scaling-policies.md)
## 分步扩缩策略的工作原理
要使用步进缩放，您需要先创建一个 CloudWatch 警报，用于监控 Auto Scaling 组的指标。定义确定触发警报的指标、阈值和评估周期数。然后，创建步进扩缩策略，定义在突破警报阈值时如何扩缩您的组。对于扩缩调整类型，您可以使用自动扩缩组当前容量的百分比或容量单位。有关更多信息，请参阅 [扩展调整类型](#as-scaling-adjustment)。
在策略中添加分步调整。您可以根据警报的阈值突破大小定义不同的分步调整。例如：
+ 如果警报指标达到 60%，则横向扩展 10 个实例
+ 如果警报指标达到 75%，则横向扩展 30 个实例
+ 如果警报指标达到 85%，则横向扩展 40 个实例
当在指定的评估周期数内超过警报阈值时，Amazon EC2 Auto Scaling 将应用策略中定义的步进调整。针对其他警报触发情况，可以继续进行调整，直到警报状态恢复为 `OK`。
每个实例都有一个预热时间，以防止扩缩活动对短时间内发生的变化反应过快。您可以选择为扩缩策略配置预热时间。不过，建议使用默认实例预热，以便在预热时间发生变化时更轻松地更新所有扩缩策略。有关更多信息，请参阅 [为 Auto Scaling 组设置原定设置实例预热](ec2-auto-scaling-default-instance-warmup.md)。
简单扩缩策略与步进扩缩策略类似，不同之处在于这些策略基于单次扩缩调整，每次扩缩活动之间有一个冷却时间。有关更多信息，请参阅 [简单扩展策略](simple-scaling-policies.md)。
## 步进扩展的分步调整
在创建分步扩展策略时，您可以指定一个或多个步进调整，这些步进调整会根据警报违规的大小自动扩展实例数量。每个分步调整指定以下内容：
+ 指标值的下限
+ 指标值的上限
+ 要扩展的数量（基于扩展调整类型）
CloudWatch 根据与 CloudWatch 警报关联的指标的统计数据聚合指标数据点。超过警报时，将调用相应的扩缩策略。Amazon EC2 Auto Scaling 将聚合类型应用于来自的最新指标数据点 CloudWatch （而不是原始指标数据）。它将此聚合指标值与步进调整定义的上限和下限进行比较，以确定执行哪个步进调整。
您可以指定相对于违例阈值的上限和下限。例如，假设您针对指标高于 50% 时发出了 CloudWatch 警报并制定了扩展策略。然后，当指标低于 50% 时，又发出了另一个警报并采取横向缩减策略。对于每个策略，您可进行一组调整类型为 `PercentChangeInCapacity`（或控制台中的**组中占比**）的步进调整：
**示例：扩展策略的步进调整**
| **下限** | **上限** | **调整** |
| --- | --- | --- |
| 0 | 10 | 0 |
| 10 | 20 | 10 |
| 20 | null | 30 |
**示例：缩放策略的步进调整**
| **下限** | **上限** | **调整** |
| --- | --- | --- |
| -10 | 0 | 0 |
| -20 | -10 | -10 |
| null | -20 | -30 |
这将创建以下扩展配置。
```
Metric value
-infinity 30% 40% 60% 70% infinity
-----------------------------------------------------------------------
-30% | -10% | Unchanged | +10% | +30%
-----------------------------------------------------------------------
```
现在，假设您在当前容量和所需容量均为 10 的自动扩缩组上使用此扩缩配置。以下几点总结了扩展配置相对于组的所需容量和当前容量的行为：
+ 在聚合指标值大于 40 并小于 60 时，将保留所需容量和当前容量。
+ 如果指标值达到 60，根据扩展策略的第二个分步调整 (增加 10 个实例的 10%)，组的所需容量将增加 1 个实例，总共达到 11 个实例。在新实例运行并且其指定的预热时间过期后，当前组容量将增加到 11 个实例。如果指标值即使在这一容量增加之后也上升到 70，则组的所需容量将再增加 3 个实例，达到 14 个实例。这基于扩展策略的第三个步进调整（添加 11 个实例的 30%，即 3.3 个实例，向下舍入到 3 个实例）。
+ 如果指标值降到 40，根据缩减策略的第二个分步调整 (删除 14 个实例的 10%，向下取整为 1 个实例)，组的所需容量将减小 1 个实例，达到 13 个实例。如果指标值即使在这一容量减少之后也下降至 30，则组的所需容量将再减少 3 个实例，达到 10 个实例。这基于缩减策略的第三个步进调整（移除 13 个实例的 30%，即 3.9 个实例，向下舍入为 3 个实例）。
为扩展策略指定步进调整时，请注意以下事项：
+ 如果使用 AWS 管理控制台，则可以将上限和下限指定为绝对值。如果您使用 AWS CLI 或 SDK，则需要指定相对于违规阈值的上限和下限。
+ 分步调整范围不能重叠或有间隙。
+ 只有一个分步调整可以有空下限 (负无穷)。如果一个分步调整有负下限，则必须有一个分步调整有空下限。
+ 只有一个分步调整可以有空上限 (正无穷)。如果一个分步调整有正上限，则必须有一个分步调整有空上限。
+ 同一分步调整中的上限和下限不能为空。
+ 如果指标值高于违例阈值，则含下限而不含上限。如果指标值低于违例阈值，则不含下限而含上限。
## 扩展调整类型
您可以根据您选择的扩展调整类型来定义执行最佳扩展操作的扩展策略。您可以将调整类型指定为 Auto Scaling 组当前容量的百分比或以容量单位指定。通常，一个容量单位表示一个实例，除非您使用实例权重功能。
对于步进扩展和简单扩展，Amazon EC2 Auto Scaling 支持以下调整类型：
+ `ChangeInCapacity` — 将当前组容量增加或减少指定的值。正值将增加容量，负调整值将减小容量。例如：如果组的当前容量为 3，调整值为 5，那么当执行此策略时，我们会向容量添加 5 个容量单位，共计 8 个容量单位。
+ `ExactCapacity` — 将组的当前容量更改为指定值。为此调整类型指定一个非负值。例如：如果当前组容量为 3，调整值为 5，则当执行此策略时，我们会将容量更改为 5 个容量单位。
+ `PercentChangeInCapacity` — 将当前组容量增加或减少指定的百分比。正值将增加容量，负值将减少容量。例如：如果当前容量为 10，调整值为 10%，那么当执行此策略时，我们会向容量添加 1 个容量单位，总共 11 个容量单位。
**注意**
如果得出的值不是整数，将按如下所示进行取整：
大于 1 的值向下取整。例如，`12.7` 取整为 `12`。
0 和 1 之间的值舍入到 1。例如，`.67` 取整为 `1`。
0 和 -1 之间的值舍入到 -1。例如，`-.58` 取整为 `-1`。
小于 -1 的值向上取整。例如，`-6.67` 取整为 `-6`。
通过 `PercentChangeInCapacity`，您还可以使用 `MinAdjustmentMagnitude` 参数指定要扩展的最小实例。例如，假定您创建一个增加 25% 的策略，并且您指定最小增量为 2 个实例。如果您有一个 Auto Scaling 组包含 4 个实例，而要执行该扩展策略，则 4 的 25% 就是 1 个实例。但是，因为您指定了最小增量 2，则将添加 2 个实例。
使用[实例权重](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)时，将 `MinAdjustmentMagnitude` 参数设置为非零值的效果会发生变化。该值以容量单位为单位。如需设置所要扩展的最小实例数，请将此参数设置为至少与最大实例权重一样大的值。
如果您使用实例权重，请记住，自动扩缩组的当前容量可以根据需要超过所需容量。如果要递减的绝对数或百分比表示递减的数量小于当前容量和所需容量之间的差值，则不会执行任何扩展操作。在您查看超过警报阈值时扩缩策略的结果时，必须考虑这些行为。例如，假设所需容量为 30，当前容量为 32。超过警报时，如果扩缩策略将所需容量减少 1，则不会执行扩缩操作。
## 实例预热
对于扩缩步骤，您可以指定新启动实例的预热时间（单位为秒）。在指定的预热时间过期前，实例不会计入自动扩缩组的聚合 EC2 实例指标。
当实例处于预热时间，仅当未预热实例的指标值大于策略的警报阈值上限时，您的扩缩策略才会横向扩展。
如果组再次横向扩展，则仍在预热的实例将计算为下一横向扩展活动所需容量的一部分。因此，落入同一分步调整中的多个警报违例只会导致一个扩展活动。旨在持续 (但不过度) 扩大。
例如，假设您通过两个步骤创建策略。第一步，当指标达到 60 时，增加 10％；第二步，当指标达到70％时，增加 30％。自动扩缩组的所需容量和当前容量为 10。在聚合指标值小于 60 时，所需容量和当前容量不变。假设指标达到 60，因此添加 1 个实例（10 个实例中的 10%）。然后，在新实例仍在预热期间，指标达到 62。扩缩策略根据当前容量（仍为 10）计算新的所需容量。不过，组的所需容量已经增加至 11 个实例，因此，扩展策略不会进一步增加所需的容量。如果指标在新实例仍在预热时增长到 70，我们应添加 3 个实例（10 个实例的 30%）。但该组的所需容量已经是 11，所以我们只添加 2 个实例，因为新的所需容量为 13 个实例。
当横向扩展活动正在进行时，通过扩缩策略启动的所有横向缩减活动都将被阻止，直到实例完成预热。当实例完成预热后，如果发生横向缩减事件，那么在计算新的所需容量时，当前正在终止的任何实例都将计入该组的当前容量。因此不会从 Auto Scaling 组中删除更多实例。例如，当实例已经终止时，如果警报超出将所需容量减 1 的相同步进调整范围，则不会执行扩缩操作。
**默认 值**
如果未设置任何值，则扩缩策略将使用默认值，即为该组定义的[默认实例预热](ec2-auto-scaling-default-instance-warmup.md)值。如果默认实例预热为空，则将回退到[默认冷却时间](ec2-auto-scaling-scaling-cooldowns.md#set-default-cooldown)值。
## 注意事项
使用分步和简单扩缩策略时，需要注意以下事项：
+ 考虑是否可以足够准确地预测应用程序上的分步调整，以便使用分步扩缩。如果您的扩缩指标的升高或降低与可扩展目标的容量成比例，则建议您使用目标跟踪扩缩策略。您仍然可以选择使用步进扩展作为附加策略来实现更高级的配置。例如，您可以在利用率达到特定级别时配置更积极的响应。
+ 确保在横向扩展和横向缩减之间选择足够的余量，以防止摇摆。摆动是横向缩减和横向扩展的无限循环。也就是说，如果采取扩展操作，则指标值将更改并启动另一个相反方向的扩展操作。
# 为横向扩展创建步进扩缩策略
要为您的自动扩缩组创建横向扩展的步进扩缩策略，请使用以下方法之一：
------
#### [ Console ]
**步骤 1：为指标高阈值创建 CloudWatch 警报**
1. 打开 CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。
1. 如果需要，可以更改区域。从导航栏中，选择您的自动扩缩组所在的区域。
1. 在导航窗格中，选择 **Alarms, All alarms**（警报，所有警报），然后选择 **Create alarm**（创建警报）。
1. 选择**选择指标**。
1. 在 **All metrics**（所有指标）选项卡上，选择 **EC2**、**By Auto Scaling Group**（按 Auto Scaling 组），然后在搜索字段中输入 Auto Scaling 组的名称。然后，选择 `CPUUtilization` 并选择 **Select metric**（选择指标）。将显示 **Specify metric and conditions**（指定指标和条件）页面，其中显示一个图表以及有关指标的其他信息。
1. 在 **Period**（周期）下，选择警报的评估周期，例如 1 分钟。评估警报时，每个周期都聚合到一个数据点。
**注意**
周期越短，创建的警报越敏感。
1. 在 **Conditions**（条件）下，执行以下操作：
+ 对于 **Threshold type**（阈值类型），选择 **Static**（静态）。
+ 对于**每当 `CPUUtilization` 为**，请指定您是希望指标值大于还是大于等于阈值以触发警报。然后，在 **than**（大于/小于）下，输入您希望超过警报的阈值。
1. 在**其他配置**下，执行以下操作：
+ 对于 **Datapoints to alarm**（触发警报的数据点数），输入指标值必须满足阈值条件才会触发警报的数据点（评估时间段）数。例如，2 个连续的 5 分钟时间段需要花 10 分钟才会调用警报状态。
+ 对于 **Missing data treatment**（缺失数据处理），选择 **Treat missing data as bad (breaching threshold)**（将丢失的数据视为不良数据（违反阈值））。有关更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[配置 CloudWatch 警报如何处理丢失的数据](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)。
1. 选择**下一步**。
**Configure actions**（配置操作）页面会显示。
1. 在 **Notification**（通知）下面，选择一个在警报处于 `ALARM`、`OK` 或 `INSUFFICIENT_DATA` 状态时通知的 Amazon SNS 主题。
要使告警为相同告警状态或不同告警状态发送多个通知，请选择**添加通知**。
要让警报不发送通知，请选择**删除**。
1. 您可以保留 **Configure actions**（配置操作）页面的其他部分为空。将其他部分留空会创建警报，而不会将其与扩展策略相关联。然后，您可以从 Amazon EC2 Auto Scaling 控制台将警报与扩展策略关联。
1. 选择**下一步**。
1. 输入警报的名称（例如，`Step-Scaling-AlarmHigh-AddCapacity`）和可选的描述，然后选择 **Next**（下一步）。
1. 选择**创建警报**。
创建 CloudWatch 警报后，按照以下步骤继续从上次中断的地方继续。
**步骤 2：为横向扩展创建步进扩缩策略**
1. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
1. 选中您的自动扩缩组旁边的复选框。
这时将在页面底部打开一个拆分窗格。
1. 验证是否正确设置了扩缩限制。例如，如果您的组所需的容量已经是最大，则指定一个新的最大值才能向外扩展。有关更多信息，请参阅 [为自动扩缩组设置扩缩限制](asg-capacity-limits.md)。
1. 在 **Automatic scaling**（自动扩展）选项卡的 **Dynamic scaling policies**（动态扩展策略）中，选择 **Create dynamic scaling policy**（创建动态扩展策略）。
1. 对于**策略类型**，选择**步进扩展**，然后指定该策略的名称。
1. 要获得**CloudWatch 警报**，请选择您的闹钟。如果您尚未创建警报，请选择**创建警 CloudWatch 报，然后完成上一个**过程中的步骤 4 到步骤 14 以创建警报。
1. 指定在使用 **Take the action (执行操作)** 来完成操作时，此策略对当前组大小进行的更改。您可以添加特定数量的实例或现有组大小的百分比，也可将组设置为准确的大小。
例如，要创建将组容量增加 30% 的横向扩展策略，请选择 `Add`，在下一个字段中输入 `30`，然后选择 `percent of group`。默认情况下，此步骤调整的下限为警报阈值，上限为正 (\$1) 无穷。
1. 要添加另一个步骤，请选择 **Add step (添加步进)**，然后定义要缩放的量以及步进相对于警报阈值的下限和上限。
1. 要设置可扩展的最少实例数，请更新 **Add capacity units in increments of at least (添加容量单位的增量至少为)** `1` **capacity units (容量单位)** 中的数量字段。
1. （可选）对于**实例预热**，请根据需要更新实例预热值。
1. 选择**创建**。
------
#### [ AWS CLI ]
要创建横向扩展（增加容量）的步进扩缩策略，可以使用以下示例命令。将每个 *user input placeholder* 替换为您自己的信息。
使用时 AWS CLI，首先要创建分步扩展策略，该策略向 Amazon EC2 Auto Scaling 提供有关在指标值增加时如何扩展的说明。然后，通过确定要监控的指标、为警报定义指标的高阈值和其他详细信息，并将警报与扩缩策略关联，您可以创建警报。
**步骤 1：为横向扩展创建策略**
使用以下[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html)命令创建名为的分步扩展策略`my-step-scale-out-policy`，其调整类型为`PercentChangeInCapacity`，该策略可根据以下步骤调整来增加组的容量（假设 CloudWatch 警报阈值为 60%）：
+ 当指标值大于或等于 60% 但小于 75% 时，将实例计数增加 10%
+ 当指标值大于或等于 75% 但小于 85% 时，将实例计数增加 20%
+ 当指标值大于或等于 85% 时，将实例计数增加 30%
```
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name my-step-scale-out-policy \
--policy-type StepScaling \
--adjustment-type PercentChangeInCapacity \
--metric-aggregation-type Average \
--step-adjustments MetricIntervalLowerBound=0.0,MetricIntervalUpperBound=15.0,ScalingAdjustment=10 \
MetricIntervalLowerBound=15.0,MetricIntervalUpperBound=25.0,ScalingAdjustment=20 \
MetricIntervalLowerBound=25.0,ScalingAdjustment=30 \
--min-adjustment-magnitude 1
```
记下策略的 Amazon Resource Name (ARN)。您需要它来为策略创建 CloudWatch 警报。
```
{
"PolicyARN": "arn:aws:autoscaling:region:123456789012:scalingPolicy:4ee9e543-86b5-4121-b53b-aa4c23b5bbcc:autoScalingGroupName/my-asg:policyName/my-step-scale-in-policy
}
```
**步骤 2：为指标高阈值创建 CloudWatch 警报**
使用以下 CloudWatch [put-metric-alarm](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/put-metric-alarm.html)命令创建警报，根据平均 CPU 阈值增加 Auto Scaling 组的大小，至少连续两个评估期（两分钟）。要使用您自己的自定义指标，请在 `--metric-name` 中指定其名称，并在 `--namespace` 指定其命名空间。
```
aws cloudwatch put-metric-alarm --alarm-name Step-Scaling-AlarmHigh-AddCapacity \
--metric-name CPUUtilization --namespace AWS/EC2 --statistic Average \
--period 120 --evaluation-periods 2 --threshold 60 \
--comparison-operator GreaterThanOrEqualToThreshold \
--dimensions "Name=AutoScalingGroupName,Value=my-asg" \
--alarm-actions PolicyARN
```
------
# 为横向缩减创建步进扩缩策略
要为您的自动扩缩组创建横向缩减的步进扩缩策略，请使用以下方法之一：
------
#### [ Console ]
**步骤 1：为指标低阈值创建 CloudWatch 警报**
1. 打开 CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。
1. 如果需要，可以更改区域。从导航栏中，选择您的自动扩缩组所在的区域。
1. 在导航窗格中，选择 **Alarms, All alarms**（警报，所有警报），然后选择 **Create alarm**（创建警报）。
1. 选择**选择指标**。
1. 在 **All metrics**（所有指标）选项卡上，选择 **EC2**、**By Auto Scaling Group**（按 Auto Scaling 组），然后在搜索字段中输入 Auto Scaling 组的名称。然后，选择 `CPUUtilization` 并选择 **Select metric**（选择指标）。将显示 **Specify metric and conditions**（指定指标和条件）页面，其中显示一个图表以及有关指标的其他信息。
1. 在 **Period**（周期）下，选择警报的评估周期，例如 1 分钟。评估警报时，每个周期都聚合到一个数据点。
**注意**
周期越短，创建的警报越敏感。
1. 在 **Conditions**（条件）下，执行以下操作：
+ 对于 **Threshold type**（阈值类型），选择 **Static**（静态）。
+ 对于**每当 `CPUUtilization` 为**，请指定您是希望指标值小于还是小于等于阈值以触发警报。然后，在 **than**（大于/小于）下，输入您希望超过警报的阈值。
**重要**
要使警报与横向缩减策略（警报的低阈值）一起使用，请确保不要选择大于或大于等于阈值。
1. 在**其他配置**下，执行以下操作：
+ 对于 **Datapoints to alarm**（触发警报的数据点数），输入指标值必须满足阈值条件才会触发警报的数据点（评估时间段）数。例如，2 个连续的 5 分钟时间段需要花 10 分钟才会调用警报状态。
+ 对于 **Missing data treatment**（缺失数据处理），选择 **Treat missing data as bad (breaching threshold)**（将丢失的数据视为不良数据（违反阈值））。有关更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[配置 CloudWatch 警报如何处理丢失的数据](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)。
1. 选择**下一步**。
**Configure actions**（配置操作）页面会显示。
1. 在 **Notification**（通知）下面，选择一个在警报处于 `ALARM`、`OK` 或 `INSUFFICIENT_DATA` 状态时通知的 Amazon SNS 主题。
要使告警为相同告警状态或不同告警状态发送多个通知，请选择**添加通知**。
要让警报不发送通知，请选择**删除**。
1. 您可以保留 **Configure actions**（配置操作）页面的其他部分为空。将其他部分留空会创建警报，而不会将其与扩展策略相关联。然后，您可以从 Amazon EC2 Auto Scaling 控制台将警报与扩展策略关联。
1. 选择**下一步**。
1. 输入警报的名称（例如，`Step-Scaling-AlarmLow-RemoveCapacity`）和可选的描述，然后选择 **Next**（下一步）。
1. 选择**创建警报**。
创建 CloudWatch 警报后，按照以下步骤继续从上次中断的地方继续。
**步骤 2：为横向缩减创建步进扩缩策略**
1. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
1. 选中您的自动扩缩组旁边的复选框。
这时将在页面底部打开一个拆分窗格。
1. 验证是否正确设置了扩缩限制。例如，如果您的组所需容量已经是最小，则需要指定一个新的最小值才能横向缩减。有关更多信息，请参阅 [为自动扩缩组设置扩缩限制](asg-capacity-limits.md)。
1. 在 **Automatic scaling**（自动扩展）选项卡的 **Dynamic scaling policies**（动态扩展策略）中，选择 **Create dynamic scaling policy**（创建动态扩展策略）。
1. 对于**策略类型**，选择**步进扩展**，然后指定该策略的名称。
1. 要获得**CloudWatch 警报**，请选择您的闹钟。如果您尚未创建警报，请选择**创建警 CloudWatch 报，然后完成上一个**过程中的步骤 4 到步骤 14 以创建警报。
1. 指定在使用 **Take the action (执行操作)** 来完成操作时，此策略对当前组大小进行的更改。您可以删除特定数量的实例或现有组大小的百分比，也可将组设置为准确的大小。
例如，要创建将组容量减少两个实例的横向缩减策略，请选择 `Remove`，在下一个字段中输入 `2`，然后选择 `capacity units`。默认情况下，此步骤调整的上限为警报阈值，下限为负 (-) 无穷。
1. 要添加另一个步骤，请选择 **Add step (添加步进)**，然后定义要缩放的量以及步进相对于警报阈值的下限和上限。
1. 选择**创建**。
------
#### [ AWS CLI ]
要创建横向缩减（减少容量）的步进扩缩策略，可以使用以下示例命令。将每个 *user input placeholder* 替换为您自己的信息。
使用时 AWS CLI，首先要创建分步扩展策略，该策略向 Amazon EC2 Auto Scaling 提供有关在指标值减少时如何缩减的说明。然后，通过确定要监控的指标、为警报定义指标的低阈值和其他详细信息，并将警报与扩缩策略关联，您可以创建警报。
**步骤 1：为横向缩减创建策略**
使用以下[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html)命令创建名为的分步扩展策略`my-step-scale-in-policy`，其调整类型为，当关联的`ChangeInCapacity` CloudWatch 警报违反指标低阈值时，该策略会将组的容量减少 2 个实例。
```
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name my-step-scale-in-policy \
--policy-type StepScaling \
--adjustment-type ChangeInCapacity \
--step-adjustments MetricIntervalUpperBound=0.0,ScalingAdjustment=-2
```
记下策略的 Amazon Resource Name (ARN)。您需要它来为策略创建 CloudWatch 警报。
```
{
"PolicyARN": "arn:aws:autoscaling:region:123456789012:scalingPolicy:ac542982-cbeb-4294-891c-a5a941dfa787:autoScalingGroupName/my-asg:policyName/my-step-scale-out-policy
}
```
**步骤 2：为指标低阈值创建 CloudWatch 警报**
使用以下 CloudWatch [put-metric-alarm](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/put-metric-alarm.html)命令创建警报，根据平均 CPU 阈值 40% 减小 Auto Scaling 组的大小，至少连续两个评估周期（两分钟）。要使用您自己的自定义指标，请在 `--metric-name` 中指定其名称，并在 `--namespace` 指定其命名空间。
```
aws cloudwatch put-metric-alarm --alarm-name Step-Scaling-AlarmLow-RemoveCapacity \
--metric-name CPUUtilization --namespace AWS/EC2 --statistic Average \
--period 120 --evaluation-periods 2 --threshold 40 \
--comparison-operator LessThanOrEqualToThreshold \
--dimensions "Name=AutoScalingGroupName,Value=my-asg" \
--alarm-actions PolicyARN
```
------
# 简单扩展策略
以下示例说明如何使用 CLI 命令创建简单扩缩策略。本文档中将保留这些命令，以供希望使用它们的客户进行参考，但建议您改用目标跟踪或步进扩缩策略。
与步进扩展策略类似，简单的扩展策略要求您为扩展策略创建 CloudWatch 警报。在您创建的策略中，您还必须定义添加还是删除实例及实例的数量，或者将组设置为确切的大小。
步进扩缩策略和简单扩缩策略之间的主要区别之一是步进扩缩策略可以进行步进调整。通过步进扩缩，您可以根据自己指定的步进调整对组的大小进行更大或更小的更改。
简单扩缩策略还必须等待正在进行的扩缩活动或运行状况检查替换完成并且[冷却时间](ec2-auto-scaling-scaling-cooldowns.md)结束，然后才能响应其他警报。与之对比，步进扩缩策略会继续响应其他警报，甚至在进行扩缩活动或运行状况检查替换时也是如此。这意味着 Amazon EC2 Auto Scaling 会在收到警报消息时评估所有警报违规情况。因此，建议您使用步进扩缩策略，即使您只有一个扩缩调整。
Amazon EC2 Auto Scaling 起初只支持简单扩展策略。如果您在引入目标跟踪和步进扩缩策略前已创建自己的扩缩策略，则您的策略将被视为简单扩缩策略。
## 为横向扩展创建简单扩缩策略
使用以下[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html)命令创建一个名为的简单扩展策略`my-simple-scale-out-policy`，其调整类型为，当关联的`PercentChangeInCapacity` CloudWatch 警报违反指标高阈值时，该策略会将组的容量增加 30%。
```
aws autoscaling put-scaling-policy --policy-name my-simple-scale-out-policy \
--auto-scaling-group-name my-asg --scaling-adjustment 30 \
--adjustment-type PercentChangeInCapacity
```
记下策略的 Amazon Resource Name (ARN)。您需要它来为策略创建 CloudWatch 警报。
## 为横向缩减创建简单扩缩策略
使用以下[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html)命令创建名为的简单扩展策略`my-simple-scale-in-policy`，其调整类型为，当关联的`ChangeInCapacity` CloudWatch 警报违反指标低阈值时，该策略会将组的容量减少一个实例。
```
aws autoscaling put-scaling-policy --policy-name my-simple-scale-in-policy \
--auto-scaling-group-name my-asg --scaling-adjustment -1 \
--adjustment-type ChangeInCapacity --cooldown 180
```
记下策略的 Amazon Resource Name (ARN)。您需要它来为策略创建 CloudWatch 警报。
# Amazon EC2 Auto Scaling 的缩放冷却时间
**重要**
作为最佳实践，我们建议您不要使用简单扩缩策略和扩缩冷却。目标跟踪扩缩策略或步进扩缩策略更能提升扩缩性能。对于随着扩缩指标值的减小或增加而按比例更改 Auto Scaling 组大小的扩缩策略，我们建议采用[目标跟踪](as-scaling-target-tracking.md)而不是简单扩缩或分步扩缩。
当您为自动扩缩组创建简单的扩缩策略时，我们建议您同时配置扩缩冷却。
在您的 Auto Scaling 组启动或终止实例后，它首先等待冷却时间结束，然后才能启动简单扩缩策略启动的任何扩缩活动。冷却时间的用途是让您的自动扩缩组在先前的扩缩活动产生明显的作用之前保持稳定，防止其启动或终止其他实例。
例如，假设一个有关 CPU 利用率的简单扩缩策略建议启动两个实例。Amazon EC2 Auto Scaling 会启动两个实例，然后暂停扩缩活动，直到冷却时间结束。冷却时间结束后，简单扩缩策略启动的任何扩缩活动都可以恢复。如果 CPU 利用率再次超过告警阈值上限，则 Auto Scaling 组将再次横向扩展，而冷却时间也会再次生效。不过，如果两个实例足以将指标值降为正常水平，该组会保持其当前大小。
**Topics**
+ [
## 注意事项
](#cooldown-considerations)
+ [
## 生命周期挂钩可能会导致额外的延迟
](#cooldowns-lifecycle-hooks)
+ [
## 更改原定设置冷却时间
](#set-default-cooldown)
+ [
## 为特定的简单扩缩策略设置冷却时间
](#cooldowns-scaling-specific)
## 注意事项
在使用简单扩缩策略和扩缩冷却时，应注意以下事项：
+ 目标跟踪扩缩策略和步进扩缩策略可以立即启动横向扩展活动，而无需等待冷却时间结束。相反，每当您的自动扩缩组启动实例时，单个实例都有一个预热时间。有关更多信息，请参阅 [为 Auto Scaling 组设置原定设置实例预热](ec2-auto-scaling-default-instance-warmup.md)。
+ 当横向扩展活动正在进行时，所有目标跟踪和步进扩缩横向缩减活动都将被阻止，直到实例完成预热。当自动扩缩组处于冷却时间时，横向缩减活动也可能会延迟。
+ 当计划的操作在计划的时间开始时，它还可能会立即启动扩缩活动，而无需等待冷却时间结束。
+ 如果实例运行不正常，Amazon EC2 Auto Scaling 不会等到冷却时间结束才替换运行不正常的实例。
+ 当多个实例启动或终止时，冷却时间（无论是原定设置冷却还是特定于扩缩策略的冷却）会从最后一个实例完成启动或终止时开始生效。
+ 当您手动扩展 Auto Scaling 组时，预设情况下不会等待冷却时间结束。但是，在使用 AWS CLI 或 SDK 进行手动缩放时，您可以覆盖此行为并遵守默认的冷却时间。
+ 预设情况下，Elastic Load Balancing 会等待 300 秒，以便完成注销（Connection Draining）过程。如果组位于 Elastic Load Balance 负载均衡器后面，它将等待终止的实例完成注销，然后再开始计算冷却时间。
## 生命周期挂钩可能会导致额外的延迟
如果触发了[生命周期钩子](lifecycle-hooks.md)，则冷却时间将在您完成生命周期操作后或超时时间结束后开始计算。例如，假设某个 Auto Scaling 组具有一个有关实例启动的生命周期钩子。当应用程序需求增加时，该组会启动实例以增加容量。由于存在生命周期钩子，所以实例将置于等待状态，并且由简单扩缩策略触发的扩缩活动将被暂停。当实例进入 `InService` 状态时，冷却时间开始。冷却时间结束后，将恢复简单扩缩策略活动。
启用 Elastic Load Balancing 时，对于横向缩减，冷却时间从选择终止的实例开始连接耗尽（取消注册延迟）时开始。冷却时间不会等待连接耗尽完成或生命周期挂钩完成其操作。这意味着，横向缩减事件的结果反映在组的容量中后，因简单扩缩策略触发的任何扩缩活动都可以立即恢复。否则，等待所有三个活动（Connection Draining、生命周期钩子和冷却时间）完成会显著增加 Auto Scaling 组暂停扩缩所需的时间量。
## 更改原定设置冷却时间
首次在 Amazon EC2 Auto Scaling 控制台中创建 Auto Scaling 组时，您将无法设定原定设置冷却。预设情况下，此冷却时间设置为 300 秒（5 分钟）。如果需要，您可以在创建组后更新此设置。
**更改原定设置冷却时间（控制台）**
创建 Auto Scaling 组后，在 **Details**（详细信息）选项卡上，依次选择**Advanced configurations**（高级配置）、**Edit**（编辑）。对于 **Default cooldown**（原定设置冷却），请根据实例启动时间或其他应用程序需求选择所需的时长。
**更改原定设置冷却时间（AWS CLI）**
使用以下命令更改新的或现有 Auto Scaling 组的原定设置冷却。如果未定义原定设置冷却，则使用 300 秒的原定设置。
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)
+ [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html)
要确认默认冷却时间值，请使用[describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html)命令。
## 为特定的简单扩缩策略设置冷却时间
预设情况下，所有简单扩缩策略都使用为 Auto Scaling 组定义的原定设置冷却时间。要设置特定简单扩缩策略的冷却时间，请在创建或更新策略时使用可选的冷却参数。在为策略指定冷却时间时，它将覆盖原定设置冷却。
对于扩缩策略特定的冷却时间，一个常见的使用场景是横向缩减策略。由于此策略是要终止实例，Amazon EC2 Auto Scaling 需要较短的时间来确定是否终止其他实例。终止实例应该是比启动实例快得多的操作。因此，300 秒的默认冷却时间太长。在这种情况下，为横向缩减策略设置一个具有较低值的扩缩策略特定冷却时间，可让该组更快横向缩减，从而帮助降低成本。
要在控制台中创建或更新简单扩缩策略，请在创建该组之后选择 **Automatic scaling**（弹性伸缩）选项卡。要使用创建或更新简单的扩展策略 AWS CLI，请使用[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html)命令。有关更多信息，请参阅 [步进和简单扩展策略](as-scaling-simple-step.md)。
# 基于 Amazon SQS 的扩缩策略
**重要**
以下信息和步骤向您展示了在将队列属性作为自定义指标发布到之前，如何使用队列属性计算每个实例的 Amazon SQS `ApproximateNumberOfMessages` 队列待办事项。 CloudWatch但是，您现在可以使用指标数学来节省发布自己的指标所花费的成本和精力。有关更多信息，请参阅 [使用指标数学创建目标跟踪扩缩策略](ec2-auto-scaling-target-tracking-metric-math.md)。
您可以扩展自动扩缩组以响应 Amazon Simple Queue Service（Amazon SQS）队列中系统负载的变化。要了解有关如何使用 Amazon SQS 的更多信息，请参阅 [Amazon 简单队列服务开发人员指南](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/)。
在一些情况下，您可能会考虑根据 Amazon SQS 队列中的活动扩展。例如，假设您有 Web 应用程序，让用户上传图像并联机使用。在此场景中，每个图像需要先调整大小并编码，然后才能发布。该应用程序在 Auto Scaling 组中的 EC2 实例上运行，配置为处理您的典型上传速率。不正常的实例将终止并进行替换，以始终保持当前的实例等级。该应用程序将图像的原始位图数据放在 SQS 队列中以进行处理。它处理这些图像，然后将处理的图像发布到某个位置以供用户查看。如果上传的图像数不随时间波动，则适用于此场景的架构可以良好运作。但是，如果上传数量随着时间波动，您可以考虑使用动态扩展来缩放 Auto Scaling 组的容量。
**Topics**
+ [
## 将目标跟踪与合适的指标结合使用
](#scale-sqs-queue-custom-metric)
+ [
## 限制
](#scale-sqs-queue-limitations)
+ [
# 配置基于 Amazon SQS 的缩放
](scale-sqs-queue-cli.md)
+ [
## Amazon SQS 和实例缩减保护
](#scale-sqs-queue-scale-in-protection)
## 将目标跟踪与合适的指标结合使用
如果您使用基于自定义 Amazon SQS 队列指标的目标跟踪扩展策略，则动态扩展可以更有效地适应应用程序的需求曲线。有关为目标跟踪选择指标的更多信息，请参阅 [选择指标](as-scaling-target-tracking.md#target-tracking-choose-metrics)。
使用诸如目标跟踪之类的 A CloudWatch mazon SQS 指标的问题在`ApproximateNumberOfMessagesVisible`于，队列中的消息数量可能不会与处理队列消息的 Auto Scaling 组的大小成比例变化。这是因为 SQS 队列中的消息数不仅仅定义所需的实例数。Auto Scaling 组中的实例数可能由多种因素决定，包括处理消息所需的时间以及可接受的延迟长度（队列延迟）。
该解决方案使用要维护的*每个实例的积压* 指标以及*每个实例的可接受积压* 的目标值。您可以按以下所示计算这些数字：
+ **每个实例的积压**：要计算您每个实例的积压，首先通过 `ApproximateNumberOfMessages` 度列属性确定 SQS 队列的长度（可从队列中检索的消息数）。将该数字除以队列的运行容量（对于 Auto Scaling 组，这是处于 `InService` 状态的实例数量），以获得每个实例的积压。
+ **每个实例的可接受积压**：要计算您的目标值，请先确定您的应用程序可以接受的延迟。然后，将可接受的延迟值除以 EC2 实例处理一条消息所用的平均时间。
例如，假设您当前有一个包含 10 个实例的自动扩缩组，并且队列中的可见消息数量（`ApproximateNumberOfMessages`）是 1500。如果每条消息的平均处理时间为 0.1 秒，最长可接受延迟为 10 秒，则每个实例的可接受积压为 10/0.1，即 100 条消息。这意味着您的目标跟踪策略的目标值为 100。当每个实例的积压达到目标值时，将发生横向扩展事件。由于每个实例已经积压了 150 条消息（10 个实例 1500 条消息），该组会横向扩展并增加了 5 个实例以维持与目标值的比例。
以下过程演示如何发布自定义指标和创建目标跟踪扩展策略，以根据这些计算值来配置您的 Auto Scaling 组进行扩展。
**重要**
请记住，为了降低成本，请改用指标数学。有关更多信息，请参阅 [使用指标数学创建目标跟踪扩缩策略](ec2-auto-scaling-target-tracking-metric-math.md)。
此配置有三个主要部分：
+ 一个 Auto Scaling 组，用于管理处理来自 SQS 队列的消息的 EC2 实例。
+ 发送到亚马逊的自定义指标 CloudWatch ，用于衡量 Auto Scaling 组中每个 EC2 实例在队列中的消息数量。
+ 一种目标跟踪策略，用于将 Auto Scaling 组配置为根据自定义指标和设定的目标值进行扩展。 CloudWatch 警报会调用扩展策略。
下图演示了此配置的架构。
![\[Amazon EC2 Auto Scaling 使用队列架构图\]](http://docs.aws.amazon.com/zh_cn/autoscaling/ec2/userguide/images/sqs-as-custom-metric-diagram.png)
## 限制
您必须使用 AWS CLI 或 SDK 将您的自定义指标发布到 CloudWatch。然后，您可以使用监控您的指标 AWS 管理控制台。
在以下各节中， AWS CLI 您将使用来完成需要执行的任务。例如，要获取反映队列当前使用情况的指标数据，可以使用 SQS [get-queue-attributes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/get-queue-attributes.html)命令。
# 配置基于 Amazon SQS 的缩放
以下步骤介绍如何配置基于 Amazon SQS 的自动扩缩。您将学习如何创建 CloudWatch 自定义指标、如何使用设置目标跟踪策略以及如何测试您的配置。 AWS CLI
在开始之前，请确保已 AWS CLI [安装](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)并[配置](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html)。此外，您必须有一个要使用的 Amazon SQS 队列。以下任务假设您已经有一个队列（标准队列或 FIFO 队列）、一个自动扩缩组以及 EC2 实例（运行使用队列的应用程序）。
有关 Amazon SQS 权限的更多信息，请参阅 [Amazon 简单队列服务开发人员指南](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/)。
**Topics**
+ [
## 步骤 1：创建 CloudWatch 自定义指标
](#create-sqs-cw-alarms-cli)
+ [
## 步骤 2：创建目标跟踪扩展策略
](#create-sqs-policies-cli)
+ [
## 步骤 3：测试扩展策略
](#validate-sqs-scaling-cli)
## 步骤 1：创建 CloudWatch 自定义指标
自定义指标是使用您选择的指标名称和命名空间定义的。自定义指标的命名空间不能以 `AWS/` 开头。有关发布自定义指标的更多信息，请参阅 *Amazon CloudWatch 用户指南*中的[发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)主题。
按照此步骤首先从您的 AWS 账户中读取信息来创建自定义指标。然后，计算前面的章节中建议的每个实例的积压指标。最后，以 1 分钟为间 CloudWatch 隔发布此数字。只要可能，我们强烈建议您按 1 分钟粒度的指标进行扩展，以确保更快地响应系统负载变化。
**创建 CloudWatch 自定义指标 (AWS CLI)**
1. 使用 SQS [get-queue-attributes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/get-queue-attributes.html) 命令获取在队列中等待的消息数 (`ApproximateNumberOfMessages`)：
```
aws sqs get-queue-attributes --queue-url https://sqs.region.amazonaws.com/123456789/MyQueue \
--attribute-names ApproximateNumberOfMessages
```
1. 使用 [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 命令获取组的运行容量，这是处于 `InService` 生命周期状态的实例数。此命令返回 Auto Scaling 组的实例及其生命周期状态。
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names my-asg
```
1. 将该队列中可供检索的大致消息数量除以该组的运行容量，计算得出每个实例的积压。
1. 创建每分钟运行一次的脚本，以检索每个实例的待办事项值并将其发布到 CloudWatch 自定义指标。发布自定义指标时，需要指定该指标的名称、命名空间、单位、值以及零个或多个维度。维度由维度名称和维度值组成。
要发布您的自定义指标，请将中的*italics*占位符值替换为首选指标名称、指标值、命名空间（只要不是以 `AWS` “” 开头）和维度（可选），然后运行以下[put-metric-data](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/put-metric-data.html)命令。
```
aws cloudwatch put-metric-data --metric-name MyBacklogPerInstance --namespace MyNamespace \
--unit None --value 20 --dimensions MyOptionalMetricDimensionName=MyOptionalMetricDimensionValue
```
应用程序发出所需的指标之后，数据发送到 CloudWatch。该指标在 CloudWatch 控制台中可见。您可以通过登录 AWS 管理控制台 并导航到该 CloudWatch 页面来访问它。然后，通过导航到指标页面或者使用搜索框搜索指标来查看指标。有关查看指标的信息，请参阅 *Amazon CloudWatch 用户指南*中的[查看可用指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html)。
## 步骤 2：创建目标跟踪扩展策略
现在，您可以将创建的指标添加到目标跟踪扩缩策略中。
**创建目标跟踪扩缩策略（AWS CLI）**
1. 使用以下`cat`命令可以在您的主目录的名为`config.json`的 JSON 文件中存储扩缩策略的目标值和自定义指标规范。将每个 *user input placeholder* 替换为您自己的信息。对于 `TargetValue`，计算每个实例的可接受积压指标并在此处输入。要计算此数值，请考虑正常延迟值并将其除以处理一条消息所需的平均时间（如前面的章节所述）。
如果您没有为步骤 1 中创建的指标指定任何维度，请不要在自定义指标规范中包含任何维度。
```
$ cat ~/config.json
{
"TargetValue":100,
"CustomizedMetricSpecification":{
"MetricName":"MyBacklogPerInstance",
"Namespace":"MyNamespace",
"Dimensions":[
{
"Name":"MyOptionalMetricDimensionName",
"Value":"MyOptionalMetricDimensionValue"
}
],
"Statistic":"Average",
"Unit":"None"
}
}
```
1. 使用 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 命令以及在前面的步骤中创建的 `config.json` 文件创建扩展策略。
```
aws autoscaling put-scaling-policy --policy-name sqs100-target-tracking-scaling-policy \
--auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
--target-tracking-configuration file://~/config.json
```
这会创建两个警报：一个用于增加实例数量，另一个用于减少实例数量。它还会返回向其注册的策略的 Amazon 资源名称 (ARN) CloudWatch，该名称 CloudWatch 用于在指标阈值被违反时调用缩放。
## 步骤 3：测试扩展策略
在您完成设置后，验证您的扩展策略是否正常工作。您可以通过以下方式测试：增加 SQS 队列中的消息数，然后验证 Auto Scaling 组是否已启动更多 EC2 实例。您还可以通过以下方式测试：减少 SQS 队列中的消息数，然后验证 Auto Scaling 组是否终止了一个 EC2 实例。
**测试扩展函数**
1. 按照[创建 Amazon SQS 标准队列并发送消息](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/creating-sqs-standard-queues.html)或[创建 Amazon SQS FIFO 队列并发送消息](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/creating-sqs-fifo-queues.html)中的步骤，将消息添加到您的队列。请确保您增加了队列中的消息数量，使得每个实例的积压指标超过目标值。
您的更改调用警报可能需要几分钟时间。
1. 使用 [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 命令确认该组已启动一个实例。
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg
```
**测试横向缩减功能**
1. 按照[接收和删除消息（控制台）](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/step-receive-delete-message.html)中的步骤，从队列中删除消息。请确保您减少了队列中的消息数量，使得每个实例的积压指标低于目标值。
您的更改调用警报可能需要几分钟时间。
1. 使用 [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) 命令确认该组已终止一个实例。
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg
```
## Amazon SQS 和实例缩减保护
实例被终止时还未处理的消息将返回 SQS 队列中，可由仍在运行的实例进行处理。对于执行长时间运行任务的应用程序，您可以选择使用实例扩展保护来控制 Auto Scaling 组扩展时终止哪些队列工作程序。
以下伪代码显示了保护长时间运行、队列驱动的工件进程免受缩放终止的一种方法。
```
while (true)
{
SetInstanceProtection(False);
Work = GetNextWorkUnit();
SetInstanceProtection(True);
ProcessWorkUnit(Work);
SetInstanceProtection(False);
}
```
有关更多信息，请参阅 [设计您的应用程序以妥善处理实例终止](gracefully-handle-instance-termination.md)。
# 验证 Auto Scaling 组的扩缩活动
在 Amazon EC2控制台的“Amazon EC2 Auto Scaling”部分中，适用于 Auto Scaling 组的**活动记录**可让您查看当前正在进行的扩缩活动的当前状态。扩展活动完成后，您可以看到它是否成功。在创建 Auto Scaling 组或向现有组添加扩展条件时，此方法特别有用。
当您向 Auto Scaling 组添加目标跟踪、步骤或简单扩展策略时，Amazon EC2 Auto Scaling 会立即开始对照该指标评估策略。在指标超过阈值达到指定数量的评估期时，指标警报将变为 ALARM（警报）状态。这意味着扩展策略可能会在创建后立即引发扩展活动。在 Amazon EC2 Auto Scaling 响应扩展策略而调整所需容量之后，您可以验证账户中的扩展活动。如果您希望从 Amazon EC2 Auto Scaling 接收告知扩展活动的电子邮件通知，请按照 [Amazon EC2 Auto Scaling 的 Amazon SNS 通知选项](ec2-auto-scaling-sns-notifications.md) 中的说明操作。
**提示**
在以下过程中，您需要查看 Auto Scaling 组的 **Activity history**（活动历史记录）和 **Instances**（实例）部分。这两个部分都会已经显示已命名的列。要显示隐藏的列或更改显示的行数，请选择每个部分右上角的齿轮图标以打开首选项模式，根据需要更新设置，然后选择 **Confirm**（确认）。
**要查看 Auto Scaling 组的扩缩活动（控制台）**
1. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
1. 在屏幕顶部的导航栏中，选择您在其中创建了自动扩缩组的区域。
1. 选中 Auto Scaling 组旁边的复选框。
这时将在页面底部打开一个拆分窗格。
1. 在 **Activity**（活动）选项卡的 **Activity history**（活动历史记录）下，**Status**（状态）列显示您的 Auto Scaling 组是否已成功启动或终止实例，或者扩展活动是否仍在进行中。
1. （可选）如果有很多扩缩活动，您可以选择活动历史记录顶部边缘的 **>** 图标，来查看下一页的扩缩活动。
1. 在**实例管理**选项卡的**实例**下，**生命周期**列显示实例的状态。在实例开启并且任何生命周期钩子结束后，其生命周期状态将更改为 `InService`。**Health status**（运行状态）列显示对您的实例进行 EC2 实例运行状况检查的结果。
**要查看 Auto Scaling 组的扩缩活动 (AWS CLI)**
使用以下 [describe-scaling-activities](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-scaling-activities.html) 命令。
```
aws autoscaling describe-scaling-activities --auto-scaling-group-name my-asg
```
下面是示例输出。
扩展活动按开始时间排序。首先描述仍在进行的活动。
```
{
"Activities": [
{
"ActivityId": "5e3a1f47-2309-415c-bfd8-35aa06300799",
"AutoScalingGroupName": "my-asg",
"Description": "Terminating EC2 instance: i-06c4794c2499af1df",
"Cause": "At 2020-02-11T18:34:10Z a monitor alarm TargetTracking-my-asg-AlarmLow-b9376cab-18a7-4385-920c-dfa3f7783f82 in state ALARM triggered policy my-target-tracking-policy changing the desired capacity from 3 to 2. At 2020-02-11T18:34:31Z an instance was taken out of service in response to a difference between desired and actual capacity, shrinking the capacity from 3 to 2. At 2020-02-11T18:34:31Z instance i-06c4794c2499af1df was selected for termination.",
"StartTime": "2020-02-11T18:34:31.268Z",
"EndTime": "2020-02-11T18:34:53Z",
"StatusCode": "Successful",
"Progress": 100,
"Details": "{\"Subnet ID\":\"subnet-5ea0c127\",\"Availability Zone\":\"us-west-2a\"...}",
"AutoScalingGroupARN": "arn"
},
...
]
}
```
有关输出中字段的描述，请参阅 *Amazon EC2 Auto Scaling API 参考*中的[活动](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_Activity.html)。
有关检索已删除组的扩展活动的帮助，以及有关可能会遇到的错误类型以及如何处理这些错误的信息，请参阅 [排查 Amazon EC2 Auto Scaling 中的问题](CHAP_Troubleshooting.md)。
# 禁用 Auto Scaling 组的扩缩策略
本主题介绍如何临时禁用扩展策略，使其不会发起对 Auto Scaling 组包含的实例数进行的更改。禁用扩展策略时，配置详细信息将保留，以便您可以快速重新启用策略。相比在不需要时暂时删除策略并在以后重新创建，这种方法更容易。
在禁用扩展策略时，Auto Scaling 组不会为违反的指标警报进行扩展或缩减。但是，任何仍在进行的扩展活动都不会停止。
请注意，已禁用的扩展策略仍会计入您可以添加到 Auto Scaling 组的扩展策略数量配额中。
**要禁用扩缩策略（控制台）**
1. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
1. 选中 Auto Scaling 组旁边的复选框。
这时将在页面底部打开一个拆分窗格。
1. 在 **Automatic scaling**（自动扩展）选项卡的 **Dynamic scaling policies**（动态扩展策略）下，选中所需扩展策略右上角的复选框。
1. 滚动到 **Dynamic scaling policies**（动态扩展策略）部分的顶部，然后选择 **Actions**（操作）、**Disable**（禁用）。
当您准备好重新启用扩展策略时，请重复这些步骤，然后选择 **Actions**（操作）、**Enable**（启用）。重新启用扩展策略后，如果当前有任何警报处于 ALARM 状态，您的 Auto Scaling 组可能会立即启动扩展操作。
**禁用扩展策略 (AWS CLI)**
将 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 命令与 `--no-enabled` 选项一起使用，如下所示。采用与在创建策略时相同的指定方式，在命令中指定所有选项。
```
aws autoscaling put-scaling-policy --auto-scaling-group-name my-asg \
--policy-name my-scaling-policy --policy-type TargetTrackingScaling \
--estimated-instance-warmup 360 \
--target-tracking-configuration '{ "TargetValue": 70, "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" } }' \
--no-enabled
```
**重新启用扩展策略 (AWS CLI)**
将 [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) 命令与 `--enabled` 选项一起使用，如下所示。采用与在创建策略时相同的指定方式，在命令中指定所有选项。
```
aws autoscaling put-scaling-policy --auto-scaling-group-name my-asg \
--policy-name my-scaling-policy --policy-type TargetTrackingScaling \
--estimated-instance-warmup 360 \
--target-tracking-configuration '{ "TargetValue": 70, "PredefinedMetricSpecification": { "PredefinedMetricType": "ASGAverageCPUUtilization" } }' \
--enabled
```
**描述扩展策略 (AWS CLI)**
使用 [describe-policies](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-policies.html) 命令验证扩展策略的启用状态。
```
aws autoscaling describe-policies --auto-scaling-group-name my-asg \
--policy-names my-scaling-policy
```
下面是示例输出。
```
{
"ScalingPolicies": [
{
"AutoScalingGroupName": "my-asg",
"PolicyName": "my-scaling-policy",
"PolicyARN": "arn:aws:autoscaling:us-west-2:123456789012:scalingPolicy:1d52783a-b03b-4710-bb0e-549fd64378cc:autoScalingGroupName/my-asg:policyName/my-scaling-policy",
"PolicyType": "TargetTrackingScaling",
"StepAdjustments": [],
"Alarms": [
{
"AlarmName": "TargetTracking-my-asg-AlarmHigh-9ca53fdd-7cf5-4223-938a-ae1199204502",
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-9ca53fdd-7cf5-4223-938a-ae1199204502"
},
{
"AlarmName": "TargetTracking-my-asg-AlarmLow-7010c83d-d55a-4a7a-abe0-1cf8b9de6d6c",
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-7010c83d-d55a-4a7a-abe0-1cf8b9de6d6c"
}
],
"TargetTrackingConfiguration": {
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ASGAverageCPUUtilization"
},
"TargetValue": 70.0,
"DisableScaleIn": false
},
"Enabled": true
}
]
}
```
# 删除自动扩缩组的扩缩策略
当您不再需要某个扩展策略时，可将其删除。根据扩展策略的类型，您可能还需要删除 CloudWatch 警报。删除目标跟踪扩展策略也会删除所有关联的 CloudWatch 警报。删除分步扩展策略或简单的扩展策略会删除底层警报操作，但不会删除 CloudWatch 警报，即使警报不再具有关联操作也是如此。
**删除扩展策略（控制台）**
1. 在上打开 Amazon EC2 控制台 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)，然后从导航窗格中选择 A **uto Scaling Gro** ups。
1. 选中 Auto Scaling 组旁边的复选框。
这时将在页面底部打开一个拆分窗格。
1. 在 **Automatic scaling**（自动扩展）选项卡的 **Dynamic scaling policies**（动态扩展策略）下，选中所需扩展策略右上角的复选框。
1. 滚动到 **Dynamic scaling policies**（动态扩展策略）部分的顶部，然后选择 **Actions**（操作）、**Delete**（删除）。
1. 当系统提示进行确认时，选择 **Yes, Delete**（是，删除）。
1. （可选）如果您删除了分步扩展策略或简单扩展策略，请执行以下操作以删除与该策略关联的 CloudWatch 警报。您可以跳过这些子步骤来保留警报以供将来使用。
1. 打开 CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。
1. 在导航窗格上，选择 **Alarms**（警报）。
1. 选择警报（例如 `Step-Scaling-AlarmHigh-AddCapacity`），然后选择 **Action**（操作）、**Delete**（删除）。
1. 当系统提示进行确认时，选择 **Delete**（删除）。
**要获取 Auto Scaling 组 (AWS CLI) 的扩展策略**
在您删除扩展策略之前，请使用以下 [describe-policies](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-policies.html) 命令查看为 Auto Scaling 组创建了哪些扩展策略。可以在删除策略和 CloudWatch 警报时使用输出。
```
aws autoscaling describe-policies --auto-scaling-group-name my-asg
```
可以使用 `--query` 参数按扩展策略类型筛选结果。此 `query` 语法仅在 Linux 或 macOS 上有效。在 Windows 上，请将单引号更改为双引号。
```
aws autoscaling describe-policies --auto-scaling-group-name my-asg
--query 'ScalingPolicies[?PolicyType==`TargetTrackingScaling`]'
```
下面是示例输出。
```
[
{
"AutoScalingGroupName": "my-asg",
"PolicyName": "cpu50-target-tracking-scaling-policy",
"PolicyARN": "PolicyARN",
"PolicyType": "TargetTrackingScaling",
"StepAdjustments": [],
"Alarms": [
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e",
"AlarmName": "TargetTracking-my-asg-AlarmHigh-fc0e4183-23ac-497e-9992-691c9980c38e"
},
{
"AlarmARN": "arn:aws:cloudwatch:us-west-2:123456789012:alarm:TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2",
"AlarmName": "TargetTracking-my-asg-AlarmLow-61a39305-ed0c-47af-bd9e-471a352ee1a2"
}
],
"TargetTrackingConfiguration": {
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ASGAverageCPUUtilization"
},
"TargetValue": 50.0,
"DisableScaleIn": false
},
"Enabled": true
}
]
```
**删除扩展策略 (AWS CLI)**
使用以下 [delete-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-policy.html) 命令。
```
aws autoscaling delete-policy --auto-scaling-group-name my-asg \
--policy-name cpu50-target-tracking-scaling-policy
```
**要删除您的 CloudWatch 警报 (AWS CLI)**
对于分步和简单扩展策略，请使用 [delete-alarms 命令删除与策略关联的 CloudWatch 警报](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/delete-alarms.html)。您可以跳过此步骤来保留该警报以备将来使用。您可以一次删除一个或多个警报。例如，使用以下命令可删除 `Step-Scaling-AlarmHigh-AddCapacity` 和 `Step-Scaling-AlarmLow-RemoveCapacity` 警报：
```
aws cloudwatch delete-alarms --alarm-name Step-Scaling-AlarmHigh-AddCapacity Step-Scaling-AlarmLow-RemoveCapacity
```
# 的扩展策略示例 AWS CLI
您可以通过 AWS 管理控制台、 AWS Command Line Interface (AWS CLI) 或为 Amazon EC2 Auto Scaling 创建扩展策略 SDKs。
以下示例显示了如何使用 AWS CLI [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html)命令为 Amazon EC2 Auto Scaling 创建扩展策略。将每个 *user input placeholder* 替换为您自己的信息。
要开始使用编写扩展策略 AWS CLI，请参阅[目标跟踪扩展策略](as-scaling-target-tracking.md)和中的入门练习[步进和简单扩展策略](as-scaling-simple-step.md)。
**示例 1：应用具有预定义指标规范的目标跟踪扩展策略**
```
aws autoscaling put-scaling-policy --policy-name cpu50-target-tracking-scaling-policy \
--auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
--target-tracking-configuration file://config.json
{
"TargetValue": 50.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ASGAverageCPUUtilization"
}
}
```
有关更多信息，请参阅[PredefinedMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredefinedMetricSpecification.html)《*亚马逊 EC2 Auto Scaling API 参考*》。
**注意**
如果文件不在当前目录中，请键入文件的完整路径。有关从文件读取 AWS CLI 参数值的更多信息，请参阅 AWS Command Line Interface 用户指南中的[从文件加载 AWS CLI 参数](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-file.html)。
**示例 2：应用具有自定义指标规范的目标跟踪扩展策略**
```
aws autoscaling put-scaling-policy --policy-name sqs100-target-tracking-scaling-policy \
--auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
--target-tracking-configuration file://config.json
{
"TargetValue": 100.0,
"CustomizedMetricSpecification": {
"MetricName": "MyBacklogPerInstance",
"Namespace": "MyNamespace",
"Dimensions": [{
"Name": "MyOptionalMetricDimensionName",
"Value": "MyOptionalMetricDimensionValue"
}],
"Statistic": "Average",
"Unit": "None"
}
}
```
有关更多信息，请参阅[CustomizedMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CustomizedMetricSpecification.html)《*亚马逊 EC2 Auto Scaling API 参考*》。
**示例 3：为仅向外扩展应用目标跟踪扩展策略**
```
aws autoscaling put-scaling-policy --policy-name alb1000-target-tracking-scaling-policy \
--auto-scaling-group-name my-asg --policy-type TargetTrackingScaling \
--target-tracking-configuration file://config.json
{
"TargetValue": 1000.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ALBRequestCountPerTarget",
"ResourceLabel": "app/my-alb/778d41231b141a0f/targetgroup/my-alb-target-group/943f017f100becff"
},
"DisableScaleIn": true
}
```
**示例 4：为向外扩展应用步进扩展策略**
```
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name my-step-scale-out-policy \
--policy-type StepScaling \
--adjustment-type PercentChangeInCapacity \
--metric-aggregation-type Average \
--step-adjustments MetricIntervalLowerBound=10.0,MetricIntervalUpperBound=20.0,ScalingAdjustment=10 \
MetricIntervalLowerBound=20.0,MetricIntervalUpperBound=30.0,ScalingAdjustment=20 \
MetricIntervalLowerBound=30.0,ScalingAdjustment=30 \
--min-adjustment-magnitude 1
```
记下策略的 Amazon Resource Name (ARN)。创建警报时需要 ARN。 CloudWatch
**示例 5：为缩减应用步进扩展策略**
```
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name my-step-scale-in-policy \
--policy-type StepScaling \
--adjustment-type ChangeInCapacity \
--step-adjustments MetricIntervalUpperBound=0.0,ScalingAdjustment=-2
```
记下策略的 Amazon Resource Name (ARN)。创建警报时需要 ARN。 CloudWatch
**示例 6：为向外扩展应用简单扩展策略**
```
aws autoscaling put-scaling-policy --policy-name my-simple-scale-out-policy \
--auto-scaling-group-name my-asg --scaling-adjustment 30 \
--adjustment-type PercentChangeInCapacity --min-adjustment-magnitude 2
```
记下策略的 Amazon Resource Name (ARN)。创建警报时需要 ARN。 CloudWatch
**示例 7：为缩减应用简单扩展策略**
```
aws autoscaling put-scaling-policy --policy-name my-simple-scale-in-policy \
--auto-scaling-group-name my-asg --scaling-adjustment -1 \
--adjustment-type ChangeInCapacity --cooldown 180
```
记下策略的 Amazon Resource Name (ARN)。创建警报时需要 ARN。 CloudWatch