Multi-Cloud Exit Strategy: Avoid Lock-In as Big 3 Dominate

Last quarter, a founder in Pune called me in a mild panic. His AWS bill had crept from ₹1.2 lakh to ₹3.4 lakh a month over eighteen months, and when he asked his account manager for a better rate, the answer was polite but firm: the discounts were tied to a three-year commitment. He was already too deep in to walk away. His entire application ran on AWS-specific services, his data sat in DynamoDB, and his authentication was hooked into Cognito. Migrating anywhere else would take six months and a rewrite. That is lock-in, and it is expensive.

Here is a number that should get your attention: AWS, Azure and Google Cloud together control roughly two-thirds of the global cloud market, and their pricing power grows every year. With Meta now building out its own infrastructure ambitions and the Big 3 tightening enterprise agreements, Indian SMBs are increasingly negotiating from a position of weakness. But it does not have to be this way. A well-designed multi-cloud strategy for Indian SMBs keeps your architecture portable, your costs negotiable, and your bargaining power intact.

In this post I will walk you through how to think about lock-in, which parts of your stack are safe to standardise versus dangerous to entangle, a real migration example with rupee figures, a vendor comparison, and a practical exit checklist you can hand to your engineering team or vendor tomorrow.

Key Takeaways

• Lock-in is rarely about the compute layer. It is about proprietary databases, managed services, and data egress fees that make leaving painful.
• You do not need to run workloads on two clouds at once. Multi-cloud readiness (portable design) matters more than active multi-cloud deployment.
• Containers, open-source databases (PostgreSQL, MySQL), and infrastructure-as-code are your three biggest lock-in defences.
• Egress fees are the silent killer. Moving 10 TB out of a hyperscaler can cost ₹70,000 to ₹90,000 before you touch anything else.
• Keep at least one credible alternative quote alive at all times. It is the only thing that keeps your renewal pricing honest.
• For Indian businesses, data residency and GST-linked invoicing add compliance layers that shape which clouds and regions you can actually use.

What does vendor lock-in actually mean for an Indian SMB?

Lock-in is the accumulated cost of leaving a vendor. It is not one thing. It builds quietly through a dozen small decisions, each of which felt convenient at the time.

Let me break it into the parts that actually trap you, because founders often worry about the wrong layer:

• Compute lock-in is mostly a myth. A virtual machine on AWS EC2 is almost identical to one on Azure or GCP. Moving it is easy.
• Managed service lock-in is where the trap lives. When you build on DynamoDB, Cosmos DB, BigQuery, or AWS Lambda with all its event triggers, you are writing code that only runs on that provider.
• Data gravity is real. Once you have terabytes sitting in one cloud, the egress fee to move it out becomes a genuine barrier.
• Identity and tooling lock-in creeps in through IAM policies, proprietary monitoring, and CI/CD pipelines built around one vendor's ecosystem.

For an Indian SMB running on tight margins, the danger is that lock-in removes your leverage exactly when you need it. When your three-year deal is up for renewal and your entire business runs on one provider's proprietary stack, you have no credible threat to walk. And the sales team knows it.

How do you design a portable architecture from day one?

The goal is not to avoid managed services entirely. That would be foolish. Managed databases and serverless functions save you real operational money. The goal is to make deliberate choices about where you accept lock-in and where you insist on portability.

Standardise on containers and Kubernetes

If your application runs in Docker containers orchestrated by Kubernetes, it can run on AWS EKS, Azure AKS, Google GKE, or even a self-managed cluster in an Indian data centre. The Kubernetes API is the same everywhere. This single decision removes about 60% of typical lock-in risk. You write your deployment configs once and they move.

Choose open-source databases over proprietary ones

PostgreSQL and MySQL run on every cloud. AWS RDS, Azure Database, and Google Cloud SQL all offer managed versions. If you build on standard PostgreSQL, you keep the operational convenience of a managed database while retaining the freedom to move. Contrast that with DynamoDB or Cosmos DB, which have no equivalent elsewhere. Your queries, your data model, and your application code would all need rewriting.

Use infrastructure-as-code with a portable tool

Define your infrastructure in Terraform (or OpenTofu, its open-source fork) rather than clicking through the AWS console. Terraform supports all major providers. When you write your networking, storage, and compute as code, recreating your environment on a different cloud becomes a configuration exercise, not a rebuild from scratch.

Pro Tip: Keep an "abstraction inventory" document. For every third-party or cloud-specific service you adopt, write down in one line what it does and what the closest alternative is on the other two clouds. When I audit SMB architectures, the teams that maintain this document can plan a migration in days. The ones that do not spend weeks just figuring out what they actually depend on.

A real migration: how a Gurgaon logistics firm cut its cloud lock-in

Let me give you a concrete example, with the numbers changed slightly to protect the client but accurate in shape.

