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 on average 20 percent of the measured exit tax, and least where lock-in is deepest. 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?