Photo by Priscilla Du Preez 🇨🇦 on Unsplash. Source: https://unsplash.com/photos/a-man-sitting-in-front-of-a-laptop-computer-OEdkPaxYMXU (Unsplash License).

Executive Summary

Regulators keep asking where data sits, and a location answer keeps passing the test. That test is too easy. The harder question is whether a workload can run somewhere else. Most enterprises have never checked.

Residency is a checkbox. Sovereignty is a control claim, and control sits with whoever holds the keys and runs the control plane. Microsoft’s EU Data Boundary, Google Sovereign Cloud, and an AWS European region staffed by EU residents each narrow who can see the data. None of them hand over the power to patch, deprecate, or suspend. Portability is where the claim gets tested. Kubernetes conformance covers stateless workloads, while stateful services, identity, and data gravity do not move because a manifest says so. Pick one production workload. Give a second team 30 days and no help from the incumbent. Count what breaks, then write that test into the contract.

A regulator asks where your data sits. You answer with a region name and a map. The answer is true and almost useless. The question underneath is harder. Can you run this workload somewhere else, and can you prove it before you need to?

Data residency is a location claim. Workload sovereignty is a control claim. One is a checkbox on a procurement form. The other is a test you either pass or fail. Most enterprises pass the first and have never run the second.

Start with who holds the keys. Managed services encrypt your data at rest, and the provider holds the master key. That means the provider can decrypt it, on request, under its own policies. Customer-managed keys shift part of that control, but only part. If the provider can still patch the service or rotate the key, the control is shared at best.

Key management is where the claim usually softens. A customer-managed key lets you revoke access, which is real power. It rarely covers the provider’s administrative plane, the metadata, or the backups. Ask which services honor your key and which quietly use their own. The honest list is shorter than the marketing.

Who Can Patch, and Who Can Turn It Off

Operational control is the part buyers forget to price. A managed control plane lets the provider upgrade, deprecate, and throttle on its own schedule. Patch rights are subtle. A provider that owns the control plane can push an upgrade that breaks your workload, then tell you it is now unsupported. That is not a denial of service, but it lands the same way.

The sovereign offerings exist to narrow that gap. Microsoft EU Data Boundary keeps EU customer data inside the bloc. Google Sovereign Cloud adds local partners and staff. AWS runs a separate European region staffed by EU residents. Each narrows who can see the data. None of them hand you the controls.

The harder question is whether the provider can turn the workload off. A billing dispute, a sanctions flag, or a policy change can suspend an account. If your critical service depends on one account in one region, your sovereignty is a setting you do not own.

Portability Is a Test, Not a Slide

Kubernetes gives you a real advantage here because it is a CNCF graduated project with a conformance program. Manifests move. CNCF conformance means the API surface is the same across conformant distributions. That covers stateless workloads well. It covers almost nothing about state.

Stateful pieces are where portability breaks. Managed databases, object stores, and identity providers do not move because a manifest says so. Velero, a CNCF sandbox project, backs up cluster resources and persistent volumes. That helps, and it is only half the job. The other half is the data and the identity that live outside the cluster.

Data gravity does the rest. Egress fees, private network links, and years of accumulated configuration make a move expensive even when the technology allows it. Identity is the hardest piece to leave. Roles, service accounts, and secrets are tangled through everything, and they rarely export cleanly.

So test it. Pick one production workload and give a second team thirty days to run it somewhere else. Run the drill with a stopwatch and no help from the incumbent. Measure what breaks. Count the tickets, the manual steps, and the parts that needed a provider engineer. A failed drill is cheap. A failed migration during an outage is not.

The 30-Day Exit Is the Only Claim That Counts

A statement that your data stays in the EU is a residence claim. A statement that you can run this workload on a different provider in 30 days is an exit claim. Only one of them survives a geopolitical shift. Buyers keep accepting the first because it is easy to verify and cheap to promise.

Platforms that manage many distributions make the exit claim easier to keep. Red Hat OpenShift runs on several clouds. SUSE Rancher Prime manages any CNCF-conformant Kubernetes distribution, including clusters it did not install. That does not make a workload portable by itself. It removes one excuse.

Write the exit test into the contract. Name the workload, the target, the timeline, and the data format. Then run the drill once a year. Sovereignty you have never exercised is a belief, not a capability.

The sovereignty picture behind this, from procurement gates to the CLOUD Act gap, is pulled together in the 2026 State of Enterprise Infrastructure report.

Every announced commitment in this space is tracked with its source in our AI data centre power commitments record.

Related reading. the data sovereignty layer underneath, and sovereign cloud is not data residency.

By Ivan Tarin

Ivan Tarin is a Principal Product Marketing Manager at SUSE, where he owns go-to-market strategy and positioning for a seven-product cloud-native portfolio spanning Kubernetes, virtualization, storage, security, and observability. A former full-stack developer who shipped production code for enterprise and public-sector clients including U.S. national laboratories, Ivan translates complex infrastructure and AI technology into messaging that lands with developers, platform teams, and enterprise buyers. He has presented at KubeCon, SUSECON, and AWS Developer Week, and is currently pursuing an MS in Artificial Intelligence at the University of Colorado Boulder.

2 thoughts on “Workload Sovereignty Is the Only Sovereignty You Can Test”

Leave a Reply

Your email address will not be published. Required fields are marked *

Get the next one before it is old news

Independent analysis of cloud-native infrastructure, Kubernetes and data centre economics. No vendor spin.