Skip to content
Back to all essays
Own Your TechResources

AWS and Google Cloud Are Designed to Keep You. Here's What We Do Instead.

By George PuEssay6 min read

Published

AWS and Google Cloud Are Designed to Keep You. Here's What We Do Instead.
Listen to this essay
0:000:00
AI-generated voice

Listen to article 0:00 / 0:00
Speed

Historical cost and portability context — October 11, 2026: This April 7 account preserves our reported month-long migration with three developers. The 15–30% markup, roughly 20% saving and seven-figure scoping anecdote are not supported here by matched model versions, usage, cache/discount terms, invoices or an independently audited estimate. A direct API can also create dependence. Compare total cost and rehearse recovery with the decision and recovery worksheet.

When my startup was brand new, both AWS and Google Cloud felt like gifts.

Our incubator had relationships with both. The credits were generous.

The onboarding was smooth. We didn't pay a dollar out of pocket for months.

It felt like they were investing in us.

In retrospect, the credits made it easier for us to become dependent on the platform. I cannot establish the vendors’ intent from that experience.

I didn't understand that then. I do now.

What You're Actually Paying For

I want you to try something. Strip away the logos and the marketing for a second.

Say you have some computer chips. You find a space to put them. You set up a rack. You start running software on them.

Then you realize you have extra room. Your colleague Alice pays $200 a month to use a slice. John pays $400 for a bigger slice.

You install some basic software to keep their stuff separate. All doable with existing tools.

That's it. That's cloud computing.

Amazon and Google just do it at a massive scale, with world-class branding, compliance teams, and sales reps who pick up on the first ring.

Those things have real value. I'm not dismissing that.

But once you see it for what it is — renting someone else's computers — you start asking different questions about how deep you really want to go.

The Month I'll Never Get Back

Here's where it got personal.

We had a simple B2B app running on AWS. Nothing fancy. A server, a few databases, a front-end, some supporting services. The kind of thing a small team builds in a few weeks.

We decided to move it to Google Cloud. Shouldn't be a big deal, right?

Same type of infrastructure. Same basic services. Should be a weekend project, maybe a week if we're being careful.

It took a month.

Three developers. Full-time. Migrating one piece at a time. Server first. Then settings. Then credentials. Then databases. Then the front-end.

Then service A, B, C, D — each one with its own quirks, its own format, its own way of doing things that didn't translate.

I remember sitting in a standup three weeks in, listening to my team debug yet another configuration issue, thinking: none of this is creating anything. We're not building features. We're not serving customers.

We're just moving boxes from one room to another, except the doors are different sizes and nothing fits.

A month of engineering time. For a simple app.

That's when I stopped thinking about cloud as a convenience and started thinking about it as a commitment.

The Help That Helps Them

I don't want to be unfair to either company. Both have good people.

An AWS team member once sat down with me, looked at my architecture, and told me straight — this is outdated, here's what's better, and it'll save you money.

Genuinely one of the most useful conversations I've had with a vendor. That kind of honesty is rare and I respect it.

Google Cloud's team was helpful too, but the energy was different. Less "how do we solve your problem" and more "here's how you can use more of our services."

Both teams are doing their jobs well. I just want you to understand what their jobs are.

Their job is to make you successful on their platform. Not successful in general. On their platform. That's a meaningful distinction.

The help is real. The direction it points you is also real.

Then AI Made It Ten Times Worse

After the migration disaster, I promised myself we'd be smarter. Keep things portable. Don't go too deep.

Then AI took off, and both platforms rolled out their own AI services. New ways to call AI models.

New ways to store data for AI. New ways to build AI-powered features. All tightly integrated with everything else on their platform.

We looked at these seriously. I had calls with both teams about it.

And then we walked away.

Here's what I realized. The old lock-in was painful but survivable. A database here, a function there — you could swap pieces out one at a time if you really needed to.

AI lock-in is different. It's not one piece. It's the entire chain.

Your documents get converted into a format only that platform understands. Your search logic uses their tools. Your security references their permission system.

Your compliance docs name their specific services. Everything connects to everything else, and the service-specific dependencies can make replacement harder; not every component or data format is proprietary.

I started asking founders who had gone deep on these platforms what it would take to leave.

The answers were sobering.

One friend running a mid-stage startup told me his CTO estimated a seven-figure cost just to scope the migration. Not do it. Scope it.

Another described it as "rebuilding the company's entire AI brain from scratch."

And the thing that really got me? During setup, the cloud engineers recommend exactly these services. And the recommendations are good. They'll get you running fast. They'll save you time upfront.

They just make it nearly impossible to leave later.

What We Do Instead

After all of this — the month-long migration, the AI lock-in research, the sobering conversations — we landed on a principle that now governs every infrastructure decision we make:

Rent the datacenter. Own the intelligence.

For the basic stuff — servers, file storage, databases — we use AWS and Google Cloud happily.

This is what they're great at. Commodity infrastructure. The kind of thing where, if we needed to, we could pack up and move to another provider in a weekend.

For the AI layer, we go direct.

We call Anthropic and OpenAI ourselves. No middleman. No cloud provider sitting between us and the model.

A platform gateway may have different prices, features and contract terms. The original 15–30% comparison lacks a matched workload and invoice record, so it should not guide a current purchasing decision.

We run our own search tools on basic virtual machines.

We keep our data in open formats.

We use software that lets us swap providers by changing a settings file, not rewriting our codebase.

Is it more work upfront? Yes. Meaningfully more.

But portable formats and rehearsed recovery may reduce migration work; they do not guarantee that every hour invested prevents an hour of future work. And I know exactly what that month feels like.

The rule of thumb: if we can pack it up and move it in a weekend, it's safe.

Everything else is a trap with a payment plan.

The Real Reason This Matters

People hear this and assume it's about saving money. And yes, we believed direct access reduced our costs, but the roughly 20% figure here was not a reproducible like-for-like comparison.

But that's not why we do it.

We do it because AI moves too fast to be stuck.

The best model today might not be the best model in six months.

The cheapest provider right now might get undercut next quarter.

Entirely new approaches show up every few months.

If you're cemented to one platform, you watch all of that happen from behind a wall. You can see the better option.

You just can't get to it. Not without months of work and a seven-figure budget.

We'd rather do more work upfront and keep the door open.

Every quarter we ask ourselves one question:

Can we realistically move our core systems to a different provider without a multi-month project?

The day that answer is no, we've gone too deep.

The Bottom Line

AWS and Google Cloud are great landlords. Competitive rates. Reliable hardware. Lights always on.

But they're not your partners. They're not even trying to be.

Their integrated services can be useful and can create switching costs. Our responsibility is to decide which benefits justify those costs and test the exit path.

And the deeper you go into their AI platforms, the more true that becomes.

So use them for what they're genuinely best at. Rent the servers. Store the files.

But own your intelligence.

Call your AI providers directly.

Keep your data in formats you control.

Build everything like you might need to leave tomorrow.

Because in a world where AI changes everything every six months, the most valuable thing you can have isn't the best model or the cheapest compute.

It's the ability to move.

Share this:

New essays and letters, by email

Subscribe if you would like to hear from me when I have something worth sending. Everything here remains free to read.

Optional. Unsubscribe anytime.