If we now consider the scale-in scenario, this becomes a little bit harder to determine. The spare ECS task capacity calculation we have discussed is related and required, however you need to think in these terms: if you removed an ECS container instance from the cluster, would there be enough capacity for all of the current running ECS tasks plus spare capacity for at least one additional ECS task? Another way to express this is to calculate the idle host capacity of the cluster–if greater than 1.0 hosts are idle in the cluster, then you can safely scale in the cluster, as subtracting a host would result in a remaining positive non-zero capacity. Note that we are referring to idle host capacity across the cluster–so think of this as more of a virtual host calculation, as you probably won't have a completely idle host. This virtual host calculation is safe, because if we did remove a host from the cluster, the life cycle hooks and ECS container instance-draining features we introduced previously in Chapter 11 - Managing the ECS Infrastructure Life Cycle will ensure any containers that are running on the instance to be removed will be migrated to other instances in the cluster.
It's also important to understand that the idle host capacity must be greater than 1.0 and not equal to 1.0, as you must have enough spare capacity for one ECS task, otherwise you will trigger a scale-out action, resulting in an auto scaling scale-out/scale-in loop.
To determine the current idle host capacity, we need to understand the following:
- The maximum number of ECS tasks that each ECS container instance can run for each of the different types of ECS resources (expressed as
). - The current free capacity for each type of ECS resource across the entire cluster (expressed as
), which we already calculate when determining whether to scale out.
With these pieces of information, you can calculate the idle host capacity for a given resource as follows:
