What the October 2025 AWS Outage Told Banks About Cloud Concentration Risk

On the morning of 20 October 2025, people who bank with Lloyds Bank, Halifax and Bank of Scotland found their apps and online banking playing up. None of the three banks had a fault of its own. The trouble sat with Amazon Web Services, which pointed to a problem on some of its US servers. Services came back online later that day.

The outage took down a long list of apps and websites around the world, so banks were only one part of the story. But they are the part regulators care about most. GlobalData estimated that up to 25% of UK consumers hold an account with Lloyds or its subsidiary brands. That is a lot of people affected by a fault in another company's data centre on another continent.

So should banks be worried about the cloud? Not exactly. They should be worried about how they use it.

Concentration Is the Real Exposure

Large cloud providers generally run more resilient infrastructure than most banks could build on their own. The issue is concentration. When a big share of the financial system relies on a handful of providers, and individual banks put critical services in a single region of a single provider, a local fault can become a national banking outage.

European regulators have been working on this for a while. The Digital Operational Resilience Act, better known as DORA, began applying in January 2025. In November 2025, the three European Supervisory Authorities published their first list of 19 critical ICT third-party providers to the financial system, and Amazon Web Services, Google Cloud and Microsoft were all on it. Those providers now face direct oversight of their governance, risk management and resilience.

That oversight helps. But it doesn't move accountability away from the banks. A bank still has to show that its own important services can keep going when a provider has a bad day.

Resilience Is Decided at Design Time

How a bank fares in an outage like this is mostly settled long before the outage begins. Where do the workloads run? How many regions do they span? What happens to the mobile app when one dependency stops responding?

A few design decisions make a real difference.

Spread critical services across more than one region, and test failover regularly instead of once a year. A failover plan that has never run under real load is closer to a hope than a plan.

Map dependencies properly. An app may run in several regions while quietly relying on an identity service, a database or a DNS setting that sits in only one.

Design for partial service. If a balance check works but a payment can't be made, the app should say so clearly. People cope much better with a limited service than with a screen that just keeps loading.

Consider multi-cloud only where it earns its cost. Running the same service across two providers adds complexity, and complexity causes outages of its own. For many banks, a well-built multi-region setup on one provider is a sounder place to start.

This is the kind of work that good cloud engineering services concentrate on. Moving workloads to the cloud is the easier half of the job. Building them so they degrade gracefully when part of the cloud goes dark is harder, and it matters a great deal more on a day like 20 October.

A Better Question for the Board

After the outage, plenty of bank boards will have asked whether something similar could happen to them. The answer is almost certainly yes, so a narrower question is more useful. Which of our important business services would stop if one region of one provider went down for six hours, and how do we know?

If the answer comes from a recent test, the bank is in a decent position. If it comes from an architecture diagram, there is still work to do.

Author - Shefali Vasave

Shefali manages content marketing at Opus Technologies, a domain-native engineering partner for banks, payment providers, and fintechs, and writes on the various aspects of financial institutions navigating change in a real-time, digital-first world.