本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

为 Auto Scaling 组设置原定设置实例预热

CloudWatch 收集和汇总您的 Auto Scaling 实例中的使用情况数据，例如CPU和网络 I/O。您可以使用这些指标来创建扩缩策略，以随着所选指标值的增减调整 Auto Scaling 组中的实例数量。

您可以指定实例在达到InService状态后等待多长时间才能向聚合指标提供使用数据。此指定时间称为默认实例预热。这可以防止动态扩展受到尚未处理应用程序流量且计算资源使用率可能暂时过高的单个实例的指标的影响。

为了优化目标跟踪和步进扩展策略的性能，我们强烈建议您启用和配置默认的实例预热。默认情况下，它未启用或配置。

启用默认实例预热时，请记住，如果您的 Auto Scaling 组设置为使用实例维护策略，或者您使用实例刷新来替换实例，则可以在实例完成初始化之前阻止将其计入最低运行状况百分比。

扩缩性能注意事项

对于大多数应用程序来说，有一个适用于所有功能的默认实例预热时间，而不是为不同的功能设置不同的预热时间，这很有用。例如，如果您未设置默认的实例预热时间，则实例刷新功能将使用运行状况检查宽限期作为默认预热时间。如果您有任何目标跟踪和步进缩放策略，它们会使用为默认冷却时间设置的值作为默认预热时间。如果您有任何预测性扩展策略，则它们没有默认的预热时间。

当实例预热时，只有当未预热的实例的指标值大于策略的警报高阈值（或目标跟踪扩展策略的目标利用率）时，您的动态扩展策略才会横向扩展。如果需求减少，动态扩展将变得更加保守，以保护应用程序的可用性。在新实例完成预热之前，这会阻止动态扩展活动的规模。

在扩展时，Amazon A EC2 uto Scaling 在决定向该组添加多少实例时，会将正在预热的实例视为组容量的一部分。因此，需要添加相似容量的多个警报漏洞会导致一次扩展活动。其目的是不断扩大规模，但不要过度扩张。

如果未启用默认实例预热，则实例在向其发送指标 CloudWatch 并将其计入当前容量之前等待的时间将因实例而异。因此，与实际发生的工作负载相比，您的扩展策略的性能可能会变得不可预测。

例如，假设一个具有重复 on-and-off 工作负载模式的应用程序。预测性扩缩策略用于对是否增加实例数量做出反复决策。由于预测性扩展策略没有默认的预热时间，因此这些实例会立即开始为聚合指标做出贡献。如果这些实例在启动时资源使用量较高，那么添加实例可能会导致聚合指标出现峰值。这可能会影响使用这些指标的任何动态扩缩策略，具体取决于使用量需要多长时间才能稳定下来。如果突破了动态扩缩策略的警告阈值上限，则该组的大小会再次增加。在新实例预热期间，活动规模将被阻止。

选择默认的实例预热时间

设置原定设置实例预热的关键是确定实例需要多长时间才能完成初始化，以及资源消耗在达到 InService 状态后需要多长时间才能稳定下来。在选择实例预热时间时，请尽量在收集合法流量的使用数据和尽量减少与启动时临时使用量峰值相关的数据收集之间保持最佳平衡。

假设您有一个附加到 Elastic Load Balancing 负载均衡器的自动扩缩组。当新实例完成启动后，它们将在进入 InService 状态之前注册到负载均衡器。在实例进入 InService 状态之后，资源消耗仍然可能会经历暂时的高峰，然后才会逐渐稳定下来。例如，与无需下载大型资产的轻量级 Web 服务器相比，对于必须下载并缓存大型资产的应用程序服务器，其资源消耗将需要更长的时间才能稳定。实例预热提供了稳定资源消耗所需的时间延迟。

对于需要在启动时运行配置任务或脚本的使用案例，应考虑使用生命周期挂钩。生命周期挂钩可以将实例投入使用的时间延迟到实例完成初始化之后。如果引导启动脚本需要一段时间才能完成，则生命周期钩子将特别有用。如果您添加了生命周期挂钩，则可以降低原定设置实例预热的值。有关使用生命周期钩子的更多信息，请参阅 Amazon EC2 Auto Scaling 生命周期钩子。