北京时间3月3日，AWS发布公告，解释2月28日上午出现在北弗吉尼亚（US-EAST-1）区域的服务中断事件。原文如下：
亚马逊简单存储服务（S3）团队当时在调试一个问题，该问题导致S3计费系统的处理速度比预期来得慢。太平洋标准时（PST）上午9：37，一名获得授权的S3团队成员使用事先编写的playbook，执行一条命令，该命令旨在为S3计费流程使用的其中一个S3子系统删除少量服务器。遗憾的是，输入命令时输错了一个字母，结果删除了一大批本不该删除的服务器。不小心删除的服务器支持另外两个S3子系统。其中一个系统是索引子系统，负责管理该区域所有S3对象的元数据和位置信息。这个子系统是服务所有的GET、LIST、PUT和DELETE请求所必可不少的。第二个子系统是布置子系统，负责管理新存储的分配，它的正常运行离不开索引子系统的正常运行。在PUT请求为新对象分配存储资源过程中用到布置子系统。删除相当大一部分的容量导致这每个系统都需要完全重启。这些子系统在重启过程中，S3无法处理服务请求。S3 API处于不可用的状态时，该区域依赖S3用于存储的其他AWS服务也受到了影响，包括S3控制台、亚马逊弹性计算云（EC2）新实例的启动、亚马逊弹性块存储（EBS）卷（需要从S3快照获取数据时）以及AWS Lambda。
S3子系统是为支持相当大一部分容量的删除或故障而设计的，确保对客户基本上没有什么影响。我们在设计系统时就想到了难免偶尔会出现故障，于是我们依赖删除和更换容量的功能，这是我们的核心操作流程之一。虽然自推出S3以来我们就依赖这种操作来维护自己的系统，但是多年来，我们之前还没有在更广泛的区域完全重启过索引子系统或布置子系统。过去这几年，S3迎来了迅猛发展，重启这些服务、运行必要的安全检查以验证元数据完整性的过程所花费的时间超出了预期。索引子系统是两个受影响的子系统中需要重启的第一个。到PST 12：26，索引子系统已激活了足够的容量，开始处理S3 GET、LIST和DELETE请求。到下午1：18，索引子系统已完全恢复过来，GET、LIST和DELETE API已恢复正常。S3 PUT API还需要布置子系统。索引子系统正常运行后，布置子系统开始恢复，等到下午1：54已完成恢复。至此，S3已正常运行。受此事件影响的其他AWS服务开始恢复过来。其中一些服务在S3中断期间积压下了大量的工作，需要更多的时间才能完全恢复如初。
由于这次操作事件，我们在做几方面的变化。虽然删除容量是一个重要的操作做法，但在这种情况下，使用的那款工具允许非常快地删除大量的容量。我们已修改了此工具，以便更慢地删除容量，并增加了防范措施，防止任何子系统低于最少所需容量级别时被删除容量。这将防止将来不正确的输入引发类似事件。我们还将审查其他操作工具，确保我们有类似的安全检查机制。我们还将做一些变化，缩短关键S3子系统的恢复时间。我们采用了多种方法，让我们的服务在遇到任何故障后可以迅速恢复。最重要的方法之一就是将服务分成小部分，我们称之为单元（cell）。工程团队将服务分解成多个单元，那样就能评估、全面地测试恢复过程，甚至是最庞大服务或子系统的恢复过程。随着S3不断扩展，团队已做了大量的工作，将服务的各部分重新分解成更小的单元，减小破坏影响、改善恢复机制。在这次事件过程中，索引子系统的恢复时间仍超过了我们的预期。S3团队原计划今年晚些时候对索引子系统进一步分区。我们在重新调整这项工作的优先级，立即开始着手。
从这起事件开始一直到上午11：37，我们无法在AWS服务运行状况仪表板（SHD）上更新各项服务的状态，那是由于SHD管理控制器依赖亚马逊S3。相反，我们使用AWS Twitter帐户（@AWSCloud）和SHD横幅文本向大家告知状态，直到我们能够在SHD上更新各项服务的状态。我们明白，SHD为我们的客户在操作事件过程中提供了重要的可见性，我们已更改了SHD管理控制台，以便跨多个AWS区域运行。
最后，我们为这次事件给广大客户带来的影响深表歉意。虽然我们为亚马逊S3长期以来在可用性方面的卓越表现备感自豪，但我们知道这项服务对客户、它们的应用程序及最终用户以及公司业务来说有多重要。我们会竭力从这起事件中汲取教训，以便进一步提高我们的可用性。
