Amazon的S3服务宕机事件无疑是送给Azure与谷歌、内部IT、混合云技术支持商以及多云网关产品的一份大礼。但在此之外，其亦暴露出Amazon客户在业务连续性与灾难恢复方面准备不足的问题。
我们当然可以将矛头指向Jeff Bezos，并抱怨AWS的表现令用户失望。然而我们同时应当意识到业务保障的重要意义，且不应将全部管理工作交由服务商负责。客户应当建立一套替代性或者混合云战略。事实上，可供选择的现有解决方案可谓多种多样。
S3（即简单存储服务）为Amazon公司推出的对象存储服务，立足于其AWS公有云。S3宕机事件发生于2月28日上午9：44（太平洋时间），当时其位于北弗吉尼亚州的热门数据中心（美国东一服务区）存储桶发生访问问题并导致错误率上升。对于众多用户而言，其数据在此阶段遭遇无法访问故障，且在持续五个小时的修复期间始终受到影响。另外，Nest视频与部分智能手机应用也受到影响。
对于众多S3应用开发商，AWS原本提供了双服务区数据冗余选项以防止此类宕机事故——但考虑到昂贵的成本投入，大部分开发商并未采用。
除了S3之外，另有其它一系列服务受到影响，具体包括Amazon Appstream 2.0、Athena、CloudSearch、Cognito、ECR (Docker容器注册表)、EMR、Amazon Elastic Transcoder、Elasticsearch Service、Glacier、Inspector、Kinesis Firehose、Lightsail、Mobile Analytics、PinPoint、Redshift、Simple Email Service、SWF、WorkDocs、WorkMail、Auto Scaling、AWS Batch、CloudFormation、CodeBuild、CodeCommit、CodeDeploy、Data Pipeline、Elastic Breanstalk、Key Management、Lambda、OpsWork Stacks以及Storage Gateway等同样处于该北弗吉尼亚州AWS基础设施内的服务。
目前大部分服务已经恢复正常，但仍有部分服务未能上线。具体情况非常复杂，下图所示为AWS EC2（北弗吉尼亚州）美国东一服务区给出的EC2运行状态历史记录：
来自AWS北弗吉尼亚州基础设施的EC2状态历史记录。
Amazon公司目前尚未解决这一重大事故的发生原因及过程：
AWS 发布状态更新
云计算巨头应当如何挽回损失？
对于Amazon而言，其显然需要将美国东一服务区进行进一步拆分以实现故障转移，而不再单纯依靠位于俄亥俄州的美国东二服务区。另外，其还需要拆分在线公共仪表板基础设施，从而确保其能够在美国东一服务区或其它服务区数据库发生故障时保持正常运作。
对于其它替代方案供应商，此次事故无异于一份大礼。Egnyte公司CEO兼联合创始人Vineet Jain在评论中表示：
互联网与云还远不完美。尽管很多用户认为我们云服务供应商的宕机事故几率已经很低，但问题总会出现，大家不应盲目乐观——Amazon的此次事故再次证明了这一点。无论您是一家因此导致无法进行正常交易的小型公司，还是因此影响到国际业务的大型企业，如果大家完全依赖于云，则其很可能对您的业务造成重大危害。
尽管宕机事故本身显示出AWS在行业内的巨大市场份额占比，但亦同时证明客户为何迫切需要一套混合型方案作为业务辅助。混合型方案仍然是最适合选择将业务交由云端打理的企业的解决方案，而且这类方案能够有效避免与此次事件类似的服务停机、经济损失以及多种其它问题。
很明显，公有云绝非一劳永逸的解决办法。事实已经证明将您的IT运营体系完全交给公有云供应商的数据中心——无论其规模多么巨大——都有可能带来风险。由此得出的结论则非常明确：支付额外冗余成本，从而为客户提供更为安心的使用体验。
回顾整次事件，可以肯定的是受到中断影响的每家客户都没有制定理想的业务连续性与灾难恢复规划。没错，Amazon让各位客户失望了，而这些企业也让自己的客户失望了。
