一位 SysOps 工程师正在排查公司 Web 应用程序的性能问题，该应用程序运行在 Auto Scaling 组内的 EC2 实例上。流量高峰在白天会不可预测地迅速发生。Auto Scaling 组在急剧的流量高峰期间无法足够快地进行扩容，导致用户响应缓慢。公司希望在控制成本的同时确保快速扩容——较大的流量高峰应导致比小高峰更大的容量增加。应如何配置 Auto Scaling 组以实现此行为？

步进扩缩策略 (Step Scaling Policy) 允许您根据警报指标的“步进”或范围来定义不同的扩缩调整。这意味着当负载增加幅度较大时（例如，CPU 利用率从 50% 跃升到 90%），您可以配置策略以增加更多的实例，从而实现比小幅负载增加更快的扩容。这直接满足了题目中“较大的流量高峰应导致比小高峰更大的容量增加”的要求，并且在成本控制方面，它只在需要时增加资源。 简单扩缩策略 (Simple Scaling Policy) 每次触发警报时都执行相同的扩缩操作，无法根据负载的严重程度动态调整扩容量。目标跟踪策略 (Target Tracking Policy) 旨在维持一个特定的指标目标（例如，平均 CPU 利用率 70%），它会自动调整容量以达到并维持该目标，但它不直接提供根据负载增量大小进行不同扩容量的机制。生命周期挂钩 (Lifecycle Hooks) 用于在实例启动或终止期间执行自定义操作，与扩缩决策本身无关，且手动更改最大实例数不符合自动扩缩的目的。