Stop Treating Cloud Lock-In Like a Binary Choice—Here's What Actually Matters

I spent three hours last week on a Slack call with our DevOps lead arguing about whether we should migrate off AWS. Not migrate away entirely—just make sure we could if things went sideways. The conversation went nowhere because we were both operating from completely different mental models of what "lock-in" even meant. He was worried about our Lambdas. I was worried about our RDS bills and egress costs. Neither of us had actually done the math.

That call reminded me why I need to think about this more systematically. Cloud lock-in gets discussed like it's binary—you either have it or you don't—but that's lazy thinking. In reality, you're dealing with four completely separate problems, each with its own exit cost, and conflating them is how teams end up either paralyzed by choice or blindsided by a bill they can't leave.

The Four Layers Actually Are Different Problems

When I started breaking down my own infrastructure, the framework clicked immediately. Data is one problem—proprietary formats plus egress fees that hit like a sucker punch when you finally need to leave. Platform is another entirely—that's your Lambdas, your managed Postgres, your IAM integrations, the genuinely useful stuff that has no real equivalent elsewhere. Then there's the contract layer, which I admit I barely looked at before. Renewal clauses and committed-spend discounts quietly raise your switching costs while your CFO is celebrating the savings. Finally, operations—the muscle memory, the runbooks, the way your team actually thinks about deploying code.

The honest part? The first time I mapped this out for our actual stack, managed databases and serverless were the scariest. Not because they're bad—they're genuinely good—but because we'd built real dependencies without knowing what the exit looked like.

Terraform Makes You Face Your Lock-In, It Doesn't Erase It

I see a lot of teams treating Terraform like a silver bullet. "Just use IaC and you can leave anytime." That's marketing-speak, not engineering. What Terraform actually does is make your dependencies visible and auditable. When your infrastructure is code, you can read exactly where you're tied to a vendor. You can estimate the cost of moving those resources elsewhere. You can, theoretically, stand up equivalent infrastructure somewhere else faster than if it was all click-configured in the console.

But—and this is the big one—Terraform doesn't make a proprietary managed service portable. If you're using RDS, you're using RDS. If you're using Lambda, switching to GCP doesn't make it go away, it just means rewriting the code. Terraform documents your lock-in and maybe reduces the operational cost of leaving. It doesn't eliminate the fundamental design choice you made.

For our team, Terraform is valuable because it forces that decision-making upfront. We have to write down what we're using and why. That's worth the overhead.

My Take: Audit the Number, Then Make Intentional Choices

Here's what I actually do now: price the four layers separately. For data, I calculate realistic egress costs if we need to export everything tomorrow. For platform, I look at managed services and ask whether the speed gain justifies the switching cost. For contracts, I actually read the terms—shocking, I know. For operations, I estimate how long it would take our team to rethink their deployment process.

Once I have those numbers, I stop worrying about lock-in as a religious problem and start treating it as a tradeoff. A managed database that saves us three months of operational work? If the exit cost is a month of engineering time and we're not subject to price gouging, that's a deal I take. A proprietary observability platform we're inexplicably locked into? That one deserves scrutiny.

The playbook is unglamorous but it works: audit the layers, codify your infrastructure so dependencies are explicit, make intentional decisions about high-lock-in services, and revisit on a schedule. Lock-in creeps while you're not looking.

What Would Actually Change Your Situation Right Now

Before you audit anything, ask yourself: would leaving actually cost us money? If the answer is "we're regulated and can't move our data anyway," then half your lock-in worry is theater. If the answer is "we're fine here," then selective portability—keeping the managed-service speed where it matters, keeping options open where it doesn't—is a pragmatic middle ground between paranoia and carelessness.

The real question is whether you've actually priced it. What's your exit cost? I'd genuinely like to know.

Source: This post was inspired by "The Four Layers of Cloud Lock-In (and How Terraform Cuts Your Exit Cost)" by Dev.to. Read the original article