The OpenInfra Foundation published two whitepapers on digital sovereignty this month: Best Practices with OpenInfra for Digital Sovereignty and OpenStack vs Proprietary Clouds: A Digital Sovereignty Comparison Guide. Both are free and ungated, and both are worth your time. But they are written from a vantage point where “sovereignty” mostly means GDPR, DORA, and European anxiety about American hyperscalers.
We run OpenStack in production, in US datacenters, for US customers. So this is a field reading: what the papers get right, the one distinction that should reframe how you buy cloud, and why the sovereignty conversation applies on this side of the Atlantic more than the papers let on.
One line that should reframe your next procurement
The comparison guide’s most important claim is easy to skim past. On data residency, it observes that OpenStack provides architectural guarantees, while proprietary platforms provide contractual guarantees.
Those sound similar. They are not.
A contractual guarantee is a promise: your data will stay in the region you selected, per the terms of service. The promise is real, and the vendor probably keeps it. But the infrastructure enforcing that promise spans jurisdictions you did not pick, its control plane is operated by people you cannot identify, and the encryption keys usually sit with the vendor. As the guide puts it, contractual data residency is offered, but the underlying infrastructure spans multiple jurisdictions. If the promise is ever tested, by a legal demand, an acquisition, or a policy change, what you hold is a clause.
An architectural guarantee is a property of the system. The hardware sits where it sits. The control plane runs on that hardware. The keys live in a key manager you can point to. Data cannot silently move somewhere else, because there is no somewhere else for it to move. Nobody has to keep a promise, because the architecture never made one that could be broken.
Almost every hard question in cloud procurement reduces to which of these two you are buying. We made a version of this argument in What Sovereign Cloud Actually Means, but the Foundation’s framing is cleaner, and it comes from a working group rather than a vendor. Quote it in your next vendor review.
The three pillars, translated into operator terms
The best-practices paper defines sovereign infrastructure through three pillars. The definitions are good; here is what each one means when you are actually evaluating a provider.
Strategic independence is the paper’s term for authority over where data lives, who can access it, and which legal frameworks govern it. The operator translation: who holds the encryption keys, and whose courts can compel access? If your provider holds the keys and answers to legal processes in jurisdictions you cannot enumerate, you have a dependency wearing a sovereignty costume.
Operational resilience means the infrastructure keeps running, gets patched, and evolves without any single external party’s cooperation. The paper’s formulation is blunt and correct: no single dependency should be able to prevent continued operation, maintenance, or evolution of critical infrastructure. The operator translation: what happens to your workloads if one vendor relationship ends badly? If the honest answer is “we would have months, not years, to rebuild everything,” you have measured your resilience.
Software transparency means the ability to audit, modify, and replace the software you run on. Open source is what makes this pillar real rather than aspirational. You cannot audit a proprietary control plane, and you cannot fork it when the vendor’s roadmap diverges from your interests. The operator translation: exit rights you cannot exercise are not rights. We put numbers on this in Vendor Lock-In Is a Technical Debt You Can Measure.
The US angle the papers underplay
Because the sovereignty conversation grew up in Europe, it is easy for US buyers to file these papers under “interesting, not my problem.” That would be a mistake. The three pillars apply directly to obligations that are written in American English:
Defense contractors and their suppliers. If you handle CUI under DFARS 252.204-7012, you already live with data-residency and incident-cooperation requirements that are architectural questions, not paperwork questions. At hour 60 of an incident, a contractual promise does not preserve a system image; a provider with actual custody of the infrastructure does. We walked through that clock in The 72-Hour Clock.
ITAR technical data. Export-controlled data demands certainty about physical location and about the nationality of the people who can access it. That is the strategic-independence pillar with a statutory penalty attached. CONUS residency is the architectural answer.
The CLOUD Act cuts both ways. European buyers worry about US law reaching their data through US vendors. US buyers should notice the mirror image: a global provider’s infrastructure and personnel span jurisdictions whose legal processes can reach into it, and you will not be notified in every case. Jurisdictional clarity is not a European luxury. It is knowing, affirmatively, every legal framework your data sits under.
Regulated commercial data. Law firms carrying privileged client files, CPA firms under IRS Publication 4557 and the FTC Safeguards Rule, healthcare organizations with HIPAA obligations: all of them face some version of “prove where the data lives and who can touch it.” We published checklists for law firms and accounting firms that are, in hindsight, the three pillars applied to specific verticals.
Egress fees are a sovereignty tax
The comparison guide makes an argument we have been making since our first month of publishing: egress fees are not a bandwidth cost, they are an exit penalty. The guide calls the effect “data gravity.” Every terabyte you accumulate inside a proprietary platform raises the cost of ever leaving it, which quietly converts a technical decision into a financial trap.
Read through the sovereignty lens, egress pricing is a direct attack on the strategic-independence pillar. Your data can be perfectly resident, perfectly encrypted, and still hostage, because retrieving it at scale costs real money that was never in the TCO model. The guide’s OpenStack column reads “no platform-level egress fees; bandwidth costs reflect the organization’s own infrastructure,” and that is exactly how we price. The hidden-costs math has not changed; the Foundation has just given it a sharper name.
How to actually use the comparison guide
The guide’s side-by-side matrices cover compute, storage, networking, security, compliance, operations, and TCO. Here is how to turn them into procurement questions rather than reading material:
- For each matrix row, ask every vendor: is your guarantee architectural or contractual? Where does the enforcement live, in the system or in the terms of service? Write the answers down. The pattern that emerges is the evaluation.
- Ask who holds the keys. Not whether encryption exists (it always does), but whether key custody is yours, and what legal process reaches the custodian.
- Price the exit before you sign the entrance. Model what it costs, in egress fees and in re-engineering, to move your estate out in year three. If the number is unknowable, that is the answer.
- Ask what remains if the relationship ends. With standard APIs (OpenStack, S3, Terraform, Ansible), your automation, tooling, and team skills survive a provider change. With proprietary control planes, they do not.
- Map your workloads to the guide’s own use-case table. The paper is honest that proprietary platforms are fine for non-critical workloads and fast experiments. Sovereignty spending belongs on the systems whose loss or exposure you cannot absorb.
Where we sit
We built Open Edge Cloud on OpenStack because we wanted to sell architectural answers, and it is worth being concrete about what that means pillar by pillar.
Strategic independence: US datacenters, operated by US persons, with customer-managed encryption keys available through OpenStack Barbican, so key custody can sit with you. Operational resilience: a managed platform with named account teams, monitored and operated as a fleet, with your workloads isolated per project. Software transparency: the entire platform is open source, top to bottom, and your workloads talk to standard OpenStack APIs that a dozen other providers and your own datacenter can also serve. No egress fees, so the exit stays priced at zero and the relationship stays voluntary. The platform follows SOC 2 and ISO 27001 control frameworks, and cryptographic operations run against a FIPS 140-3 validated module (CMVP certificate #5115).
None of that requires you to take our word for anything, which is rather the point.
Read them
Both papers are short, free, and ungated:
- Best Practices with OpenInfra for Digital Sovereignty
- OpenStack vs Proprietary Clouds: A Digital Sovereignty Comparison Guide
If your next infrastructure decision involves data you are obligated to protect, read them with your current contracts open in the next tab, and ask of every clause: is this architecture, or is this a promise?
If you want the architectural version of the answer, talk to us.