Multi-Cloud Backup: What Cloud-Native Actually Means

The cloud-washing problem 

Every backup vendor in our market sells multi-cloud backup now. The marketing pages all look similar. The architectures underneath are wildly different, and the differences become expensive at exactly the wrong moment. 

I have spent the last few years watching customers learn this the hard way. A vendor sells them "cloud-native multi-cloud backup." The product is a fixed-size virtual appliance that the customer deploys into AWS or Azure, configures with maximum capacity guessed at upfront, and pays for whether or not they use it. That is not cloud-native. That is the old data center model running in a cloud-hosted VM. 

The shorthand I use for this is cloud-washing. The vendor's product has not really changed. Their slides have. 

Five things that make backup actually cloud-native 

Real cloud-native backup is not a marketing claim. It is an architecture, and the architecture has consequences for cost, scale, and recovery. Five characteristics matter. 

It scales elastically with the cloud. New VMs get protected automatically through API discovery. Old VMs stop generating backup load when they are decommissioned. No fixed capacity to guess at. No procurement cycle when the environment grows. 

It uses native cloud services as primitives. Native snapshots for VMs, native IAM for authentication, native object storage for retention, native marketplaces for billing. Not a vendor-built abstraction layer that recreates what the cloud already does. 

It bills on what you actually backed up. Pay-as-you-protect economics charged on source capacity actually protected and backup frequency. Not on capacity you may use someday. 

It does not require infrastructure deployment. No backup appliances to provision, no agents to install on protected workloads, no proprietary storage to size. The customer subscribes; the service runs. 

It moves data across clouds natively. Backup taken on AWS restores to GCP. Workload migration through the same mechanism. The clouds you choose today and the clouds you choose in three years all work through the same management. 

What cloud-washed backup actually costs you 

Three TCO patterns show up repeatedly in cloud-washed deployments. They are predictable enough that I can usually identify them in 15 minutes of a customer's bill review. 

Over-provisioning is the first one. Customer sizes the backup appliance for peak future load, runs at 30% utilization for the first two years, and pays for the unused 70%. With true cloud-native, you do not provision capacity. You consume it. 

Hidden cloud costs are the second. The vendor's backup appliance generates significant egress, cross-region replication traffic, or storage tier API calls that show up on the customer's cloud bill, not the vendor's. The customer pays the vendor a fixed price for the software and pays the cloud provider an unpredictable amount for the work the software causes. 

The migration tax is the third. Customer wants to move workloads from one cloud to another. The backup vendor's tool only works inside one cloud. The migration becomes a separate project with a separate tool, separate budget, and separate timeline. 

Multi-cloud reality across enterprises 

Flexera's State of the Cloud research has tracked multi-cloud adoption for years. While previous reports found that nearly nine in ten organizations (89%) were already using multiple clouds, the 2025 research shows the market has matured into a hybrid and multi-cloud norm. Organizations now use an average of 2.4 public cloud providers, and 70% operate hybrid environments that span both public and private clouds, reinforcing that multi-cloud is no longer a future-state architecture, it's how enterprises run today.

Most enterprise IT environments now span at least two public clouds plus on-premises infrastructure plus a portfolio of SaaS applications. A backup strategy that works for AWS and breaks at Azure does not match the reality customers are operating in. Neither does one that covers IaaS but ignores SaaS. 

The cost of getting this wrong is concrete. IBM's 2024 Cost of a Data Breach Report found that the global average cost of a data breach reached $4.88 million, up 10% year over year and the highest increase since the pandemic. The increase was driven largely by operational disruption, lost business, incident response costs, and prolonged recovery efforts. IBM's research also found that complex hybrid environments spanning cloud, on-premises, and containerized infrastructure can make breaches more difficult and costly to contain. Cloud misconfiguration, compromised credentials, and other security gaps remain among the leading contributors to breach risk. Backup coverage gaps that leave attackers a path to encrypt, destroy, or exfiltrate data can significantly increase the operational and financial impact of an incident.

What real multi-cloud coverage has to include 

The diagnostic questions that actually work 

Three questions, asked in the order below, will tell you in 10 minutes whether a vendor's multi-cloud claim is real or marketed. 

Ask first what you have to deploy. If the answer involves a virtual appliance per cloud, fixed capacity sizing, or maximum-Terabytes commitments, the architecture is cloud-hosted, not cloud-native. Real cloud-native means no infrastructure to deploy. 

Ask second how pricing works. If the answer is anchored to capacity you reserve up front, the vendor is selling appliance economics. Pay-as-you-protect economics charge on source data actually backed up, not on a guess at future maximum. 

Ask third what cross-cloud migration looks like. Have them walk through a workload backed up from AWS and restored to GCP. If the answer involves export, re-import, and a services engagement, the multi-cloud claim is the kind that breaks when you actually need it. 

What 'Your data. Your cloud. Yours to control.' actually means 

Our founder Simon Taylor has been saying this for years, and I have come to understand it as something more concrete than a tagline. 

The customer chooses the clouds. Not the backup vendor. If the customer wants to run AWS for production, Azure for DR, and GCP for analytics, the backup platform protects all three with the same policies and the same recovery model. The customer's cloud strategy is not constrained by what their backup vendor supports. 

Control means the data stays in customer infrastructure. Backups live in the customer's cloud accounts. The customer holds the keys. The vendor does not become a single point of failure or a single point of leverage. 

Common questions on multi-cloud backup 

Why not just use each cloud's native backup service? 

Native services are useful primitives within their own cloud. AWS Backup is good at protecting AWS workloads. It does not help with Azure, GCP, on-premises, or SaaS. Most enterprise environments span all four, and the operational cost of managing four separate backup tools, with four separate policies, four separate consoles, and four separate retention models, gets expensive quickly. 

What about the cost of egress when restoring across clouds? 

Egress is real, and it matters. The architectural answer is to keep backup copies in the cloud where the workload originates and only egress when actually recovering to a different cloud. Most days, that is zero. The day you need cross-cloud recovery, egress is a small fraction of the incident cost. 

How does multi-cloud backup handle compliance and data sovereignty? 

Region-by-region. Backup data stays in the customer-specified region. If GDPR requires EU data to remain in EU, the backup configuration enforces it. Compliance is a configuration choice, not a vendor commitment that may or may not hold. 

Is this realistic for organizations not yet multi-cloud? 

Most organizations end up multi-cloud whether they planned to or not. Acquisitions bring different clouds. Different business units pick different providers. SaaS sprawl adds workloads outside any chosen cloud. Choosing a multi-cloud-capable backup platform before you need it is cheaper than replacing your backup vendor when you do. 

What I would do next 

Audit your current backup. List every workload, where it runs, what protects it, and what would happen in a recovery scenario. The exercise usually reveals two or three workloads that are functionally unprotected. Those are the gaps multi-cloud backup is supposed to close. If yours is one of these, start there.