The advice "just put it behind an autoscaling group" is commonly used for scaling stateless applications like web servers. It works well because replicas are interchangeable and can be added or removed with minimal impact. However, this approach doesn't suit all workloads, particularly those with specific properties that violate interchangeability.One such property is session affinity, where a session is tied to a particular instance and cannot be easily transferred. Another is slow startup times for new instances, making reactive scaling ineffective if instances aren't ready when needed. For workloads with these characteristics, standard reactive autoscaling is the wrong solution.Instead of immediate reaction, scaling out should use slower, trend-based triggers. This allows new instances sufficient time to become fully operational before they are critically needed. Safely scaling in is also crucial, as simply terminating instances can disrupt ongoing work.Industry solutions like AWS lifecycle hooks enable graceful draining of sessions before an instance is terminated. This pattern involves stopping new work, waiting for existing sessions to complete, and then removing the instance. Large-scale systems, such as video conferencing platforms, already employ these more sophisticated scaling strategies.The key takeaway is to assess instance interchangeability. If any instance can handle any task instantly, autoscaling is appropriate. Otherwise, a slower scaling-out mechanism and proper scaling-in drain logic are necessary to effectively manage session-affine or slow-starting workloads. Forcing such workloads into a reactive, interchangeable model leads to significant failures.