Cloud-native backup tools are good at protecting resources inside their own cloud, and structurally unable to restore outside it. That is not a defect — it is the scope they were built for. This page explains where that boundary sits and how to tell whether it matters for your recovery plan.
What native backup does well
AWS Backup, Azure Backup, Google Cloud Backup and OCI’s backup services are first-party, deeply integrated, and require no extra vendor. Snapshots are fast, consistent, and cheap to take. For same-cloud, same-account operational recovery — someone deleted a volume, a deployment went wrong — native tooling is usually the right answer and the fastest path back.
Four limits that surface during a real recovery
1. Recovery points cannot leave the cloud that made them
A snapshot is a provider-specific object. It is meaningful to the API that created it and to nothing else. That is fine until the recovery requirement is “restore somewhere that is not here” — during a region-wide event, a provider contract ending, or a regulator asking whether exit is actually possible. A backup you cannot restore elsewhere is a copy, not an exit.
2. Topology is not part of the backup
Native tools protect resources individually. They do not record how those resources relate — which subnet a VM sat in, which key vault held its secrets, which security group governed it. Rebuilding an environment from a pile of independent snapshots is a manual reconstruction exercise, performed under time pressure, by whoever is on call. This is where most restores actually fail.
3. Each cloud is its own operational island
A multi-cloud estate means separate interfaces, policy models, retention semantics and audit formats per provider. Proving a consistent retention policy across four clouds means proving it four times, in four dialects, to an auditor who wants one answer.
4. SaaS is usually out of scope entirely
Microsoft 365, Google Workspace and Intune are not covered by infrastructure backup services. Providers protect their own platform and offer retention features, but that is a different guarantee from an independent point-in-time copy you control. Most compliance frameworks treat SaaS backup as the customer’s responsibility.
How to tell whether this affects you
Four questions that usually settle it:
- If your primary cloud region were unavailable for 48 hours, where would the workload run?
- If you had to exit your primary provider within 90 days, what would the recovery path be?
- When did you last restore a complete environment — not a single resource — and how long did the dependency reconstruction take?
- Who holds an independent copy of your Microsoft 365 or Google Workspace data?
If any answer is uncomfortable, the constraint is portability, not backup quality.
What a portable recovery point requires
- A provider-neutral representation of each resource, so it can be rebuilt against a different API.
- The dependency graph, captured at backup time, so restore order is derived rather than guessed.
- Translation with a compatibility report, so gaps between source and target are visible before execution rather than discovered during it.
- One policy model across providers, so retention and compliance are stated once.
That is what cross-cloud restore and dependency-ordered backup are for.
Common questions
Should we stop using native backup?
No. Native snapshots remain the fastest route for same-cloud rollback. The layers solve different problems and most mature teams run both.
Is this only relevant to multi-cloud organisations?
No. Single-cloud organisations carry the largest exit risk, because the entire recovery plan depends on one provider being available and one contract staying signed.
Talk to us about where your current recovery plan stops.