How locked in are you, exactly? A map for cloud dependencies¶
A plain-language companion to the working paper "A Two-Dimensional Taxonomy of Cloud Service Integrations" (July 2026). The paper carries the formal model, the computed scores, and the policy analysis; this text carries the ideas.
The short version. "Vendor lock-in" is usually argued as a binary: you are locked in or you are free. In reality every cloud service you adopt locks you in by a measurable amount, in a measurable place. The paper builds the measuring device: two axes, a formula that makes every score auditable, and a map of fifteen AWS services that holds several surprises. Then it asks the European question: if the goal is getting public systems off the US hyperscalers, which interventions actually move the needle? The answer, via a classic systems-thinking ladder: almost everything Europe currently spends money on sits at the shallow end.
Two axes, four quadrants¶
Ask two separate questions of every managed service you use. Where does the coupling live? At one extreme, only in your deployment scripts: your application speaks standard protocols (SQL, POSIX, HTTP) and does not know what cloud it runs on. At the other, inside your source code: provider SDKs, proprietary event formats, code that cannot compile without the platform. How hard is leaving? From "re-point the DNS and replicate the data" to "rewrite the application."
The two questions are independent, and that is the map's first lesson. Kubernetes and managed Redis couple deeply into your architecture and are easy to leave, because the interface is an open standard with many implementations: high coupling, low friction, and perfectly safe. AWS's identity and key-management services barely touch your code and are among the hardest things in the estate to migrate: every permission and every encryption envelope is written in a proprietary language with no second implementation. The scary quadrant is the double-high one: a serverless workflow whose database, event bus, orchestration, and functions are all proprietary scores near the maximum on both axes.
The formula, and why it has that shape¶
Exit friction decomposes into three measurable parts: data gravity (how much mass must physically move), protocol proprietary-ness (who owns the interface specification), and migration friction (how much translation the move requires, net of tooling). They combine with a deliberate non-linearity: if either the protocol is proprietary or the tooling is absent, your code is effectively trapped, regardless of how small the dataset is. Data transport gets 30 percent of the weight; logical lock-in gets 70. Every score in the paper is recomputed from this formula by a script that refuses to build the figure if the table disagrees.
That weighting carries a policy result worth stating on its own: a rule that only makes data movement cheaper can touch at most 30 percent of the exit tax. The EU Data Act's egress-fee ban is real and useful, and for a service whose lock-in is in the code, it barely moves the total. Anyone declaring the switching problem solved by egress rules has confused the truck with the cargo.
Lock-in compounds¶
Services chain: the function is triggered by the event bus, orchestrated by the workflow engine, persisting to the proprietary database, authorized by the proprietary identity layer. The paper models this with a coupling coefficient: at zero, you can migrate the estate piecemeal; as it grows, the whole estate becomes hostage to its most entangled component. The practical antidote is old-fashioned software architecture: keep the core logic behind clean interfaces, confine the provider-specific code to adapters, and mandate open standards at the boundaries between services, which is exactly where the compounding lives.
The European question, on the systems-thinking ladder¶
The paper's second half ranks the available interventions on Donella Meadows' ladder of leverage points, from shallow (change a number) to deep (change the goal). The uncomfortable finding: the bulk of visible EU cloud-sovereignty spending, capacity subsidies, datacenter build-outs, "Euro-hyperscaler" ambitions, sits at the shallow end, and a hyperscaler's own "sovereign region" is the same confusion in vendor packaging: geographic residency with the architectural exit tax fully intact. The workload still cannot leave.
The high-leverage interventions are cheap and mostly regulatory. Mandatory exit-tax disclosure on every public cloud procurement, because the engineer who picks the proprietary database under deadline pressure is never the one who pays the migration bill years later, and restoring that feedback is the single most reliable systems fix. Specification-first procurement: tenders that name standards, never products, converting Europe's ~14 percent-of-GDP purchasing power into demand for interfaces anyone can implement. And funding the interface as public infrastructure, simple and royalty-free, while a competitive market of European providers supplies the implementations. One distinction guards all of it: an open standard is an interface, open source is an implementation, and mandating a specific open-source product re-creates lock-in in a new costume.
The paper's own caveats: the scores are calibrated judgments made auditable rather than measurements of any particular estate; the sample is fifteen AWS services (the logic transfers to Azure and GCP, the numbers would differ); and the ladder ranks leverage; political feasibility is a separate axis. The endpoint, though, is a sentence the whole research programme keeps arriving at from different directions: the interface is the sovereign asset. Whoever owns the specification owns the exit.