They Left AWS. Came Back. Now They're Leaving Again.

“You rented it. How can you be locked in?” It’s the question that keeps coming back as more teams who once fled AWS for self-hosting quietly return — only to pack their bags again 18 to 24 months later. That second exit is the interesting one. It’s where the real cost of cloud lock-in finally becomes visible, and it has almost nothing to do with the monthly invoice.

The Lock-In Isn’t on Your Bill. It’s in Your Codebase.

When developers complain about vendor lock-in, the conversation usually starts with EC2 pricing or S3 egress fees. Those are real, but they’re the smallest part of the trap. The expensive part is structural: boto3 imports scattered through every service, auth flows shaped around IAM, data models built on DynamoDB key design, async patterns tuned for Lambda’s runtime.

Each of these is non-portable debt. It doesn’t show up on a bill, but it shows up the day you try to leave.

The moment returning teams start eyeing the door again is remarkably consistent. They want to ship a new feature. To work around the limits of one AWS service, they have to bolt on another AWS service. Then a third to glue the first two together. At some point a senior engineer says it out loud: “We’re not building a product. We’re operating AWS.”

Why They Came Back in the First Place

Worth being honest about: there’s a reason these teams returned. Self-hosting is humbling. You get one 3 a.m. page about a full disk, one expired TLS cert that takes down checkout, one Postgres replica that silently drifted out of sync — and suddenly RDS at $400 a month sounds like a steal.

For early-stage startups, AWS managed services are a genuine weapon. The annual cost of one infrastructure engineer often covers a year of AWS bills with room to spare. So they come back. And then, typically 18 to 24 months later, they start drafting the exit plan again.

Three Signals That a Second Exit Is Coming

Teams considering a second departure tend to hit the same three walls.

Unpredictable billing. Traffic doubles, the bill quadruples. Finance starts asking pointed questions. The damage usually comes from the invisible line items — NAT Gateway hours, CloudWatch Logs ingestion, cross-AZ data transfer — that nobody budgeted for because they never appeared in the keynote slide deck.

The managed-service black box. RDS has a performance regression and you can’t drop to the OS to investigate. Aurora does something weird and the internals are sealed. You file a support ticket and wait three days. Worse, your team’s operational muscle atrophies in the meantime — you’re paying premium prices to lose the ability to debug your own stack.

The portability illusion collapses. Year one: “We can move whenever.” Year two: SQS, SNS, Step Functions, and EventBridge are load-bearing parts of your business logic. Leaving isn’t a migration anymore. It’s a rewrite.

Where the Second-Time Leavers Actually Go

The second exit doesn’t look like the first. Nobody’s racing to colocate servers in a datacenter cage. The pattern is hybrid by design: core workloads on cheap bare-metal providers like Hetzner or OVH, bursty or stateful pieces still on a hyperscaler. Kubernetes as a portability layer. PostgreSQL as the default database because it runs anywhere, including under your desk.

The governing principle is simple: use the cloud, but don’t design for the cloud. If you do reach for an AWS-specific service, hide it behind your own interface. It looks like over-engineering on day one. By month eighteen, it’s the only reason you have options.

The Real Cost Is Negotiating Leverage

The bills, the tech debt, the operational complexity — all real costs. But the largest cost is the one that doesn’t appear in any spreadsheet: not having an alternative is itself the price you pay. When AWS adjusts Reserved Instance terms, when a new service launches with pricing you hate, when Enterprise Discount Program renegotiation comes around — if you can’t credibly leave, you take the deal.

Teams holding a real exit option don’t usually exit. They just stay on better terms. The strongest weapon at an EDP negotiation is a competing quote that the AWS rep knows you could actually act on.

So the question isn’t whether your team uses AWS. It’s whether you use AWS or AWS uses you. The two states look identical from the outside, and the difference comes down to a decision made before the first line of code: were you building a system that assumed it would never leave, or one that assumed someday it might? Two years in, those two systems don’t even resemble each other.