A platform team adopts a strict multi-cloud policy - only services available on all three major providers are permitted and everything is abstracted behind internal interfaces. What does the organisation gain, what does it pay, and when does the bill arrive?

What is gained

• A stronger bargaining position at renewal, which is real and is the honest commercial reason most such policies exist.
• Regulatory optionality - a credible answer when a customer or a supervisor requires that a provider can be exited, which in some sectors is a contractual obligation rather than a preference.
• A genuine exit path, if the abstraction is exercised rather than merely built.
• Resilience to one provider's failure, but only for workloads actually running in two places and tested there. An abstraction that has never been run elsewhere provides none of this.

What is paid

• The lowest common denominator of managed services. If a service must exist on all three providers in comparable form, the team runs its own message broker, its own search, often its own database and secret store. The policy converts a provider's operational work into your headcount, and that is the dominant cost by a wide margin.
• An abstraction layer that is a product with no external users, needing design, documentation, versioning, support and an on-call rotation of its own.
• Two or three operational surfaces - identity models, networking semantics, quota systems, incident channels, support contracts - held by the same people.
• Hiring and training breadth rather than depth, in a market where depth is what is available.

The distinction that decides it

Compute and storage are nearly fungible; control planes are not. A virtual machine, a container image and an object in a bucket move between providers with modest effort. What does not move is the semantics around them: the identity and policy model, the network and egress model, event plumbing, the behaviour of each managed service under failure, and the operational knowledge your team has built.

So the useful question is not "are we portable?" but "which kind of lock-in are we accepting?" Accepting control-plane lock-in while keeping the data in open formats, with a documented and costed exit plan, gets most of the optionality at a small fraction of the price. That is the position most mature organisations end up in, often after paying for the strict policy first.

When the bill arrives

At the first feature that exists on one provider only - a managed vector store, a specific accelerator, a compliance certification - at which point the policy either blocks the product or is quietly broken, and the abstraction now has two divergent implementations to maintain.

The second arrival is slower and more damaging: the team's attention. Three years in, the platform group is maintaining its own broker, its own database automation and its own abstraction layer, and has no capacity left for the developer experience work that was the point of having a platform group.

How to keep the option without the tax

Keep data portable - open table formats, exports that are tested, schemas you own - because data is the thing that cannot be re-created. Use the provider's managed services freely for compute and plumbing, which can be rebuilt. Write the exit plan as a document with a cost and a timeline, review it annually, and rehearse the one piece that is genuinely hard, which is almost always the data movement and the identity model rather than the application.

When this is the wrong analysis

Where a regulator or a major customer contractually requires demonstrable multi-provider operation, the cost is not optional and the argument is about scope, not principle - and the answer is usually to keep one critical path genuinely portable rather than the whole estate. A policy applied to everything is almost always wrong; applied to the two systems that would end the business, it can be exactly right.

The decision rule to write down: choose strict portability only where an exit is contractually required or where a provider failure would end the business, and accept control-plane lock-in everywhere else. The quantity that makes it concrete is headcount - running your own broker, database automation and abstraction layer is 2 to 3 engineers of permanent work, which for most platform groups is half the team. The regulatory backdrop is worth knowing too: since 2024 the large providers have offered free data transfer for customers exiting entirely, following European pressure, so the cost of leaving has moved from egress fees to the control-plane rewrite - the exact cost a strict policy is paying up front, every year, to avoid once.