Your data is your responsibility, not your vendor’s

As a cloud architect, I’ve learned that your data is your responsibility, not your vendor’s. Providers will give you storage, compute, and managed services, but at the end of the day, it’s your job to make sure your data is protected, sovereign, and resilient.

That’s why I don’t trust a single vendor with my data, and you shouldn’t either.

Don’t Trust a Single Vendor with Your Data

The old 3-2-1 backup strategy, three copies, two formats, one offsite, still applies in the cloud era. Redundancy protects you from failure.

A backup is not “just a snapshot.” It’s a recording of your data at a certain point in time, an insurance policy against mistakes, corruption, or worse.

If you rely on a single provider, you’re putting your entire business at risk of one company’s outage, one change in terms of service, or one sudden price hike.

A second cloud provider isn’t a luxury, it’s a lifeline.

Data Sovereignty Matters

If there’s one thing we must emphasize, it’s data sovereignty. I prefer to store data in the country where you live. Why? Because you understand the rules there. You know how your government protects, or fails to protect, privacy. You know the regulations, the authorities, and the recourse you have if something goes wrong.

Sovereignty is not just about compliance, it’s about trust. Once your data crosses borders, it falls under foreign laws and foreign interests. That can expose you to risks you can neither predict nor control.

Here in Europe, and especially in the Netherlands, we value privacy and independence. We’ve built some of the strongest regulations in the world around protecting personal and business data. If you keep your data close to home, you benefit from those protections. If you send it abroad, you give them up.

And you may want to use the raw compute power of a hyperscaler. That’s fine. But when it comes to your data, think carefully about where it lives. Nothing stops you from running workloads in one place and keeping the actual data safe with a trusted provider closer to home.

That’s how you stay in control, and that’s how you protect Dutch and European values in practice.

There’s Only One Version of Your Production Data

Your production environment runs on one live dataset. That’s the truth. Backups are recordings, valuable but frozen in time. Replication across nodes or even across providers gives you resilience, but it comes with higher costs.

As an architect, your job is to strike the right balance. For some workloads, backups are enough. For mission-critical systems, live replication is worth the investment.

But never confuse a backup with a replica. They serve very different purposes.

Avoid Vendor Lock-in: Choose Standards

The surest way to get locked in is by leaning too heavily on proprietary cloud-native services. They start out convenient, but over time, they become the chains that tie you to a single provider.

I prefer standards:

• Kubernetes for orchestration
• Docker images for applications
• Postgres for databases
• S3-compatible storage for objects

These technologies are widely supported across clouds and make moving workloads realistic. The more you standardize, the less you depend on one vendor’s ecosystem.

Providers want you locked in. That’s their business model.

Cost, Complexity, and Security

Running across multiple providers isn’t free. It comes with operational overhead and requires discipline. But what does a data breach or extended downtime cost you?

The apparent “savings” of a single-cloud architecture often disappear the moment something goes wrong. Multi-cloud gives you leverage, options, and a chance to reduce dependency on a single security posture.

Of course, a larger footprint can expand your attack surface, but with the right security practices, you reduce your risk of catastrophic failure.

In the end, resilience isn’t cheap, but neither is losing control of your data.

Practical Steps You Can Take Today

Multi-cloud doesn’t have to be an all-or-nothing project. You can start small. Here are a few practical steps that already make a difference:

• Move your backups to another provider. It’s the easiest way to add resilience and independence. If one provider goes down or locks you in, your data is safe elsewhere.
• Run your database with a local provider. In most cases, you only need to change the connection string in your application. Your app won’t care where the data comes from, but you’ll sleep better knowing it lives under local laws.
• Use S3-compatible object storage outside your main cloud. It’s a standard supported by many providers. This lets you diversify storage without rewriting your applications.
• Separate compute from data. You can still leverage hyperscaler compute for scale and performance, while keeping your critical data at home with a trusted provider.

Small steps like these already reduce dependency and give you more control.

Closing Thought

Although you may rely on cloud-native services, remember that data always stands on its own. It’s the one asset you can usually take out of a locked-in provider. And the providers know that very well — that’s why they charge you for extracting data from their platforms.

Never put blind trust in a single provider. Design for sovereignty first and always keep independent control of your data. That way, you not only protect your sovereignty, but you also keep an easy exit strategy if your provider no longer meets your needs.