如何在ECS Auto Scaling环境中自动执行EC2实例上的OS / ECS-agent更新？

首先，我觉得我还不了解AWS的一些基本概念，所以请耐心等待，如果这个问题是不好的。

我在AWS中有以下设置：

• 1个单一服务的ECS群集
• 群集configuration为使用1个单个EC2实例
• 此EC2实例是基于特定启动configuration的AutoScaling组的一部分。 （群集设置configuration它是这样的，这是有道理的，我猜。）

我已经发展了一些先入为主的条件

• 我不关心EC2实例，因为我的服务运行机器不可知论
• 我的服务一次只需要运行一个实例。 我只使用ECS来运行一个dockerized应用程序。
• 我不在意在特定的时间停机。
• 有一个预定义的Elastic IP必须与该服务一起使用。
• 我希望此服务尽可能自动化。 当出现问题时，我们可以解决问题（正常运行时间并不重要），但是我从来不想SSH到EC2实例或类似的东西。

借助CloudWatch和Lambda ，我设置了以下任务：

• 使用AWS Route53通过IP打开网站而不打开域名
• 将EC2server映像存储在存储桶“子文件夹”中
• 云计算持久性服务器
• EC2公共AMI库中CENTOS发行版的最新版本是什么？
• EC2是否有费率限制？ 看来，如果你使用AB来testing请求，我们得到扼杀

实例由集群名称标识，自动添加到Name标签。

• 每周一次，群集实例重新启动。 这会更新证书和configuration，因为服务在启动时会执行此操作。 （我可能也可以安排服务被杀死，重新启动集群内部……）
• 每次集群的新EC2实例启动时，都会分配预定义的弹性IP。
• 每个月一次， EC2实例被终止，由Auto Scaling Group启动的一个新的自动replace。

现在我的希望是，一旦Auto Scaling Group创build了一个新实例，它将拥有最新的，最大的AMI，包括最新的ECS代理。

纠正我，如果我错了，但当我看着这个Auto Scaling组的启动configuration，我想这不会是这样，因为它总是采取configuration的AMI。

我的一般问题是：这个设置有什么用处，当我需要每隔一段时间手动检查一次（何时完成）来更新启动configuration中的AMI，然后终止实例来取代一个新的实例它？

我知道很多人可能不希望在生产群集中自动执行操作系统更新，因为他们想先testing它。 但是，仍然有人可能想要有一个临时环境，在其中自动应用操作系统更新。 当我仍然需要手动推出操作系统更新时，为什么要使用高度自动化的平台？ 这是对我的概念误解吗？