A hospitality-tech company hit a staff error that corrupted one custom field across roughly 1,400 booking records. Nothing was down. Nothing was lost. Every row was still there; one field in each was wrong.
The fix on paper was a few kilobytes of corrected values. The fix in practice was restoring a ~4 TB managed PostgreSQL instance into a temporary environment, at a cost of 30+ hours and two engineers, just to reach the rows that needed editing.
They didn't need a restore. They needed a lookup. The backup product only sold them one of those.
Two paths welded into one word
The industry treats "get my data back" as a single operation called restore. It is two operations that have been fused together.
- The restore path rebuilds a running system. RDS goes back to RDS, EC2 back to EC2, in the original cloud. It is constrained by cloud APIs and machine-image formats. That constraint is inherent to a correct restore: a running system must return to its original service and cloud.
- The read path retrieves one record, one table, or one point in time. It boots nothing and provisions nothing.
Because the read path provisions nothing, it is not bound to the source cloud. It only needs to run wherever the backup vault lives. So the vault does not have to sit in the source cloud either.
A cross-cloud vault is exactly that: data originating in one provider, with its backup vault physically residing in a different provider, in an account you own.
Concretely: back up an Amazon RDS or Aurora database into a Google Cloud vault, and every read - audit lookup, legal-hold extraction, single-record retrieval - happens in GCP under GCP IAM, with no dependency on AWS at read time. The read path runs in the vault's cloud through a cloud-native engine (BigQuery for a GCS vault, Athena for an AWS vault). Full restore still returns to AWS, correctly, because that is the only correct home for a running RDS instance. The direction reverses cleanly: a GCP Cloud SQL database can back up into an AWS vault and be queried there.
Cross-cloud, not multi-cloud
Most people who say "multi-cloud backup" mean one console for the clouds they already run in: one control plane, consistent policy, unified posture across AWS, Azure and GCP. Eon does that, but it is not the subject here. Cross-cloud means the vault sits somewhere the source does not.
Audit, compliance, and legal hold: retrieval as a query
Audit, compliance, and legal-hold requests become a query, not a restore project, once the read path can reach individual records directly. An auditor, a regulator, a legal hold, or a customer dispute asks for specific historical records. Under the conventional model, the only path is a full restore: provision a target, rehydrate the whole database, query it, extract, tear down. That is hours to days of engineering time and compute cost to answer a question about a handful of rows.
Because it is expensive, teams avoid it, so the restore path goes untested until a real incident forces it.
Eon makes retrieval a query. Eon supports restoring records that match a SQL query and querying database snapshots directly from the console or the API. Eon's own framing for this shift is compliance evidence retrieval moving from days to minutes.
Three cross-cloud angles matter specifically here:
- Jurisdictional and provider separation. Some regulatory and internal-risk regimes want the evidentiary copy outside the blast radius of the production provider, not merely in a different region under the same control plane and the same account.
- Evidence retrieval that survives a source-cloud outage. Compliance deadlines do not pause during an incident.
- Provider-independent chain of custody. The retained copy does not depend on continued availability of, or good standing with, the source provider.
Reading the contents also gives you continuous proof the backup is good, which a green "job succeeded" status never tells you.
Decommissioned applications: keep the data, retire the app
When you retire an application - a legacy ERP, an acquired company's stack, a sunset product line - the data usually must be retained for years for regulatory, audit, or legal-hold reasons. The application does not need to survive. The queryability does.
Today's options are all bad. Keep the application running purely so the data stays reachable, which is expensive and a growing security liability. Archive to cold storage, where answering any question means a restore project, sometimes requiring the retired application to be rebuilt. Or bolt an archival tool onto deep-archive storage and accept that retrieval is slow and manual.
The read-path model fits: retain the data in an immutable vault, query it directly for the whole retention period, and never rebuild the application. Retired data also has no reason to stay in the provider the retired application happened to run in. Once the app is gone, the only requirements are durability, cost, governance, and queryability. The provider-lock-in cost lands hardest in post-acquisition consolidation, where the inherited estate sits in a provider the acquirer does not otherwise use and does not want to keep an open account with indefinitely.
What the October 20, 2025 AWS outage proved
A source-cloud failure freezes your restore path, but a read path in another cloud can keep answering questions about your data. That day, a DNS race condition in DynamoDB's automated DNS management left the regional DynamoDB endpoint unresolvable. It cascaded across the region for roughly 15 hours and affected on the order of 140 services, including EC2, Lambda, S3 and RDS. Because us-east-1 hosts global control-plane functions such as IAM and Route 53, even multi-region deployments could not perform some operations.
With a vault in another cloud, you could still have read your data during those hours. You could have answered "what did this record say at 3 a.m.," and produced a value for an incident bridge or a regulator, because the read path runs in the vault's cloud and never touches the source cloud.
You could not have failed over, run your application, or restored a database into the other cloud. Restore returns to the source cloud, and when the source cloud is down, restore waits.
Four questions for any backup vendor
Whatever you are evaluating this quarter, four questions separate a read path from a restore path:
- Does retrieving a single record require restoring the entire resource?
- Does this cover the contents of relational databases, or only files and documents?
- Can the vault, and the read path, live outside the cloud the data came from?
- What exactly happens on a full restore: which cloud, which service, and are there conversions you should not assume?
Ask the fourth of every vendor, Eon included. The answer should be unambiguous.
What this does not do
Eon's cross-cloud read path has three limits, stated plainly so none of them surprises you in a POC:
- Not a cross-cloud "migration" service. Full instance and cluster restore returns to the original cloud and the original service, every time.
- No machine-image conversion between clouds, and no service conversion. RDS does not become Cloud SQL, and Cloud SQL does not become RDS. This is not migration.
- Record-restore output lands in the same cloud as the vault. Read in GCP, results land in GCP; output is not pushed back across a cloud boundary.
"Readable in another cloud" is not "exfiltrated"
Reading AWS data from a GCP vault is not exfiltration. The security boundary is the account and its IAM, not the cloud provider.
Eon's vault sits in a dedicated, customer-owned account, logically air-gapped from production, with object lock and immutability, encryption at rest and in transit, and programmatic-only access - no human console. Those controls are identical regardless of which provider hosts the vault. A second-cloud vault is not less governed than a same-cloud one; it is the same control model with an added failure-domain boundary a same-cloud vault cannot provide. The data moves between two accounts you own; it never leaves your control.
The 1,400-record incident was a data-correction problem solved with a disaster-recovery tool. If audit, legal-hold, and single-record requests land on your team as restore work, the read path is the difference between a query and a 30-hour project. Request a demo and bring the retrieval you dread most.
FAQ
Can I back up an AWS database to Google Cloud?
Yes. Eon supports cross-cloud vaults for managed relational databases, so an Amazon RDS or Aurora database can back up into a Google Cloud vault in an account you own. Reads then run in GCP under GCP IAM, while a full restore still returns to AWS.
What is record-level restore, and does it require restoring the whole database?
Record-level restore retrieves specific rows or tables without rebuilding a running instance. Eon supports restoring records that match a SQL query and querying database snapshots directly from the console or API, so retrieving a handful of rows never requires a full restore.
Can I query backup data without restoring it?
Yes. Eon's read path queries database snapshots directly through the console or API without provisioning a target or rehydrating the whole database, using a cloud-native engine in the vault's cloud - BigQuery for a Google Cloud Storage vault and Athena for an AWS vault. For example, you can run a point-in-time query in place instead of launching a full restore:
-- Query a point-in-time snapshot in place - no target provisioned, no full restore
SELECT booking_id, custom_field
FROM bookings
WHERE updated_at BETWEEN '2025-10-19' AND '2025-10-20';What is the difference between cross-cloud backup and multi-cloud backup?
Multi-cloud backup means one control plane and consistent policy across AWS, Azure, and GCP. Cross-cloud backup means data originating in one provider with its backup vault physically residing in a different provider, in an account you own.
If my source cloud has an outage, can I still read my backups?
If the vault lives in a different cloud, yes. The read path runs in the vault's cloud and never touches the source cloud, so you can retrieve a record even while the source provider is down - as during the October 20, 2025 AWS us-east-1 outage, which lasted roughly 15 hours and affected on the order of 140 services. You could not, however, have failed over or restored the database into the other cloud.
.png)