Vendor Lock-In
The cost of switching away from a provider, treated as a quantity to be managed deliberately rather than a condition to be avoided absolutely.
Lock-in is not binary and avoiding it entirely is not a goal — the cost of provider-agnostic design is paid continuously, and the benefit is realised only on a migration that usually never happens.
The useful framing is exit cost against the value of using the thing. A managed database with proprietary features may save a year of engineering, and the migration you might do in five years is a cheaper problem than the year you would spend now.
Where the cost concentrates: data gravity — moving terabytes is expensive and slow, and egress charges are designed to make it more so; proprietary services with no equivalent elsewhere; operational tooling and skills built around one provider; and contractual commitments with discounts tied to spend.
Practical management rather than avoidance: keep data in portable formats and know how it would be extracted; put an abstraction around genuinely proprietary integration points, not around everything; prefer open standards where they cost nothing (Kubernetes, Postgres-compatible interfaces, OpenTelemetry, S3-compatible storage); and estimate the migration cost periodically so the number is known rather than feared.
The strongest position is not independence but a credible, costed exit, which is also what gives leverage at renewal.