Stop 13 · Cloud Migration & Multi-CloudTopics · 7/8

Vendor Lock-In Considerations

In short

Every time you pick a cloud's special service, you get speed today and make leaving a little harder tomorrow. Lock-in isn't evil. Walking into it without noticing is the real problem.

Using a provider's proprietary, deeply integrated services (versus more portable, open alternatives) trades convenience and capability for reduced flexibility to switch providers later — a conscious decision, not an accident.

The blob character smiles while fitting a mixer jar onto a mixer base on a kitchen counter.

Think of it like this

Jars that fit one mixer

Your mixer grinder's jars lock onto only that brand's base. They work beautifully, but if the motor dies, the jars are useless with any other mixer. A plain steel kadhai, meanwhile, works on any stove. Each has its place.

Watch it happen

From easy to move to hard to move

Linux VM

Kubernetes

Managed Postgres

Aurora

DynamoDB

Step Functions

1/6Services sit on a spectrum. Left side: standard tech that runs anywhere. Right side: proprietary services unique to one provider.

The big ideas

What you need to know

A trade, not a trap

Proprietary services often mean less code and less ops work. You're trading flexibility for speed.

Data is the real anchor

Moving terabytes out costs time and egress fees. Formats like Parquet or plain SQL dumps keep options open.

Wrap the special parts

Hide provider calls behind your own small interface, so a future swap touches one file, not the whole app.

Know your exit

For each key service, write a one-line exit plan and a rough effort estimate. Then decide calmly.

See it in code

Walk through the code

1import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";2 3// The rest of the app only knows this interface4export interface FileStore {5  save(key: string, body: Buffer): Promise<void>;6}7 8const s3 = new S3Client({ region: "ap-south-1" });9 10export const s3Store: FileStore = {11  async save(key, body) {12    await s3.send(new PutObjectCommand({ Bucket: "campus-uploads", Key: key, Body: body }));13  },14};15 16// Switching clouds later means writing gcsStore, not touching every route

1/3Your own small interface. Routes call save() and never import the AWS SDK.

A thin adapter keeps the provider-specific code in one place. Don't overdo it: wrap the parts you might really swap.

Save yourself the pain

Common mistakes

Oops

Refusing every managed service and running everything yourself on VMs to stay portable.

Do this instead

You pay daily in ops work for an exit you may never take. Pick portability where it really matters.

Oops

Building everything on proprietary services without ever asking "what if we leave?".

Do this instead

Note the exit cost when choosing. A one-line exit plan is enough for most services.

Your mission

Score your project's lock-in

~20 min

Quick check

Your app uses DynamoDB heavily. What's the most practical way to reduce lock-in without giving up its benefits?

Go deeper

1Identify a proprietary cloud service you've used and its more portable open-source equivalent.
2Learn why lock-in isn't inherently bad — it's a trade-off against genuine convenience and capability.
3Practice weighing lock-in risk against the productivity gain of a managed, proprietary service.