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 deliberate non-linearity: if either the protocol is proprietary or the tooling is absent, the code is trapped regardless of dataset size. Fifteen AWS services are scored and mapped into four quadrants, with surprises in both off-diagonal corners (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 can touch at most 30 percent of the exit tax, and, 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?