On July 13, the UK started directly supervising four cloud providers. AWS, Microsoft Azure, Google Cloud and Oracle were designated Critical Third Parties, which puts them under the eye of the Bank of England, the PRA and the FCA. It is the first time the powers from the Financial Services and Markets Act 2023 have actually been used.
The reason is simple. A 2024 Bank of England and FCA survey found that Microsoft, Google and Amazon accounted for 73% of UK financial-sector cloud services. When that much of an economy runs on three companies, one bad outage stops being an IT incident and starts being a systemic event.
You might not run a bank. But the logic that pushed regulators to act is the same logic you should be applying to your own stack.
Concentration risk is not just a regulator's problem
Most teams pick a cloud early, wire everything to that provider's proprietary services, and never look back. Managed queues, provider-specific auth, a serverless runtime that only exists in one place. It feels productive because it is. You ship faster when you lean on the platform.
The cost shows up later, and it shows up all at once. A regional outage takes your whole product down. A pricing change lands on a service you cannot easily leave. An account gets flagged and suspended, and you discover your data and your identity layer live in the same place you just lost access to.
Regulators are now formalising a worry that builders have quietly carried for years: if one vendor going dark can take you with it, that is a design flaw, not bad luck.
What "designated critical" actually tells you
The designation does not mean these providers are unsafe. It means they are load-bearing for the entire financial system, so someone finally wants visibility into their resilience arrangements. Regulators can now request information, assess how these firms handle failure, and write rules specific to them.
Read that as a signal. The people whose job is to model catastrophic failure looked at cloud concentration and decided it needed direct oversight. If that is their conclusion about the infrastructure layer, your conclusion about your dependency on it should not be "it will be fine."
Architect so one provider going dark is survivable
You do not fix this by going multi-cloud on day one. That is expensive and slow, and for most teams it is the wrong first move. You fix it by making deliberate choices about where you are willing to be locked in.
- Separate your identity and data from your compute. If your auth, your database and your app all die together, you have no recovery path. Keep the pieces that hold state portable, even if compute stays on one provider.
- Use open interfaces at the boundaries. Postgres over a proprietary datastore. S3-compatible object storage. Standard container images. You can still run on one cloud. You just keep the door open.
- Write the exit runbook before you need it. Not a migration project. A one-page answer to "what do we do in the first hour if this provider is unreachable." Most teams have never written it, which is why the first hour is chaos.
- Know your real blast radius. Map which services fail together. A lot of teams think they are spread across three availability zones and find out during an outage that one control plane ties them all together.
The goal is not zero lock-in. It is knowing exactly what you are locked into and what it would cost to leave.
The builder takeaway
Regulation tends to lag reality. The UK moving cloud providers under supervision is the formal version of a lesson experienced teams already learned the hard way. Depending on a single vendor for everything is a bet, and you should know the odds before you place it.
Treat your cloud provider like any other dependency you cannot fully control. Useful, worth the leverage, and never something you let become a single point of failure without a plan.
We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!