AWS现在可以让实例从多种错误中恢复了，但这并不会代替真正的云弹性应用设计。
AWS EC2实例现在可以经由CloudWatch从某些错误状况中恢复，但这个功能并不能完全替代云弹性应用架构。
自动恢复允许用户在Amazon Web Service（AWS）的CloudWatch监测服务中设定临界值。如果操作系统在Amazon那方出了问题，例如底层的硬件故障，系统断电，网络连接断开或物理机的软件问题等，实例将会原封不动的依照它的实例识别码，IP地址，弹性块存储（EBS）附件和其他设定细节来自动恢复。
自动恢复暂时只适用于美东（维吉尼亚）区域的C3，C4，M3，R3和T2线的实例，虽然在AWS官方博客的一个帖子有提到将会很快在更多区域提供这个服务。实例必须要在一个虚拟私有云（VPC）之内运行并附加在一个EBS卷上才能使用自动恢复的功能。使用自动恢复功能的用户将依照CloudWatch的价格表来收费，但对于恢复过程中使用的EC2或EBS资源是不收费的。
这个概念对于AWS一贯强调的，在应用中而不是在基础架构层面建立云弹性的说法难免有点背道而驰，但它不会成为一个完全将应用弹性抹杀掉的捷径，根据Glenn Grant，一家位于波士顿的云咨询和管理服务供应商，G2 技术集团公司的CEO表示。
G2 技术集团也提供了类似的功能，通过其针对AWS的管理服务，包括监控软件来检查AWS云的健康度，并在必要时重启实例。
“我认为这个功能对于过程的自动化很有帮助，”他说道。“但是，我们需要评估一下，才能完全了解它的检查方式和临界点，这样才不会在不必要的时候重启实例。”
比如，Grant想知道网络流量很大会不会被误判成连接的完全断开，或者一个DoS攻击的情景是否会导致某个实例不断重启。但自动恢复装有自适应调节的控制器来确保同一实例不会被不停的恢复。
一些业界观察者会提出一个问题：为什么Amazon没有早点提供这个功能？“我一直很好奇为什么他们没在几年前就做这件事，”Carl Brooks，一名位于波士顿的451 Group的分析师说道。“我猜那是因为他们曾经这样来告诉客户要‘自己动手，丰衣足食’。”
总是会有这样的风险，用户会默认将这个功能当作一种“快捷”的围绕恰当弹性的应用架构的方式，但这些问题和做法大家已经司空见惯了，Brooks说道。
另外也有一部分人则质疑自动恢复强制使用EBS的必要性。
“如果某个EBS卷在恢复的过程中损坏了怎么办？”一名位于马萨诸塞州Cambridge的Forrester Research的分析师James Staten说道。AWS拒绝对这个问题发表公开评论。
不论如何，当那些技术水平没那么高的新顾客群采用云计算时，这种功能将很有必要，根据Staten的说法。云技术采纳的第一波用户大多数是那些很乐意编写自动化的基础架构恢复功能脚本或将其融入到应用中的DevOps族群，但最新的一代用户可能不具备这种程度的云计算专业或运营经验，他说道。
AWS的几个竞争者都已经提供类似的恢复功能了。Google经由他们的管理VM服务来管理Google计算引擎虚拟机的可用性，进而巩固了他们的应用引擎平台即服务，Rackspace的云服务器是由支持人员来监测并确保他们的可用性。VMware的vCloud Air Service也会在主机故障发生时提供VMware的Live Migration功能。微软的Azure则有服务治愈功能，可以自动侦测有问题的节点并将虚拟机移动至新的主机上。
原文链接：http://www.searchcloudcomputing.com.cn/showcontent_87717.htm
