我们正在尝试使用策略“每个主机一个任务”在ECS中部署我们的应用程序，因为我们使用主机网络而不是Docker。
我们从1个任务〜1个主机开始，随着（假设）CPU的增加，我们看到当新的任务部署在这些实例中时，如何将新的Container实例添加到集群。
然后，当CPU较低时，我们会看到调度程序如何开始销毁实例和容器。
一切都很了不起，但有时候，调度程序会破坏一个实例和一个容器，因此，我们的集群在某些时候有1个实例和0个任务，因为它会破坏不同实例中的任务。我们想要的是一种始终销毁Container实例及其中的容器的方法。
我在实例上看到了“终止策略”，但与容器没什么相似之处。
我们正在使用容器实例中的比例组和1到5的容器以及基于CPU的指标，以便CPU增长实例和容器增长1到1，我们希望它们以相同的顺序销毁。
那可能吗？
我知道这篇文章有点暗示，但是如果你还在寻找，或者有人发现这个帖子有同样的问题，请让我提供答案。
是的，这是可能的，但不符合ECS的正常“包装”策略。 ECS基本上可以将容器打包或循环使用 - 这与其智能程度有关。它也不够聪明，不知道它应该终止最老实例上的容器（通常是ASG在扩展时终止的容器）。那么如何处理这个问题呢？
好吧，诀窍是让ASG服务完全处理扩展。创建规则以在cloudwatch中扩展，并让它们触发Lambda函数。在该Lambda函数中，增加ASG和ECS服务的所需计数。是的，ECS将尝试立即执行任务（由于没有足够的CPU /内存可用实例，因此会失败），但是一旦ASG完成实例放置，它就会成功。
扩展很容易，缩小比较麻烦。因此，您可以创建缩小规则，并在CPU使用率较低时删除ASG实例。您没有在ECS群集上配置缩小规则。完全没有。当ASG终止实例时，它将触发生命周期规则，说明“实例ID X正在尝试终止”，您可以使用SQS（您将配置为启动lambda）来监听该规则。当您在Lambda中捕获该规则时，您将使用BOTO获取与实例ID关联的任务列表，并调用kill以删除这些特定任务。
一旦该任务失效，您将在服务上将所需的设置设置为-1，这将阻止服务尝试重建任务。
瞧，现在与您的垂死实例关联的任务实例将始终是缩小时终止的实例。
复杂？是的 - ASG真正意味着对与其相关联的集群天真。这会做你想要的。
您可以使用ECS控制所有扩展而不是ASG来模拟相同类型的方法，但这将更加困难，因为您必须轮询已终止的容器而不是能够监听生命周期规则。