What you'll take away
Cloud vendor lock-in has been a theoretical concern for enterprise technology leaders since the first AWS services launched two decades ago. In 2026, it has become a concrete commercial problem: cloud provider pricing power has increased as customer switching costs have grown, and organisations that built their entire stack on proprietary managed services now face the choice between accepting price increases or undertaking migrations that are expensive, risky, and slow.
The standard response — 'we should be cloud-agnostic' — is technically naive. Complete cloud agnosticism means refusing all proprietary managed services and building everything on portable open standards: Kubernetes instead of ECS, Postgres on EC2 instead of RDS, self-managed Kafka instead of Amazon MSK. The engineering cost of this portability is enormous, and the resulting infrastructure is more complex and operationally demanding than the managed-service equivalent. Most organisations that try to achieve complete agnosticism end up with a hybrid that's the worst of both worlds.
The Right Framework: Strategic Agnosticism
Strategic agnosticism asks a different question: not 'how do we avoid all vendor dependencies?' but 'where does vendor lock-in create financial exposure that outweighs the operational cost of portability?' The answer varies by organisation, but there are consistent patterns in where portability investment pays off and where native services are worth the dependency.
Where Lock-In Is Expensive: The High-Exposure Layers
Data
Data is the highest lock-in exposure for most organisations because it combines high egress costs (moving data out is expensive), high migration complexity (database migrations are technically difficult and risky), and long-term accumulation (the longer you stay, the larger the data estate and the more expensive the migration). Designing data architecture to be portable — using standard SQL databases over proprietary NoSQL services where feasible, avoiding deep dependence on provider-specific data formats and APIs — is among the highest-ROI lock-in mitigation investments.
AI/ML Services
The major cloud providers are racing to lock AI workloads into their proprietary ML platforms and foundation model services. The switching cost from a tightly integrated ML platform (SageMaker, Vertex AI, Azure ML) can be enormous: retraining pipelines, rewriting inference serving, migrating model registries. For organisations building AI capabilities that will matter for the next decade, the portability decision on ML infrastructure is one of the most consequential ones to get right early.
Application Tier Integration Services
Not sure where to start?
48-hour turnaround. No obligation.
Message queues, event streaming, API gateways, and workflow orchestration are services that deeply embed in application code. A service built on AWS SQS has SQS-specific logic distributed throughout its codebase. Migrating that service to run on GCP or on-premise requires refactoring every integration point. Designing these integrations behind abstraction layers — interfaces that could be implemented against multiple backends — costs engineering time upfront but dramatically reduces switching cost.
The commercial leverage question: if your primary cloud provider informed you tomorrow that they were raising prices by 30%, what would it cost you to switch? If the answer is 'more than we'd save in three years,' you have accepted vendor pricing power that you should price into your infrastructure budget indefinitely.
Where Lock-In Is Acceptable: The Low-Exposure Layers
- Managed networking and CDN: VPC configurations, load balancers, and CDN are expensive to replicate but typically a small fraction of total spend and not the source of pricing power disputes
- Provider-specific security services: IAM, secrets management, and security tooling are deeply integrated but rarely the source of cost surprises
- Commodity compute: EC2/GCE/Azure VM pricing is highly competitive; providers have limited ability to raise prices on undifferentiated compute without losing market share
- Monitoring and logging basics: Provider-native CloudWatch/Cloud Monitoring is useful but easy to replace with third-party observability tools if needed
The Multi-Cloud Question
True multi-cloud — actively running the same workloads across multiple cloud providers for resilience or commercial leverage — is operationally expensive and justified for only a small class of organisations: those with extreme resilience requirements, those with specific regulatory requirements for geographic distribution, or those large enough to run meaningful provider negotiations. For most organisations, the right strategy is primary-cloud with strategic portability at the high-exposure layers, not active multi-cloud.
GYSP's IT Consulting & Advisory practice conducts lock-in exposure assessments for organisations preparing for cloud contract renewals or evaluating infrastructure architecture investments. The output is a prioritised map of where portability investment creates commercial leverage — and where it doesn't.
“Cloud agnosticism is not a binary choice. It's a spectrum of investments in portability at different layers of the stack. The question is which investments create commercial leverage that justifies their cost, and which create engineering complexity that doesn't.”
— Dhaval Rana, Founder & CEO — GYSP.tech