A 28-person logistics and last-mile delivery company in Gurgaon was running everything on a single hyperscaler. Their monthly bill was ₹2.8 lakh. When we dug in, roughly ₹90,000 of that was compute, ₹60,000 was a managed NoSQL database, ₹40,000 was a proprietary message queue and serverless functions, and the rest was storage, data transfer, and monitoring.

The problem was not just the cost. It was that their renewal quote had jumped 22% and they had zero negotiating leverage because their tracking platform was built entirely on proprietary services.

Here is what we did over a four-month engagement:

1. Containerised the application (weeks 1 to 4). The core tracking app was refactored into Docker containers running on Kubernetes. This alone made the compute layer portable across any cloud.
2. Migrated the NoSQL database to PostgreSQL with JSONB (weeks 4 to 9). Most of their "NoSQL" usage was actually semi-structured JSON that PostgreSQL handles natively via JSONB columns. This eliminated the ₹60,000/month proprietary database and replaced it with a managed PostgreSQL instance at around ₹32,000.
3. Replaced proprietary serverless functions with containerised background workers (weeks 8 to 12). The event triggers were rewritten as standard queue consumers using RabbitMQ, which runs anywhere.
4. Rewrote infrastructure in Terraform (ongoing). Every resource was codified so the whole environment could be recreated on another cloud in under a week if needed.

The result: their monthly bill dropped to ₹1.9 lakh, a saving of about ₹9 lakh a year. More importantly, when their renewal came up, we had a live quote from a second provider. The incumbent's account team cut the effective rate by 15% within a week. That negotiation alone paid for the entire engagement.

If you want a deeper look at trimming cloud spend specifically, our companion piece on right-sizing AWS bills for Indian SMBs covers the cost side in detail. This kind of work is exactly what our cloud migration and managed services team handles day to day.

AWS vs Azure vs Google Cloud: which is best for a portable Indian setup?

There is no universally "best" cloud. There is only the best fit for your workload, your team's skills, and your portability goals. Here is how the Big 3 compare on the criteria that matter for an SMB planning to stay flexible.

Criterion	AWS	Azure	Google Cloud
Indian regions	Mumbai, Hyderabad	Pune, Chennai, Mumbai (Central India)	Mumbai, Delhi NCR
Kubernetes maturity	EKS, very mature	AKS, mature	GKE, best-in-class (Google created Kubernetes)
Managed PostgreSQL	RDS / Aurora	Azure Database for PostgreSQL	Cloud SQL / AlloyDB
Data egress cost (approx, per GB after free tier)	~₹7.5	~₹7	~₹9.5
Best for teams already using	Broadest service catalogue	Microsoft 365, Windows, .NET shops	Data analytics, AI/ML workloads
Startup credit programs	AWS Activate (up to $100K)	Microsoft for Startups	Google for Startups Cloud

My general advice: if your team already lives in the Microsoft ecosystem with Microsoft 365 licensing, Azure reduces friction. If you are data and AI heavy, GKE and BigQuery give Google an edge, though BigQuery itself is a lock-in trap you should enter with eyes open. If you want the widest talent pool in India and the broadest service selection, AWS remains the default. But whichever you pick, build portable and keep the alternatives credible.

What about data residency and compliance for Indian businesses?

Portability is not just a technical question in India. It is a regulatory one. The Digital Personal Data Protection Act and sector-specific rules from the RBI shape where your data can legally live.

The RBI's payment data localisation mandate, for instance, requires that payment system data be stored only in India. If you handle payment data, your multi-cloud plan must ensure every provider you use offers an Indian region. Fortunately all three hyperscalers now do, but if you are considering a smaller regional provider as your backup, verify this first.

A few practical compliance points I run through with every client:

• Confirm your primary and backup clouds both have Indian regions so failover does not accidentally move data offshore.
• Keep GST-compliant tax invoices from your cloud provider. Foreign billing entities complicate input tax credit claims, so check whether the provider bills through an Indian entity.
• Document your data flows. Regulators increasingly expect you to know exactly where each category of data resides.

We covered this in depth in our guide to data residency rules for Indian SMBs, and if AWS routing more workloads to India affects your planning, this piece on AWS data centres in India is worth a read. For a formal review of your compliance posture, our IT consulting team can map your data flows against current regulations.

How do you actually plan a cloud exit? A practical checklist

An exit strategy is not something you build the day you decide to leave. It is something you maintain continuously so that leaving is always possible. Here is the checklist I hand to teams.

The exit-readiness checklist

1. Inventory every cloud-specific dependency. List each proprietary service and its cross-cloud equivalent. If there is no equivalent, flag it as high-risk.
2. Confirm your data export path. Can you get a full copy of your data out in a standard format? Test this quarterly with a sample. Do not assume it works.
3. Estimate your egress cost. Calculate what it would cost to move your total data volume out today. For 10 TB on AWS, that is roughly ₹75,000. Know this number.
4. Keep infrastructure as code. Your entire environment should be reproducible from a Terraform repository.
5. Maintain a warm alternative. Get a real quote from a second provider annually. Even a small pilot workload keeps the relationship alive.
6. Document your runbooks. Anyone should be able to understand how the system deploys, scales, and recovers without tribal knowledge.
7. Set contract review reminders. Diarise your renewal 90 days ahead so you negotiate from strength, not from a deadline.

Common Mistake: Teams sign long committed-use discounts (three-year Reserved Instances or Savings Plans) covering 100% of their capacity to chase the lowest rate. Then their needs change, or a better option appears, and they are stuck paying for compute they cannot move. Cover 60 to 70% of your baseline steady-state usage with commitments. Keep the rest on-demand or spot so you retain flexibility. The extra few percent you pay is cheap insurance against being trapped.

Does multi-cloud make sense for every SMB?

Honestly, no. Running active workloads across two clouds simultaneously adds real operational complexity: two sets of billing, two security models, two sets of skills your team needs. For a 15-person company, that overhead can outweigh the benefit.

This is the distinction that matters. There is a difference between multi-cloud deployment (running live on two clouds) and multi-cloud readiness (designed so you could move). For most Indian SMBs, readiness is the right goal. You get almost all the negotiating leverage and portability benefits without doubling your operational burden.

Reserve true multi-cloud deployment for cases where you have a specific reason: regulatory requirements to split data, a need for extreme availability, or a workload that genuinely runs better on a specific provider (say, ML training on Google and everything else on AWS). A sound multi-cloud strategy for Indian SMBs is usually about readiness first, active deployment only when justified.

Frequently Asked Questions

What is the biggest hidden cost when leaving a cloud provider?

Data egress fees. Providers charge you to move data out of their network, and the cost scales with volume. Moving 10 TB out of a major cloud can cost ₹70,000 to ₹90,000 before you spend a rupee on the new environment. Always calculate this figure before assuming a migration is cheap.

Can a small Indian business afford a multi-cloud strategy?

Yes, if you focus on readiness rather than running two clouds at once. Building portable (containers, open-source databases, infrastructure-as-code) costs little more than building lock-in and often nothing extra. The expensive version is active multi-cloud deployment, which most SMBs do not need.

Which database should I use to avoid lock-in?

PostgreSQL is the safest choice. It is open source, runs as a managed service on every major cloud, and its JSONB support handles most semi-structured data that people wrongly think requires a proprietary NoSQL database. MySQL is a solid alternative. Avoid DynamoDB, Cosmos DB, and BigQuery unless you accept the lock-in consciously.

How often should I get a competing cloud quote?

At least once a year, and always 90 days before any major contract renewal. A live alternative quote is the single most effective tool for keeping your existing provider's pricing honest. In one client case, simply having a second quote cut the renewal rate by 15%.

Does using Kubernetes really prevent lock-in?

Kubernetes removes a large portion of compute and orchestration lock-in because its API is identical across clouds. But it does not solve everything. You can still get locked in through cloud-specific databases, storage, and networking services attached to your Kubernetes workloads. Treat it as a strong foundation, not a complete solution.

Do Indian data residency laws force me to use a specific cloud?

Not a specific cloud, but they do require Indian regions for certain data types, especially payment data under RBI rules. All three major hyperscalers offer Indian regions, so you have choice. The key is ensuring both your primary and backup providers keep the relevant data within India.

Should startups accept cloud credits given the lock-in risk?

Take the credits, but spend them on portable architecture. Cloud credits from startup programs are genuinely useful in your early runway-conscious years. The mistake is letting free credits push you toward proprietary services that trap you once the credits expire and full pricing kicks in.

Where to go from here

The Big 3 are not going away, and their leverage over pricing will only grow as the market consolidates and new entrants like Meta reshape the landscape. Your best defence is not to pick the "right" cloud. It is to design a multi-cloud strategy for Indian SMBs that keeps you portable, keeps your egress costs known, and keeps at least one credible alternative on the table at all times. Do that, and you negotiate from strength every renewal cycle.

If you are staring at a rising cloud bill or a renewal you cannot escape, that is exactly the kind of problem we untangle. Our team can audit your current architecture, map your lock-in risks, and plan a portable migration path. Explore our cloud migration and managed services, browse our full services overview, or get in touch with eDarpan for a no-obligation architecture review. If your project also needs a portable application built the right way from the start, our custom software development team builds cloud-agnostic by default.

Lock-in is a choice you make one convenient decision at a time. So is freedom. Choose deliberately.

Image credit: Sad Cartoon versus Technology by Sean Loyless via flickr (BY 2.0), sourced through Openverse.