This article is based on reporting originally published by Financial News (fnlondon.com) in August 2017, with community discussion sourced from Hacker News.
A Single Point of Failure for the Internet?
Amazon Web Services (AWS) has become so deeply embedded in global internet infrastructure that its potential failure is no longer just a business continuity problem—it is beginning to look like a systemic risk. That concern, long discussed quietly in engineering circles, moved into broader public view in mid-2017 when Financial News revealed the scale of AWS adoption in the financial sector and the tech community responded with alarm.
Discussions on Hacker News—the community forum run by Y Combinator, the startup accelerator behind companies such as Dropbox and Airbnb—surfaced a range of concerns from working engineers about what a serious, prolonged AWS outage would actually mean in practice.
How Dominant Is AWS?
AWS relaunched as a commercial cloud platform in 2006 and has since grown into the dominant infrastructure provider across multiple industries. Its customer list, as reported by Financial News, includes:
- Major banks: Citigroup, JPMorgan, and HSBC
- Stock exchange operator Nasdaq
- Media platform Netflix
- The UK’s Financial Conduct Authority (FCA)
- 100% of the Fortune 50 companies (as claimed by Amazon at the time)
This level of concentration—where a single vendor underpins critical systems across finance, media, government, and e-commerce simultaneously—is what prompted the “too big to fail” framing borrowed from the 2008 banking crisis.
What Engineers Are Saying
Hacker News contributors were direct about the downstream impact of an extended AWS outage. User Mgkimsal wrote:
“How many government and/or university systems would be unable to function because of direct or indirect dependencies on AWS-related services? [Amazon] going down for, let’s say four days, would cause big havoc on so many projects and systems I know of. I’m pretty sure most people have no clue how much of their data and systems functionality is reliant on AWS-related services.”
User Fenwick67 expanded the picture beyond consumer inconvenience:
“If AWS went down hard, it would be more than just ‘I can’t watch Netflix’. Some people wouldn’t be able to do their computer work, send or receive emails, others might not receive their paychecks or be able to pay bills.”
User Dalbasal framed the concern more broadly:
“It seems reasonable to start worrying about the fragility potentially introduced by these massive internet infrastructure companies.”
One contributor, Peteretep, raised the national security dimension, noting that concentration of critical infrastructure in a small number of physical data centers could make those facilities high-value targets—a concern that goes beyond typical business risk discussions.
The February 2017 S3 Outage: A Real-World Warning
The debate is not hypothetical. In February 2017, a human error during routine maintenance of AWS’s S3 object storage service in the US-East-1 region triggered a significant outage that lasted several hours. Among the affected services were Business Insider, Quora, Medium, and notably AWS’s own service health dashboard—making it temporarily impossible to even check the status of the outage through official channels.
This incident illustrated two important points for DevOps teams:
- Indirect dependencies are invisible until they fail. Many services affected by the S3 outage were not direct AWS customers—they relied on third-party tools, libraries, or SaaS products that themselves depended on S3.
- Single-region architectures amplify risk. Organizations that had not configured cross-region replication or multi-cloud failover were fully exposed.
Amazon’s Position
Gavin Jackson, then head of EMEA at AWS, told Financial News that the platform operates data centers across multiple countries and regions, and that customers can—and should—replicate data across centers to protect against localized failures. He stated:
“I can pretty confidently say that I don’t think that there’s any other company on the planet that has as many people thinking about security every day.”
This is technically accurate—AWS does offer the tools to build highly available, multi-region architectures. The problem critics raise is not that those tools don’t exist, but that many organizations have not implemented them, either due to cost, complexity, or simply not understanding the dependency chain running beneath their systems.
Regulatory Concern: The Financial Stability Board Weighs In
The concern is not limited to the engineering community. The Financial Stability Board (FSB), in a June 2017 report titled Financial Stability Implications from FinTech, noted that third-party service providers are “quickly becoming more prominent and critical, especially in areas of cloud computing and data services.” The FSB called on local regulators to evaluate whether tighter rules governing concentration risk in cloud infrastructure were needed.
This regulatory angle is significant. Financial institutions already operate under strict operational resilience requirements, and supervisors in the UK (FCA, PRA) and EU (EBA, DORA framework, introduced later) have since moved toward explicit rules governing cloud provider concentration and exit strategies for regulated firms.
Practical Takeaways for DevOps and Platform Teams
Whether or not AWS is “too big to fail” in a regulatory sense, the underlying engineering problem is real and actionable. Teams relying heavily on any single cloud provider should consider the following:
- Map your dependency graph. Identify not just your direct AWS usage but the third-party services your application depends on that are themselves AWS-hosted.
- Design for multi-AZ as a minimum. Single Availability Zone deployments are inappropriate for production workloads with meaningful SLAs.
- Evaluate multi-region for critical paths. Cross-region replication of data and active-active or active-passive failover for critical services raises resilience significantly, at added cost and complexity.
- Test your failover. Documented failover procedures that have never been tested in production are not reliable failover procedures.
- Consider multi-cloud selectively. Full multi-cloud is operationally expensive, but abstracting storage or DNS layers can reduce lock-in for specific critical components.
- Monitor for indirect dependencies. Services like npm, Docker Hub, GitHub, and many SaaS tools run on AWS. An outage can affect your CI/CD pipeline even if your application itself is elsewhere.
Conclusion
The concentration of critical internet infrastructure in a small number of hyperscale cloud providers is a genuine systemic risk—not a theoretical one. The February 2017 S3 outage demonstrated that cascading failures can affect organizations with no direct relationship to the root cause. For DevOps engineers and platform architects, the lesson is that availability architecture must account for provider-level failure, not just instance or zone-level failure. For regulators, the question of how to govern this concentration remains open and increasingly urgent.
Original reporting by Financial News (fnlondon.com), August 2017. Community discussion via Hacker News.