Is multicloud a backup strategy?

What does multicloud actually solve?

Multicloud means running workloads on more than one cloud provider, for example AWS and Azure. It solves vendor lock-in and, when designed for it, keeps some services running if one provider has a regional outage.

Those are real benefits. You can place workloads where they fit best, negotiate from a stronger position and avoid being stuck with one provider's pricing or roadmap. For applications built to fail over, a second cloud can keep customers served while the first recovers.

What multicloud doesn't do is protect the data inside those workloads. It's tempting to read "our data is in two clouds" as "our data is backed up". It isn't, and the difference only shows when something goes wrong. That gap is what backup as a service exists to close.

Why doesn't multicloud protect your data?

Because the copies in a multicloud setup are live copies. When data is synchronised or replicated between platforms, a deletion, a corrupt write or a ransomware encryption is copied too, often within seconds.

Cloud providers say this plainly about their own replication. Microsoft's Azure Storage redundancy documentation states: "Redundancy protects against hardware failure, not against data-modifying operations." The same logic applies when you replicate across providers.

Common ways data is lost in a multicloud environment:

• Synchronised mistakes: an admin deletes a bucket or a folder and the sync removes it everywhere.
• Corruption that spreads: an application bug writes bad data and every connected copy takes it.
• Ransomware with admin rights: an attacker with cloud credentials can encrypt or delete data in each environment those credentials reach.
• No way back in time: without versioned backups, there's no clean point to restore to.

Data protection needs three properties that multicloud doesn't provide by default: versioning, isolation from production credentials, and a tested way to restore.

What do recent cloud outages show about shared dependencies?

They show that hidden dependencies, especially identity, DNS and shared services, can take down several systems at once. Having two clouds helps less than expected if both rely on the same failing component.

The Cloudflare case is the multicloud lesson in miniature. Cloudflare wrote that although the trigger was a vendor failure, "we are ultimately responsible for our chosen dependencies". One storage dependency on another provider's cloud stopped login services for customers who didn't know that dependency existed.

This isn't rare. Over nine years of tracking, the Uptime Institute's 2026 outage analysis found that third-party IT and data centre service providers, including cloud and internet giants, accounted for about two-thirds of publicly reported outages.

Multicloud vs backup: what's the difference?

Multicloud keeps services available; backup makes data recoverable. They answer different questions, so a resilient setup needs both.

There's one place they meet. The CISA #StopRansomware Guide suggests considering a multi-cloud solution for cloud-to-cloud backups, "in case all accounts under the same vendor are impacted". A second provider is a good place for a backup, provided it really is a backup. The NCSC UK principles for ransomware-resistant cloud backups set the bar: backups should resist deletion even by compromised admin accounts, and earlier versions should stay restorable.

Do you still need backup in a multicloud setup?

Yes. Multicloud lowers the chance that everything is unavailable at once. It does nothing for the day someone deletes the wrong data, an attacker encrypts it, or an account is locked or closed.

It's also a compliance point. Article 21(2)(c) of the NIS2 Directive requires essential and important entities to take measures for "business continuity, such as backup management and disaster recovery, and crisis management". Uptime across two clouds doesn't show you can restore lost data. Restore logs do. See what Article 21 asks for.

For systems that must come back fast, add disaster recovery on standby infrastructure, so you're not waiting for any cloud provider to finish its own recovery.

How do you build a resilient multicloud data strategy?

Keep multicloud for availability, and add a backup layer that sits outside it. Map your dependencies, set recovery targets and test against them.

1. Map critical data and dependencies: which identity provider, DNS, SaaS tools and storage does each system rely on, in every cloud?
2. Set RPO and RTO per system: how much work you can lose and how long you can be down. See RTO and RPO explained.
3. Back up outside the production clouds: use separate credentials, so one compromised admin account can't reach both production and backup.
4. Make one copy immutable and one air-gapped: follow the 3-2-1-1-0 rule.
5. Plan for an identity outage: keep break-glass accounts and recovery runbooks somewhere reachable when single sign-on is down.
6. Test restores quarterly and after major changes: see how to verify your backup works.

We back up AWS, Azure and Google Cloud workloads to our own Tier III data centres in the Netherlands and Germany, under EU law and independent of US hyperscalers. Backups are immutable with Object Lock, an air-gapped copy is kept, and admin actions require MFA.

What to do next

Multicloud is a sound choice for flexibility and uptime. It isn't a backup strategy. If your only copies are live copies in other clouds, a single mistake or a single compromised admin account can reach all of them.

Start by listing which of your systems would have no clean restore point if data were deleted today. Then add an independent, immutable copy outside your production clouds. Our backup as a service overview shows how that layer works.

Want a second opinion on your multicloud setup? Get a free assessment from our engineers, in Dutch, German or English.

This article is information, not legal advice.