Multi-cloud data protection often runs as three single-cloud backup programs sitting side by side, and that split is where coverage gaps, retention drift, and unrecoverable data begin.
We work across AWS, Azure, and Google Cloud daily, and this is what a program that holds across all three looks like.
What multi-cloud data protection is and how it works
Multi-cloud data protection is the practice of keeping data backed up, retained correctly, and recoverable across more than one cloud provider under a single policy model. It spans coverage, retention enforcement, granular recovery, and audit evidence for workloads in AWS, Azure, and Google Cloud.
Running more than one cloud raises the bar on standard cloud data protection. Every policy has to survive translation into three enforcement systems and three restore paths, so resources stay protected, retention holds, recovery returns the exact record touched, and an auditor sees it from one view.
Multi-cloud data protection sits alongside multi-cloud security, not inside it. Security controls stop unauthorized access; data protection ensures a clean, recoverable copy after those controls fail. A perfectly encrypted database with no tested restore path still stays lost.
Both belong in a cloud program, and this piece takes on the protection half that most environments cover thinner.
How AWS, Azure, and Google Cloud enforce backup retention and immutability
Retention and immutability sound like policy decisions, but each provider enforces them through a different mechanism with different defaults, different lock-in behavior, and different workload coverage. A policy that reads identically on paper lands differently in each console.
AWS Backup Vault Lock: Governance vs. compliance mode
AWS Backup applies write-once protection through Vault Lock, which runs in two modes. Governance mode lets administrators with sufficient IAM permissions remove the lock later.
Compliance mode starts a cooling-off period of at least 72 hours. After that window, the vault and its lock become immutable, and no user or AWS itself can change or delete them.
That permanence cuts both ways. A recovery point with retention set to "Always" inside a locked compliance-mode vault is kept forever, at full storage cost, with no path to deletion.
Review retention on AWS before the 72-hour window closes, because afterward it stops being a decision.
Azure Backup: Soft delete plus immutable vaults
Azure Backup takes a recovery-first approach to deletion. Soft delete holds deleted backup data in a recoverable state for 14 days by default, extendable to 180 days.
Immutable vaults sit above that, blocking operations that would remove recovery points, and the setting can be locked to make it irreversible.
The practical difference from AWS is the order of defenses. Azure assumes deletion will happen and makes it reversible for a window.
AWS compliance mode assumes deletion must be impossible and removes the option entirely. Neither model maps cleanly onto the other, and a shared policy absorbs that translation.
Google Cloud Backup and DR: Enforced retention on backup vaults
Google Cloud's Backup and DR service stores backups in backup vaults designed to be immutable and indelible, with minimum enforced retention configurable up to 99 years.
Backups cannot be modified or deleted before that period elapses, and the underlying storage stays isolated from direct customer access.
Vault storage supports Compute Engine instances and disks, Cloud SQL, AlloyDB for PostgreSQL, and Filestore, with additional workload types moving into vault support over time. Workloads outside the current vault set need separate protection paths, so one project can hold strongly enforced vaults and unenforced resources at once.
What the 3 enforcement models mean for one shared policy
One written policy, three enforcement floors. Holding them aligned manually across accounts, subscriptions, and projects is the operational core of multi-cloud data protection. It is also the work a single protection layer across AWS, Azure, and Google Cloud exists to absorb.
How regional cloud outages take backups down with production
Multi-cloud is now the default at scale. Among the 583 cloud professionals surveyed for Eon's 2026 Cloud Data Infrastructure Report, 54% operate across three or more clouds, 97% of multi-cloud teams trust their cross-cloud restore, and 84% of them report at least one recovery failure in the past 12 months.
Most of that gap traces to two failure modes: the cloud the backup lives in going down, and the credentials that reach the backup going wrong.
Running more than one cloud is often justified as resilience. That argument only holds if the recovery path stands independent of the platform it protects, and in most environments it does not.
The clearest test came in October 2025, when a DNS issue in DynamoDB took down large parts of AWS us-east-1 for roughly 15 hours end to end.
Backups reachable only through the affected control plane stayed out of reach for the full duration, however many other clouds the organization ran.
An outage is the visible version of this dependency. The quieter version is architectural. Snapshots stored in the same account as production, governed by the same credentials, sit inside the same blast radius as the data they exist to protect.
How compromised credentials wipe backups alongside production
Every major cloud enforces deletion protection differently, but all three trust valid credentials. When those credentials go wrong, the enforcement differences stop helping.
In April 2026, an AI coding agent at PocketOS hit a staging credential mismatch and resolved it by deleting the production database and its volume-level backups in nine seconds. The agent held valid credentials and used approved APIs. Every copy reachable through that identity went with the primary.
This is the case for keeping recovery copies logically air-gapped. Eon stores immutable backups in a vault account production credentials cannot reach, across AWS, Azure, and Google Cloud, with object lock by default. A compromised key can take production down without touching the copy that brings it back.
What EU regulation is doing to cloud portability by January 2027
Keeping recovery copies portable across providers has historically carried a tax in egress fees and switching charges. EU regulation is removing that tax on a fixed timeline, which is worth planning around now.
EU Data Act Article 29 removes switching charges from January 12, 2027
Under Article 29 of the EU Data Act, providers may charge only reduced, cost-linked switching charges today. From January 12, 2027, they may impose no switching charges at all. The rule reaches any provider serving EU customers, and it lowers the cost of treating one provider as replaceable.
DORA requires financial entities to hold tested exit strategies
For banks, insurers, fintechs, and payment institutions in the EU, portability moved from good practice to obligation on January 17, 2025, when DORA took effect.
Article 28 of DORA requires financial entities to hold documented, tested exit strategies for ICT providers supporting critical functions, and to assess concentration risk before signing new arrangements. A protection program that can restore workloads and hand over historical data independently of any one provider is a large part of that evidence.
7 multi-cloud data protection best practices
These practices apply once a second provider enters the picture, where single-cloud backup hygiene stops covering the job.
1. Write one policy model, then translate it down to each provider's floor
Define retention, immutability, and recovery targets once, in business terms, before touching any console. Then map each requirement onto the enforcement mechanism each cloud offers, and record where the mechanisms diverge.
How to check this:
- Every data class has one documented retention and immutability requirement.
- Each requirement maps to a named control in AWS, Azure, and Google Cloud.
- Divergences, such as Azure's soft delete window, are recorded up front.
- Policy changes propagate to all three clouds through one workflow.
2. Put the recovery copy outside the identity boundary of every cloud it protects
Store immutable copies in a separate account or project that production credentials cannot reach. Separation at the account boundary keeps a compromised key, an over-permissioned pipeline, or a misfiring AI agent from deleting the copy alongside the primary.
Immutability settings inside the production account help, but the PocketOS incident showed how far valid credentials can reach. Isolation at the account boundary is the missing control.
3. Set the recovery unit by data class and hold each restore path to it
Native snapshots recover at the disk, volume, database, or resource boundary rather than at record or table granularity, which turns a single corrupted table into restoring the whole surrounding resource.
Decide per data class whether an incident requires a record, a table, a file, or a full resource, then confirm each cloud's restore path can deliver at that unit.
Granular restoration closes the distance between the two. NETGEAR cut recovery of a 10TB SQL Server database from 24 hours to under three with Eon, because the restore stayed scoped to the data the incident touched.
4. Verify coverage continuously from one view
Coverage checks run per cloud by default, which is why gaps first surface during audits. Manual tagging is what decays fastest: a database spun up without the right tag inherits no policy, a VM whose contents moved from test data to customer records keeps its old classification, and nothing alerts because nothing knows.
Cloud Backup Posture Management (CBPM) replaces that dependency with continuous classification. Eon discovers new resources on creation, classifies them by their content, applies the matching policy automatically, and surfaces drift the moment coverage or retention falls out of line.
SoFi runs this model across five AWS regions with Eon, applying retention changes in seconds across the full environment and holding regulatory alignment as regions and workloads grow.
5. Rehearse the restore you would run with a primary console unavailable
The October 2025 us-east-1 event turned regional console dependency into a tested scenario. Run restore drills that assume the affected provider's control plane is degraded, and measure whether recovery targets still hold under that constraint.
How to test this:
- Restore a workload into a different region without using the affected region's console.
- Confirm backup data stays reachable and queryable during a simulated provider outage.
- Time the drill against the recovery targets your policy documents claim.
6. Keep protected data in open formats so a copy stays portable and readable
Format is where portability gets decided. A snapshot in a proprietary provider format restores into that provider and nowhere else.
The same data held in Parquet, Iceberg, and Delta Lake stays readable by any engine that speaks those standards, can support data portability as part of a DORA exit strategy, and can be ingested zero-ETL into Snowflake, Databricks, BigQuery, and Athena for analytics and AI without a full restore.
7. Attribute backup spend per cloud, account, and workload
Backup costs spread across three billing systems hide waste that a single bill would expose. Attribute protection spend to specific workloads and clouds, then review retention against what each data class requires.
Cloud-native platforms such as Eon typically bring backup storage spend 30-50% below native hyperscaler tools through deduplication, compression, and incremental snapshots. Eon's Cost Explorer shows that spend across AWS, Azure, and Google Cloud in one view.
Common mistakes to avoid in multi-cloud data protection
The failures below tend to show up only when a restore is already running or an auditor is already asking. Each one is easy to prevent up front and expensive to fix after the fact.
- Treating three green dashboards as one protected environment. Each console reports only on what it knows about, so an incident or auditor usually finds the unprotected resource first.
- Locking retention before the policy is settled. Compliance-mode Vault Lock and Google Cloud enforced retention have no undo, and a value locked in error is a storage bill with no end date.
- Assuming a second cloud reduces risk by existing. Respondents on three or more platforms in Eon's 2026 report ran into more recovery failures than those on one or two.
Where to start with multi-cloud data protection
Start from the four questions a working program answers.
What is protected across all three clouds right now? What retention is enforced, and where is it locked? What recovery unit can each workload restore at? And, which copies survive if one provider's credentials or control plane go down?
Multi-cloud data protection holds together when one policy model, one isolated recovery copy, and one view of coverage span every provider you run. Eon delivers that layer across AWS, Azure, and Google Cloud, with logically air-gapped immutable backups, CBPM, and granular recovery under one platform.
Want to see what your protection posture looks like across every cloud you run? Book a demo with Eon and walk through coverage, gaps, and cost across your full environment.
Frequently asked questions
What is multi-cloud data protection?
Multi-cloud data protection is the practice of keeping data backed up, correctly retained, and recoverable across more than one cloud provider under a single policy model. It spans coverage verification, retention enforcement, granular recovery, and audit evidence across AWS, Azure, and Google Cloud.
What is the difference between multi-cloud data protection and multi-cloud security?
The main difference between multi-cloud data protection and multi-cloud security is scope. Security controls who can access data, while data protection keeps a clean, recoverable copy available after access controls have been bypassed or misused. A full cloud program needs both.
Do native cloud backup tools work for multi-cloud environments?
Native tools such as AWS Backup, Azure Backup, and Google Cloud Backup and DR protect workloads inside their own cloud, each with its own policy model and restore paths. Running all three across different consoles is the gap a unified layer such as Eon closes.
How does the EU Data Act affect multi-cloud data protection?
The EU Data Act removes cloud switching charges from January 12, 2027, and caps them at direct costs until then. Lower exit costs make portable, open-format backup copies more valuable, because moving protected data between providers stops carrying a fee.
What is a logically air-gapped backup?
A logically air-gapped backup is a copy stored in an isolated account that production credentials cannot access, with the separation enforced through cloud-native access controls. It stays intact when production credentials are compromised, misused, or turned against the environment by an automated agent.
How much can multi-cloud data protection reduce backup costs?
Cloud-native protection platforms typically cut backup storage spend by 30-50% compared with native hyperscaler tools, through deduplication, compression, and incremental snapshots. Actual savings depend on data volume, retention settings, and workload mix, with cost attribution per cloud revealing where the waste sits.
