The cloud-services matrix¶
The architecture-level project: where lock-in is actually created, service by service, and which interventions reach it.
A Two-Dimensional Taxonomy of Cloud Service Integrations¶
Every cloud dependency gets two scores: architectural coupling (does the integration live in your deployment scripts or inside your source code?) and exit friction, computed from an auditable formula combining data gravity, protocol proprietary-ness, and migration friction with a non-linearity: if either the protocol is proprietary or the tooling is absent, the code is trapped regardless of dataset size. Thirty-five AWS services (adoption-anchored across three data sources) are scored and mapped into four quadrants, each with its open-source and European alternatives cataloged. A robustness suite (score noise plus a weight sweep) backs the scoring: the extreme corners never move, the boundary services flip and are flagged. Both off-diagonal corners are filled (Kubernetes and Redis: deeply coupled and easy to leave; identity and key management: barely touching your code and nearly impossible to move). Two policy results follow directly. Rules that act only on data movement reach about a fifth of the scored exit friction under the paper's calibrated weight, and less than half where lock-in is deepest, for any weight on data transport below one half. On Meadows' leverage-point ladder, most visible EU cloud-sovereignty spending sits at the shallow end while the cheap, deep interventions (exit-tax disclosure, specification-first procurement, simple royalty-free standards) go under-used. Companion explainer: How locked in are you, exactly?