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:

1. 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.
2. 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.

From Snowballs to Snowmobiles: AWS’s Scale Problem

When large enterprises — particularly banks — first move to Amazon Web Services, they face an immediate physical challenge: how do you transfer petabytes of legacy data into the cloud? AWS solved this with its Snowball appliance: a ruggedized, encrypted storage device shipped to a client site, filled with data on-premises, then physically transported to an AWS data centre for upload.

As customer data volumes grew, even the Snowball Edge (with higher capacity than the standard Snowball) was no longer sufficient for some enterprises. AWS’s response was characteristically blunt: mount a purpose-built, data-centre-grade container on a tractor-trailer. They called it a Snowmobile. The customer plugs it into their data centre, the data is encrypted and ingested, the truck drives to an AWS facility, and the data is uploaded and re-encrypted. It is a vivid illustration of how seriously AWS treats the mechanics of large-scale data migration.

AWS and Azure Dominate Financial Services

Since AWS relaunched its commercial cloud platform in 2006, it has become the de facto standard for enterprise cloud infrastructure. By 2017, AWS revenues had reached approximately $14 billion annually, up from roughly $10 billion the prior year, and the platform counted Nasdaq and all Fortune 50 companies among its customers.

Financial services adoption lagged other industries — banks are famously conservative — but the pace accelerated dramatically in the mid-2010s. Major institutions including Citigroup, JPMorgan, and HSBC moved workloads onto AWS. Regulators themselves followed: the UK’s Financial Conduct Authority (FCA) and the US Financial Industry Regulatory Authority (FINRA) became cloud customers.

Microsoft Azure pursued a parallel strategy. By mid-2017, Microsoft claimed that 85% of systemically important banks had signed on to Azure, ranging from established names like UBS to new entrants like ClearBank.

A survey of more than 40 London fintechs at the time found that the vast majority ran on AWS, with most of the remainder on Azure, and only three using both.

The Systemic Risk Question

The concentration of financial infrastructure in two cloud providers triggered a familiar debate. In June 2017, the Financial Stability Board (FSB) raised concerns about the systemic risk created by banks’ dependence on third-party providers, specifically calling out cloud computing and data services. The FSB urged local regulators to assess whether tighter rules were warranted, and acknowledged that it lacked sufficient data to draw firm conclusions — one proposed measure was requiring banks to disclose which third-party providers they rely on.

“The moment that there is a security flaw or an availability flaw within the Amazon fabric, for us that is a catastrophic failure.”

Gavin Jackson, Head of EMEA, Amazon Web Services

The analogy to the 2008 financial crisis is not merely rhetorical. Systemically important financial institutions (SIFIs) were considered too big to fail because their collapse would cascade through the global economy. The question regulators began asking in 2017 was whether AWS or Azure had achieved a comparable degree of systemic importance — not through financial leverage, but through operational dependency.

Why Multi-Cloud Is Harder Than It Sounds

The obvious mitigation for concentration risk is diversification: require financial institutions to spread workloads across multiple providers. In practice, this is more complicated than it appears.

Modern cloud platforms are not simply storage and compute rentals. AWS and Azure each offer deeply integrated ecosystems of services — databases, analytics pipelines, machine learning frameworks, security tooling, identity management, and more. A financial institution that builds its core platform on AWS-native services (such as RDS, Redshift, or SageMaker) cannot simply replicate those workloads on Azure without significant re-engineering. The two platforms’ APIs, data models, and operational tooling are fundamentally different.

Andrew White, co-founder of FundApps, put it plainly: running on both AWS and Azure would “pretty much require near duplication of all operational infrastructure and staff and would be a nightmare for any company, large or small.” Charlie Henderson, co-founder of Feedstock, noted the same problem from the vendor side: when a bank insists on Azure and his product is built on AWS, “you have to rebuild it, which is very costly.”

Gavin Jackson of AWS pushed back on the framing of “lock-in” altogether, arguing that AWS services are built on open standards and open-source software, making it technically possible for customers to leave. Microsoft’s Richard Peers acknowledged that switching difficulty is a “real issue” while arguing that the risk calculus must be proportionate — a small fintech representing 0.01% of UK payment volumes does not carry the same systemic weight as a clearinghouse or payment rail.

One company, Credit Benchmark, took a different path entirely, selecting CenturyLink as its cloud provider rather than AWS or Azure. Its CTO described the trade-off plainly: the ready-made managed services on the major platforms make life easier in the short term, but deepen dependency over time.

