This article is based on a 2017 report originally published by fnlondon.com, drawing on interviews with AWS and Microsoft executives, fintech founders, and security researchers. Some figures and market conditions have evolved since publication.
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.