创建 Ec2 Container Engine 集群时，它会创建一个 Compute Engine 托管实例组来管理创建的实例。这些实例来自 Ec2 服务，这意味着它们是虚拟机。
但是我们知道容器代表了一种基于操作系统级虚拟化而不是硬件虚拟化（如重量级且不可移植的虚拟机）部署容器的新方法，这不是矛盾吗？如我错了请纠正我。
我们使用容器是因为与 VM 相比它们非常快（无论是在启动时间还是在任务执行方面），并且它们节省了大量空间存储。因此，如果我们有一个最多可以支持 4 个容器的节点（vm），我们的客户可以快速午餐 4 个容器，但是超过这个数量，Ec2 自动缩放器将需要午餐一个新的节点（虚拟机）来支持即将到来的容器，这会产生一些任务延迟。
在物理机器上启动容器是不可能的吗？
对于运行关键时间执行任务，您有什么建议？
我相信您是在错误的假设下工作的，即 ECS 会根据任务需求直接扩展虚拟机（“容器实例”——容器将运行的实例）。
如果这是真的，那么您就有道理了，因为任何时候没有立即可用的容器实例资源不足，集群都会变得迟缓且无响应。
尽管存在 Auto Scaling Group，但 ECS 并没有这样做。
根据您在集群中使用的 Amazon EC2 实例类型以及集群中容器实例的数量，您的任务在运行时可以使用的资源数量有限。ECS 监控集群中可用的资源，以便与调度程序一起放置任务。如果您的集群在任何这些资源（例如内存）上运行不足，您最终将无法启动更多任务，直到您添加更多容器实例、减少服务中所需任务的数量或停止您的集群以释放受限资源。（重点补充）
http://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch_alarm_autoscaling.html
所以，不......当您的容量不足时，它不会缓慢启动新任务。它根本不启动它们。
但是不要走在我前面。
上面的链接通过示例解释了虚拟机（容器实例）的扩展是如何设计为实际工作的。
当然，您根本不必让它们自适应地扩展。您可以使用您的物理服务器模型（注意：我说物理服务器模型-- 意味着一个固定的、非弹性的资源池，在始终运行的虚拟机上，因为虚拟机是 EC2 提供的），并且只需选择您等待始终运行的实例数量，本质上是模拟物理服务器。例如，如果您想要 8 个容器实例，“自动扩展组”将始终保持 8 个，如果其中一个发生硬件故障，则会创建替换。这种“自动”成就将维持现状。当然，在这种配置中，您可以手动将 8 重新配置为 12，“自动”成就将是您将自动获得 4 个新的添加到现有的 8。
但是，如何理想地使用该服务的想法是，您的虚拟机组可以根据您设计的规则来扩大和缩小规模，以预测未来任务所需的资源 - 或未来缺乏任务。
在给出的示例中，内存预留是触发器：
当您的集群的内存预留上升到 75% 以上时（意味着您的集群中只有 25% 的内存可用于预留新任务），警报会触发 Auto Scaling 组添加另一个实例并为您提供更多资源任务和服务。
它会触发添加更多容器实例，以便您始终拥有在您需要时已经在线的任何您确定的适当剩余容量阈值。
当然，内存只是一种资源，75% 只是为示例选择的任意阈值。
Auto Scaling Groups 可以根据各种触发器进行扩展——月亮的短语、股票市场的价格趋势、任何适合预测您想要的剩余容量并且可以量化和监控的东西都可以使用……但是当由于资源不足而无法启动任务时，此服务不会通过实际尝试启动新任务来直接扩展自身。
这就是您原始论点中的缺陷。
为什么是虚拟机？很简单，因为当您因为预计不需要容量而销毁虚拟机时，您将停止为此付费。
从这个角度来看，也许你会同意这不是弱点，而是优势。当您不使用物理服务器时，它们永远不会停止花费您。
您根本不需要为虚拟机不需要的容量支付任何费用——您只需为正在使用的容量加上为处理预期需求而需要立即保持可用的容量付费。
您可以立即准备好您愿意支付的闲置剩余容量，或者您可以通过允许尽可能少的剩余容量来最大限度地节省资金，因为您可以毫不拖延地访问。