Buying a second service is not the same as buying a separate failure path. In the account retained from AWS, an S3 dependency in dashboard administration prevented individual service updates during the February 28, 2017 incident. AWS used Twitter and banner text instead. For a buyer reviewing that event on a March 4 retrospective basis, administration belongs in the purchasing questions. [aws]
Statuspage’s account exposes another layer. It says core incident, status and notification functions continued, but S3-hosted styling files and images damaged appearance and slowed loading. That is not the same failure AWS describes. It does show why a vendor’s brand alone cannot reveal which parts of its service depend on the same infrastructure as the buyer’s application. [atlassian]
Our proposed procurement questionnaire would separate status-page administration, readable page delivery, styling and images, and notification delivery. For each, request the infrastructure dependency, a failure test and the fallback route; mark undisclosed or untested answers unknown. Ask how incident history and recipient records could be exported on exit. That last question tests a possible switching cost, not a cost measured by these accounts. [aws][atlassian]
A buyer could then compare which dependencies an alternative actually removes, and which it merely relocates behind a different invoice. The proposal does not favor a named competitor or establish prices, concentration or migration. Functional survival in Statuspage’s self-report deserves weight alongside its presentation problems. AWS’s page is currently undated, so its remediation statements cannot be treated as a verified March 4 purchasing option. [aws][atlassian]
Source documents
- Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Regionhttps://aws.amazon.com/message/41926/
- A bird’s-eye view of the Amazon S3 outagehttps://www.atlassian.com/blog/statuspage/a-birds-eye-view-of-the-amazon-s3-outage