AmazonWebServices从星期五开始进行实例重启，重启即将于9月30日结束，这次安全补丁修复凸显了云计算应该如何成熟以及应对这种问题的最佳实践都还有待思考完善。
这家云计算巨头通过电子邮件告诉EC2该公司计划在这些日子里重启所有区的实例，用户不能停止这个过程。云计算供应商都会有一些停机的维护时间，但是AWS重启的规模之大——据推测可能是由于开放源代码管理程序Xen中存在一个缺陷——很多用户会担心这次停机。
亚马逊在周四表示此次更新和Bashbug无关。
显然当所有实例都不得不进行重启的情况下，如何沟通和最佳实践仍需摸索。AWS是最大的云计算基础架构供应商，也最有可能首先采用这种大规模重启模式。请放心，AWS不会是最后一个。
随着企业越来越多地依赖于AWS、微软Azure、谷歌和IBM的SoftLayer(这只是几个例子，还有惠普、Oracle、Rackspace等)之类的云计算供应商，应该有一些标准的方法来处理这些问题。
美国东部时间下午4:40分最新消息：AWS在一篇博客文章中表示只有少量用户会受到影响，不过该公司也承认重启带来了不便。AWS表示：
如同我们在写给受到影响的小部分用户的邮件中和论坛上解释的那样，需要更新的实例需要对系统的底层硬件进行重启，几分钟之内就可以安装好补丁程序，主机也可以完成重启，之后就可以接着使用了。
虽然绝大多数软件更新无需重启，但是某些特定类型的更新是需要重启系统的。需要重启的实例重启的时间会被错开，这样就不会同时有两个地区或者可用地区受到影响，所有的数据都会被保存，并且自动完成配置。绝大部分用户在重启过程中不会遇到重大问题。我们理解对于一小部分用户来说，重启会非常不方便;如果不是非常重要和急迫的更新我们不会让我们的客户忍受不便。
那些不能确定自己是否会受到影响的客户可以到EC2控制程序中查看“事件”，其中会列出他们的AWS账户即将出现的所有实例重启。
RightScale的情况可能是一个非常好的起点，对管理重启和最佳实践进行思考。理想情况下，亚马逊应该有一个系统，万一客户无法推迟重新启动的时候，在系统停机维护期间，他们可以自动地被转移到另一个可用的区域(不收取任何费用)。
就像微软最终形成了在“补丁星期二”进行安全更新一样，AWS也会按照自己的节奏解决这个问题。
这里的困难在于AWS无法提前预知何时打补丁，直到准备工作完成才能确定。缺陷出现危及安全性是比停机严重得多的问题。一些客户表扬AWS能够进行如此大规模的重启来解决安全问题，另一些人则大喊大叫着有意见。
重新启动的时间彼此错开，这样AWS的客户就能够建立冗余。然而，AWS在重启的节奏上可能没有给客户足够的提醒。
这位客户在AWS论坛上很好地总结了这个问题：
对于我们来说，这当然是个大问题。按照计划，我们目前有超过100个实例要进行重启，我们也没办法在获得通知后这么短的时间内监视所有受到影响的服务。事实上，整个服务器集群计划同时进行重启，尽管它们处于不同的AZ，相当于出现了一个影响整个地区的事件。只提前两天进行通知我们不可能为此做好准备。
AWS的反应是不可能重新安排重启时间，因为它们是“非常急迫的安全和操作补丁。”
这是一个难题。随着云计算成为事实上的计算系统，这些问题将需要得到解决。在未来，我们将会看到云计算中也采用星期二补丁的模式。
