
I hear it everywhere. And it’s wrong.
“We have to get out of AWS.” “Azure is a security risk.” “As long as we’re with a US hyperscaler, we’re not sovereign.” I encounter these statements in architecture reviews, in compliance discussions, at conferences. They sound decisive. They feel right.
And they’re still wrong.
Not because the desire for independence is misguided. That desire is legitimate and important. But because exit and sovereignty are two completely different things — which our industry constantly conflates.
“Those who don’t know what they have cannot know what they depend on. And those who don’t know that don’t make sovereign decisions — no matter where they migrate.”
WAF++ Sovereign Pillar · SOV-010
Exit without visibility is not a step toward sovereignty. It is a step toward a new dependency — one that you now have to operate yourself, without the managed-service depth of a hyperscaler, without dedicated teams, and without the infrastructure expertise these companies have built up over decades.
What really happens during an exit
Let’s be concrete. Technically, an exit is possible — that’s undisputed. Kubernetes runs everywhere. Terraform abstracts providers. The open-source ecosystem with OpenStack, Ceph, and Cilium is mature.
But when you exit RDS, someone has to operate PostgreSQL HA themselves. Failover, backups, security patches — who does that at 3am? When you exit S3, you need an object storage team. When you exit CloudFront, you build your own CDN logic. When you exit IAM, you need your own PKI.
These are not theoretical problems. They are operational realities that become visible exactly when something breaks — and usually too late.
From the field: A European government agency worked for 3 years on an AWS exit. Afterward, they found that 60% of the original compliance requirements were still not met by the new on-premises solution. The problem was never the provider. It was the missing governance framework — which was still missing after the exit.
That’s not an isolated case. It’s the pattern. Without inventory, without controls, and without documented dependencies, you trade one known dependency for several unknown ones. That’s not more sovereignty — that’s more complexity with less oversight.
Sovereignty is not a question of the provider. It is a question of visibility.
What sovereignty really means
Here is the thesis that WAF++ represents — and it’s uncomfortable because it means more work than a migration project:
Sovereignty is a continuous system property, not a destination.
It doesn’t arise from canceling a contract. It arises from knowing at any point in time what you have, why you use it, how you depend on it — and how you can get out if you must.
That means: Inventory — every resource, every dependency, every proprietary service documented. Controls — governance requirements defined as YAML, machine-checked, versioned. Portability as a decision — not every workload must be portable, but every decision about it must be conscious. And public transparency — decisions, votes, and roadmap changes visible to everyone.
When all of this is in place, you are sovereign. Regardless of whether you run on AWS, Azure, GCP, Hetzner, or your own hardware.
And yes: that’s harder than an exit. An exit ends. Governance never ends. But that is exactly the point — sovereignty is not a project. It is an attitude.
When exit is still the right answer
WAF++ does not fundamentally reject exit. There are legitimate scenarios:
Exit makes sense when data localization laws explicitly exclude US companies as processors. When the organization has the operational maturity to permanently self-operate managed services. When a complete cost-benefit analysis supports the move.
Exit is the wrong answer when it happens as a reaction to a headline. When no inventory exists. When no dedicated platform team is standing by. And when exit serves as a substitute for governance — as if a provider change were the same as a governance framework.
The decisive question is not: “Where do we run?” The question is: “Do we know what we’re doing — and can we prove it?”
What this has to do with the Cloud Native Conference
On May 13th in Frankfurt, this exact question will land on stage. The panel discussion “Does sovereignty eat cloud-native for breakfast?” brings two positions head to head: the cloud-native enthusiast who says innovation needs the big hyperscalers, and the exit advocate who says their path was without alternative.
WAF++ is neither side. We are the framework that enables the community to answer this question for themselves — with evidence, not ideology.
In the Deep Dive (14:20) we’ll show live: What does a WAF++ control look like? How does Terraform run as a policy engine? How does an organization get from “no idea where we stand” to “fully auditable” in 90 days — without migrating a single workload?
If that interests you: come by. Bring your hardest questions.