How to avoid cloud vendor lock-in without overengineering

You avoid cloud vendor lock-in by keeping two things portable: your data, in formats another provider can load, and your deploys, in tools another provider can run. Then you check, once, what leaving would actually take. You don't need a second cloud or an abstraction layer for any of it.

The exit bill used to be the scary part. Since early 2024, AWS, Google Cloud and Azure have all waived the transfer charge for customers who move out, with conditions. What still keeps teams in place is everything the waivers don't cover.

What actually locks you in?

Four things. Three cost you engineering time, and egress is the one that shows up on your bill.

Data in a format only one service reads. A Postgres dump loads into any Postgres. A DynamoDB export comes out as DynamoDB JSON or Amazon Ion, and getting that into another database means writing a transform for every table.
Proprietary services in the request path. A queue, an auth service or a function runtime that exists on one cloud is code you rewrite before you can move.
Infrastructure defined in one cloud's tool. A CloudFormation template only describes AWS. Anything clicked together in a console has to be rebuilt by hand.
Egress while you run both. Until the cutover, your users still pull their traffic from the old cloud, and the old cloud still meters it.

How can a startup avoid lock-in without overengineering?

Don't run two clouds just to avoid depending on one. Multi-cloud doubles the accounts, the networking, the permissions and the on-call, and a small team pays that every week to avoid a move it might make once. An abstraction layer over every cloud service is the same trade: you build and maintain your own worse version of each service so you never have to rewrite against the real one.

Our take: use the portable default wherever it costs you nothing extra. That's most places:

PostgreSQL or MySQL for your main database. Managed Postgres on any cloud is still Postgres, so the managed service saves you the ops work without changing your data.
The S3 API for object storage. Most providers speak it, and tools like rclone copy buckets between them.
Containers, run on Kubernetes or on plain VMs with Docker Compose. The image runs the same anywhere Docker does.
Terraform or OpenTofu for infrastructure.

Terraform doesn't make you portable on its own. Resources are written per provider, so an aws_instance block won't create a server anywhere else. What carries over is the workflow: plans, state and the habit of keeping every resource in code. You rewrite the resource blocks, not the process. If licensing matters to you, HashiCorp moved its products to the Business Source License in August 2023, and OpenTofu is the open-source fork of Terraform.

When a proprietary service saves your team weeks, use it, and write its exit beside it in the repo: what you'd replace it with and how the data comes out. If you can't name the exit, that service is your lock-in.

Which database export options keep you portable?

What matters is the engine, not the host.

Data store	Export tool	What you get	Loads elsewhere as is?
PostgreSQL (self-run, Amazon RDS, any managed Postgres)	`pg_dump`	A plain SQL script, or a custom, directory or tar archive for `pg_restore`	Yes, into any PostgreSQL
MySQL	`mysqldump`	SQL statements that recreate the tables and their data	Yes, into any MySQL
Redis	RDB snapshot or AOF file	Redis's own persistence files	Yes, into another Redis server
Amazon DynamoDB	Export to S3, with point-in-time recovery turned on	DynamoDB JSON or Amazon Ion files	No: you write a transform for each table

Then test the restore. Load last night's dump into a fresh server on another provider, point a staging copy of your app at it and run your checks. A dump you've never restored is a hope, not an exit.

How do you avoid lock-in with a data lake?

Keep the files and the tables in open formats, and the engine becomes a choice you can change. Apache Parquet is an open, column-oriented file format. Apache Iceberg is an open table format that Spark, Trino, Flink, Presto, Hive and Impala can all work with, so the same tables answer queries from whichever engine you pick.

Store those files in S3-compatible object storage and the storage is portable too: rclone's S3 backend works with AWS S3 and a long list of S3-compatible providers. Data lake lock-in comes from a table format only one warehouse can read, or a query service that's the only thing able to read your data.

Does leaving AWS, Google Cloud or Azure still cost egress?

Usually not for the move itself. All three waive the transfer charge for customers who leave, and each sets its own rules.

Provider	What's waived	How you get it	Window and limits
AWS	Data transfer out to the internet when you move all your data off AWS, or all of it off one AWS service	Ask AWS Support. Approved moves get credits for the data migrated, and you don't have to close your account	180 days to finish, outside the EU
Google Cloud	Network data transfer for customers who stop using Google Cloud and move their data to another cloud or on premises	Google lists the steps on its exit page	All customers, globally
Azure	Egress for moving all your data off Azure, as an invoice-level credit	Open a Support request with your start date, move the data, cancel every subscription, then claim the credit	60 days from your start date. ExpressRoute, VPN, Front Door and CDN traffic isn't covered

The waiver pays for the copy. It doesn't pay for the weeks you serve users from the old cloud while the new one comes up, and that's where egress adds up: AWS charges $0.09 per GB in US East for the first 10 TB a month after the free 100 GB. Our breakdown of egress fees prices 1, 5 and 20 TB a month on all three.

What should you track before you need to leave?

Three numbers tell you how locked in you are, and none of them needs a consultant.

Hours to restore your main database on another provider. Measure it by doing it. If nobody has done it, the honest answer is "unknown".
Services with no open equivalent. Count them. Each one is a rewrite in your exit plan, and the count should only go up on purpose.
Share of your infrastructure in code. Everything outside Terraform, OpenTofu or your deploy scripts is something someone rebuilds by hand from memory.

Write the three down once a year, next to the date of the last restore test. If a number gets worse, you'll see it while it's still cheap to fix.

How does American Cloud avoid lock-in?

We built American Cloud on the defaults above. Our promise: any managed service on American Cloud is portable to any other cloud if you ever choose to leave. We don't charge egress fees, so pulling your data out costs nothing in transfer, whether you're running a restore test or moving for good.

Managed PostgreSQL, MySQL and Redis run the standard engines, with standard connection strings and no proprietary drivers. pg_dump and mysqldump work on them like anywhere else.
Database backups go to the destination you set: an American Cloud Object Storage bucket or any other S3-compatible repository, so a copy of your data can live outside our cloud.
Object storage speaks the S3 API, so s3cmd, rclone and the AWS CLI work with it.
Kubernetes gives you standard kubectl and Helm with no wrappers, so your manifests run on any cluster.
Our Terraform provider is on the Terraform Registry, so the stack lives in code from day one.

If you're coming from AWS, the AWS migration playbook takes it a service at a time, from EC2 and S3 to EKS and RDS. You should stay with a cloud because the service is good, not because leaving is expensive.