13 Apr 2026 · governance cloud open source · 16 min read

Exit Is Flight. Not Freedom.

Sovereignty begins with visibility — not with migration. Those who flee the cloud without knowing what they have simply trade one dependency for more complexity.

Exit Is Flight. Not Freedom. — WAF++ at Cloud Native Conference 2026

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.

Figure 1 — What really happens during an exit? FIGURE 1 What really happens during an exit? TODAY Governed Cloud Database (RDS) Object Storage (S3) CDN (CloudFront) Identity & Controls ✓ 1 Team · clear · auditable Clear. Controlled. Sovereign. EXIT = Flight into Complexity AFTER EXIT Self-operated PostgreSQL HA Ceph Cluster CDN (self) PKI & Certs Backup Mgmt Monitoring Auth / IdP Patch Mgmt On-Call Rota ⚠ Who is responsible? Complex. Unclear. Expensive. waf2p.dev · WAF++ Sovereign Pillar
Fig. 1 — Exit ≠ Freedom. What is today an orderly governed cloud becomes, after an unplanned exit, a patchwork of self-operated services. RDS, S3, CloudFront, IAM — everything must be replaced, patched, monitored, and owned. By whom, exactly?

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.

Figure 2 — Two Conceptions of Sovereignty FIGURE 2 Two Conceptions of Sovereignty COMMON MISCONCEPTION Exit = Freedom → Find a different provider → Cancel the contract → Done. Sovereign. RESULT IN PRACTICE: Cost shock from self-operation Unexpected hidden dependencies WAF++ BETTER WAF++ VISIBILITY Visibility = Freedom ✓ Inventory: know what you have ✓ Document all dependencies ✓ Define & enforce controls RESULT: Exit is possible at any time Sovereign — regardless of provider Sovereignty is not a question of the provider. It is a question of visibility.
Fig. 2 — Myth vs. Reality. What most believe: changing provider = sovereign. What WAF++ shows: visibility = sovereign. With full inventory and controls, exit is possible at any time — but no exit is needed to achieve sovereignty.

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.

Figure 3 — Three Uncomfortable Truths FIGURE 3 Three things that are true — even if they're uncomfortable. 01 Exit doesn't solve a governance problem. An org without inventory is just as unsovereign after exit as before. Only the provider changes. SOV-001 02 Visibility is more demanding than exit. Controls must run. Inventory must be current. Decisions must be documented. Always. SOV-002 03 Sovereignty works in AWS too. If you know what you have, why you use it, and how to exit — you are sovereign. No matter where you run. SOV-003 waf2p.dev · WAF++ Sovereign Pillar
Fig. 3 — Three Uncomfortable Truths. Exit doesn't solve a governance problem. Visibility is more demanding than exit. And sovereignty works in AWS too — if you know what you have and why.

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?”

Figure 4 — Are you sovereign? Four honest questions. FIGURE 4 Are you sovereign? Four honest questions. Do you fully know which cloud resources you have? Inventory, dependency map, proprietary services all marked. Is every dependency a conscious decision? Not accidentally grown. Documented and justified. Can you show a regulator today exactly what you do with what? Controls running. Evidence exists. Audit-ready. Do you know how to exit in an emergency — and what it would cost? Exit scenario documented. Portability score known. Are you currently in the process of exiting AWS / Azure / GCP? That is a project — not the same as sovereignty. If you answered the first four with Yes: You are sovereign. Regardless of provider. · waf2p.dev
Fig. 4 — Four Honest Questions. Do you fully know what you have? Are all dependencies conscious decisions? Can you show a regulator today what you do with what? Do you know how to exit? If yes: you are sovereign — no matter where you run.

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.

Sascha Lewandowski
Sascha Lewandowski
Cloud Architect
Cloud Architecture Cloud Security DevSecOps

Mit einer umfassenden Erfahrung in der IT-Sicherheit trägt er maßgeblich zur Entwicklung innovativer Cloud-Lösungen bei.

MORE FROM WAF++

Continue reading