“只需将其置于自动伸缩组之后”这一建议常用于无状态应用（如 Web 服务器）的伸缩。其效果良好，因为副本可互换，且增减时对系统影响极小。然而，这种方法并不适用于所有工作负载，尤其是那些具有特定属性、违背可互换性的工作负载。其中一种属性是会话亲和性（session affinity），即会话绑定到特定实例，难以轻易转移。另一种属性是新实例启动缓慢，若实例在需要时未就绪，则反应式伸缩将失效。对于具有此类特征的工作负载，标准的反应式自动伸缩并非正确方案。与其立即反应，伸缩扩容应采用基于趋势的较慢触发机制。这使新实例有足够时间完全就绪，再在关键需求出现前投入使用。安全地缩容同样至关重要，因为直接终止实例可能中断正在进行的工作。行业解决方案（如 AWS 生命周期挂钩）可在终止实例前实现会话的优雅 draining。该模式包括停止新工作、等待现有会话完成，随后移除实例。大规模系统（如视频会议平台）已采用此类更复杂的伸缩策略。关键要点是评估实例的可互换性。若任何实例都能即时处理任何任务，则自动伸缩是合适的。否则，必须采用较慢的扩容机制以及正确的缩容 draining 逻辑，才能有效管理具有会话亲和性或启动缓慢的工作负载。强行将此类工作负载纳入反应式、可互换的模型，将导致严重故障。