I had a catch-up recently with the CEO of a European fintech. Sharp operator, solid platform. Cloud-native, well-architected, humming along nicely.
Then, almost as a thought experiment, he asked:
“If our regulator told us to move off our cloud provider, how long would it actually take?”
He was not asking out of nowhere. He had been watching the same signals many of us have.
Under DORA, the ESAs have designated 19 “critical” ICT third-party providers for direct oversight. The list is heavily weighted towards large global providers, including the big US hyperscalers and major market infrastructure names.
Add in the broader trend that governments and regulators are talking more openly about digital sovereignty, strategic dependency, and control of critical infrastructure. Not as ideology. As risk mitigation.
So, I asked him:
Who is your provider?
AWS.
And which of your critical services are built on AWS-native managed services?
Most of them.
At that point, the discussion stops being “migration planning” and becomes what it really is which is service rewrite planning.
Because if your core workflows are built on provider-native primitives, you are not lifting and shifting workloads. You are rebuilding behaviour.
He had not been careless. He had made rational trade-offs. Managed services bought speed and reliability. The relationship was strategic. Long-term. Sensible.
What he had not stress-tested was the scenario where the provider relationship itself becomes the risk. Not because of service quality. Because of jurisdiction and policy uncertainty.
Then we hit the question that stopped both of us:
If you had to exit AWS, where would you go?
The first answer is always the same: Azure or Google.
Then comes the pause.
Because if the trigger is geopolitical or jurisdictional rather than technical, moving from AWS to Azure does not exit the risk. It just changes the logo.
And if you needed a genuine European alternative, you quickly run into an uncomfortable reality. The European “hyperscaler” market still does not match the managed-service depth, ecosystem maturity, and enterprise adoption patterns that most firms have architected around.
That is not a criticism. It is just the current state of play.
Those questions, and more, have kept replaying in my head.
The ground is shifting
That conversation did not happen in a vacuum.
Across Europe, the direction of travel is clear – digital platforms are being treated more like governed infrastructure.
Recent examples are telling:
France is rolling out a sovereign video platform (“Visio”) across government, replacing Teams/Zoom-type tooling, hosted on French infrastructure.
The digital euro is being framed explicitly as reducing dependency on international card schemes and strengthening Europe’s payments position.
SAP and Mistral have positioned a partnership around “sovereign AI” and European control of infrastructure and data.
Deutsche Telekom is explicitly pitching “hyperscaler power with European sovereignty” via T Cloud Public, targeting feature parity by the end of this year.
Dassault Aviation has selected Bleu (“cloud de confiance”) for collaborative tooling in an environment protected under European law.
Airbus is preparing a major tender to migrate mission-critical workloads to a “digitally sovereign” European cloud, explicitly linked to sovereignty concerns.
Microsoft has publicly acknowledged it cannot guarantee sovereignty against US legal demands under the Cloud Act, even with EU hosting.
None of these, individually, are earth-shattering.
Stack them up and you get a simple conclusion, the assumptions that shaped the last decade of enterprise platform decisions are being rewritten.
Not just in the EU. The UK and Switzerland are watching the same signals too, each with their own regimes and priorities, but the same underlying concerns of concentration risk and strategic dependency.
Cloud-native is not the problem. Provider-native is.
I say this as someone who built a cloud-native SaaS trading platform from scratch.
Cloud done well with portable workloads, clean boundaries, open standards, interoperable architecture, is still one of the smartest moves a firm can make.
But somewhere along the way, “cloud-native” quietly became “provider-native”.
Your event bus is proprietary. Your serverless compute is proprietary. Your identity model is baked in. Your state management, retry logic, and workflow semantics are all tightly coupled to one provider’s way of doing things.
And I do not just mean the APIs.
I mean the semantics: the delivery guarantees, the ordering behaviour, failure modes, the consistency assumptions your architecture has quietly absorbed over years.
That is how you end up with a platform that is fast to build and hard to leave.
And when the relationship itself becomes the risk, “hard to leave” stops being a technical detail. It becomes a board-level exposure.
The gap is real — but it is closing
Here is what gives me some optimism.
The market is responding. Sovereign infrastructure and “trusted cloud” programmes are attracting real capital and real customers. This is not aspiration anymore. It is deployment.
And the European tech community has more capability than it gives itself credit for. The bottleneck is not skill. It is coordination and demand clarity.
Too many teams are waiting for a perfect sovereign stack to appear fully formed. The practical path is to start building with what exists. Open standards, interoperable architecture, and genuine portability are not just good engineering principles anymore. In this environment, they are survival strategies.
What assumption-light actually looks like
I am not suggesting anyone rips out their cloud platform tomorrow. That would be daft.
But some of the old disciplines we were supposed to have outgrown are starting to look remarkably smart again.
Genuine separation between your control plane and your domain logic
Explicit data zoning and boundary enforcement
Stronger key and access sovereignty patterns
Dependency mapping as a maintained, living artefact, not a one-off exercise buried in a risk register
Resilience testing that includes third-party failure and constrained support
Portability and exit designed as real architectural capabilities, not just contractual clauses.
This is not anti-cloud.
Its pro-reality.
Four questions to assess your risk
Forget the glossy vendor presentations for a moment. Sit down with your team and ask:
What is our actual exit cost, not the theoretical one, if we had to move off our primary cloud provider in 12 months?
If we had to leave our current provider, where would we actually go, and does that resolve jurisdictional exposure, or just move it?
Which of our critical services depend on proprietary managed services, and what would it take to decouple them?
Do we know who owns the physical infrastructure our data sits on, and what jurisdictional obligations apply across the chain?
If those questions make you uncomfortable, good.
That is not paranoia.
That is where resilience starts.