The February 28, 2017 S3 incident affected Northern Virginia, identified by AWS as US-EAST-1. For this March 4 retrospective, the useful question is what a recovery notice actually covers. AWS’s retained account describes an index holding object-location information and a placement system assigning storage for new objects. Those components did not finish recovery together. [aws]

A plain-language diagram could put the index first, with branches to reading, listing and deleting objects. Writing a new object would pass through a second box, placement, which also needs the index. AWS reports normal read, list and delete operations by 1:18PM PST on February 28; placement recovery finished at 1:54PM PST. Some dependent services still had backlogs. [aws]

Statuspage supplies a separate distinction for the diagram: communication functions versus presentation. Its account says incident creation, status updates and notifications continued, while S3-hosted styling files and images caused appearance and loading trouble. A rough-looking page therefore need not mean its notification function failed. Equally, this self-report does not establish how any particular reader experienced the service. [atlassian]

This diagram is an editorial explanation, not a live availability test. A normal read response would leave two unanswered checks: whether writes work and whether the dependent application has cleared its backlog. Keep page readability and communication functions on their own branch. AWS’s current page is undated; the exact text and remediation availability by March 4 remain unestablished. [aws][atlassian]

Source documents

  1. Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Regionhttps://aws.amazon.com/message/41926/
  2. A bird’s-eye view of the Amazon S3 outagehttps://www.atlassian.com/blog/statuspage/a-birds-eye-view-of-the-amazon-s3-outage