如果有人对Amazon Web Services在保持商业网站平稳运行中的关键作用有任何疑问，那么该问题在2月28日该公司的S3存储服务的一部分关闭时得到了明确的答复。这次故障使从Apple到Zendesk等公司运营的数十种Web服务消失了。
令许多用户感到沮丧的是，应该报告其Web服务运行状况的Amazon AWS仪表板报告了一切正常运行(即使显然不是)。这样做的原因是，仪表板依赖于Amazon的S3存储，无法接收有关中断的更新信息。
AWS承认存在问题，并承诺保持客户更新。但是更新在下午中旬停止了。AWS团队的最后一条推文是：“对于S3，我们认为我们了解根本原因，并且正在努力进行修复。所有服务的未来更新都将显示在仪表板上。”此前，该公司曾承诺在Twitter上进行更新。
但是，一旦公司在其数据中心所在的北弗吉尼亚州的位置再次运行了S3服务，Service Health Dashboard就开始准确报告情况。
那时，位于该数据中心状态报告中的服务表明该问题已解决。AWS在下午2:19报道说，“在太平洋标准时间上午9:37到下午1:57之间，我们在与其他AWS服务进行通信时，在US-EAST-1地区中API网关请求的错误率提高了。部署新的API或修改现有的API也受到了影响。问题已解决，服务正常运行。”
对仪表盘进行仔细检查后发现，位于亚马逊北弗吉尼亚州的某些服务可能仍然微不足道，但在其他方面看来它仍然可以正常运行。
那么，Amazon S3服务实际上发生了什么?该公司还不是很好，但是它对API网关请求的错误率升高的评论表明该问题与基础架构有关，这可能是路由器问题。
但是，当然，这只是一个猜测。但是，最近许多大规模的服务中断(例如航空公司预订系统)似乎都归结为路由器问题，因此做出这样的假设是合理的。另外，路由器更新经常是此类问题的根本原因。亚马逊没有说出问题的真正原因是什么，所以它可能是从黑客入侵到配置问题。我们只是不知道。
我们确实知道的一件事是，AWS及其S3服务是问题的一部分，但这不是因为它不可靠。实际上，Amazon的服务是如此可靠，以至于其客户对AWS的依赖程度可能比其应有的程度更高。从大多数客户的角度来看，AWS永远不会失败，因此他们不认为需要计划停机。
当然，除了它是什么时候。然后，正如我们看到的那样，客户几乎没有任何更新和解释。但是，缺乏解释可能会令人讨厌，客户真正需要的是重新开始工作。这需要一些计划。
该计划的第一阶段必须是为您保留在S3存储服务中的项目找到备用存储位置。这可能意味着将备份保留在另一个区域的S3存储中，或者可能意味着完全使用另一个存储服务。这样，如果S3存储出现故障，则可以无缝切换到其他服务。
理想情况下，Amazon可以在其S3产品中提供冗余存储，因此，如果该服务像2月28日那样发生故障，则数据请求将自动路由到另一个站点。该计划的潜在问题是，如果冗余依赖于还存储在AWS中的信息，那么当区域出现故障时，冗余也是如此。
但是，假设亚马逊可以避免犯这种错误，并且我确信该公司可以做到，那么它就有一种很好的方法来保护客户，使其不会犯同样的错误，即假设亚马逊永远不会倒下。
更好的方法是假设AWS和所有其他云服务都将崩溃，然后计划解决方案。实际上，这样的假设是良好的安全实践。冗余对于确保您的数据始终无故障可用非常重要。
这就是为什么现有数据中心具有冗余服务器，冗余网络路由器和电源的原因。这也是为什么他们拥有比实际所需更多的发电机来保持数据中心正常运行的原因。
一些数据中心甚至超出了对可靠性的追求，甚至达到了拥有多余的冷冻水库的程度，因此不太可能损失系统冷却剂。拥有冗余数据存储库只是确保可以交付客户所需信息的一部分。
借助AWS及其高度的可靠性，很容易忘记这样的课程，但它们仍然很重要。