The Shared Responsibility Model and Its Gaps

Cloud providers operate on a shared responsibility model: the provider secures the underlying infrastructure, while the customer is responsible for securing everything they build on top of it — their data, their access controls, their application configurations, and their network rules.

“If you are architecting your applications for a single data centre in a single availability zone in a single region, then you could argue there’s an accident waiting to happen.”

Gavin Jackson, Head of EMEA, Amazon Web Services

Javvad Malik, security advocate at AlienVault, identified a persistent and dangerous misunderstanding in the financial sector: the belief that moving to AWS transfers security responsibility to Amazon. “‘We put it on Amazon so it must be secure,” he said, is a mindset that is “wrongly embedded” among bank management. It ignores firewalls, operating system hardening, and database configuration — all of which remain the customer’s domain.

Malik also flagged a structural skills gap: cloud security expertise is not uniformly distributed across financial institutions’ IT teams. Where that knowledge gap exists, risk follows. A further complication is outsourcing — some banks delegate management of their AWS accounts to third parties, adding another link in the chain and another potential point of failure.

Ankur Modi, CEO of cybersecurity startup StatusToday, noted that even the most robust infrastructure is not immune to outages. In February 2017, a misconfigured command during routine maintenance of AWS S3 in the US-EAST-1 region caused a significant outage that disrupted a wide range of services — including Business Insider, Quora, Medium, and AWS’s own status dashboard — for several hours. The incident was caused by human error, not a security breach, but it illustrated that availability risk is real regardless of the provider’s security record.

AWS’s Argument: Resilience by Design

AWS counters concentration risk arguments with its global infrastructure architecture. The platform operates across multiple geographic regions, each divided into multiple isolated Availability Zones — physically separate data centres within a region, connected by high-bandwidth, low-latency links. Customers who architect their applications to span multiple AZs and multiple regions gain a degree of resilience that most on-premises deployments cannot match.

Jackson argued that AWS does not access customer data — it is always encrypted and controlled by the customer, who determines the region and replication strategy. He declined to disclose AWS’s security investment figures but pointed to over eleven years of operation without a major security breach of the underlying infrastructure as evidence of the platform’s trustworthiness.

The broader argument from both AWS and Microsoft is that, for most financial institutions, running on a major cloud provider is more secure than maintaining aging on-premises infrastructure with limited security budgets and staff. The pendulum, as Jackson described it, had shifted: banks were no longer asking “How do I think about security in the cloud?” but rather “I have to get into the cloud, because of security.”

Key Takeaways for DevOps and Platform Teams

• Shared responsibility is not optional. Cloud providers secure their infrastructure; you secure everything you build on it. Misconfigurations, weak IAM policies, and unpatched OS images are your problem, not AWS’s.
• Multi-AZ and multi-region architecture matters. Deploying to a single availability zone in a single region exposes you to outages like the 2017 S3 incident. Design for failure from the start.
• Multi-cloud is architecturally expensive. True workload portability between AWS and Azure requires avoiding provider-native managed services and accepting significant operational overhead. Evaluate this trade-off honestly before committing.
• Vendor lock-in is real, even with open-source tooling. Using open-source software does not eliminate lock-in if your operational tooling, IAM, networking, and data services are tightly coupled to one provider’s abstractions.
• Concentration risk is a governance issue, not just a technical one. For regulated financial institutions, documenting third-party dependencies — including cloud providers — is increasingly a regulatory expectation, not merely a best practice.
• Skills gaps are an underestimated risk vector. Migrating to the cloud without investing in cloud-native security expertise creates exposure regardless of the provider’s own security posture.

Where the Debate Stands

The concentration risk debate in financial services cloud has not been resolved — it has intensified. Regulators in the UK, EU, and US have continued to develop frameworks for operational resilience that explicitly address cloud dependency, including requirements for exit planning and third-party risk management. The FSB’s concerns about systemic risk from cloud concentration remain active policy questions.

For DevOps and platform engineers working in or adjacent to financial services, this debate has direct operational implications. Architecture decisions that seem purely technical — which managed database to use, how to structure IAM, whether to use a provider’s native container orchestration — carry regulatory and systemic risk dimensions that teams need to understand and document.

As Jackson noted in 2017, the cloud market — even dominated by two players — was still early. That remains true. But the infrastructural and regulatory stakes have only grown since.