Cloud-Native Backup: Immutability and Fast Recovery

A snapshot is not a backup

The most expensive assumption in cloud operations is that snapshots are backups. They are not, and the gap only reveals itself during an incident. A snapshot is a point-in-time reference held inside the same account, same provider, and often the same region as the volume it protects. It is fast, cheap, and excellent for rolling back a bad deploy. It is also fully reachable by any identity that can reach production — which means the person, script, or intruder who can delete your database can delete its snapshots in the same API call.

Snapshots fail as backups on four specific counts:

• Shared fate. They live in the blast radius they are supposed to protect. A compromised account, a deleted project, or a billing suspension takes the snapshots with the source.
• Deletable by production credentials. No separate authority is required. If an attacker owns your control plane, your recovery copies are one command away from gone.
• Weak retention discipline. Snapshot lifecycle policies are easy to disable or shorten, and they rarely enforce a legal hold that survives an administrator.
• No independent restore path. Recovering from a snapshot assumes the surrounding account, network, and IAM still exist and are trustworthy. After a compromise, none of that is safe to assume.

Use snapshots for what they are good at: fast operational rollback measured in minutes. Then build a real backup tier beneath them — copies held somewhere the production blast radius cannot reach.

Isolation is the whole point: cross-account and cross-region

A backup earns the name only when losing production cannot also lose the backup. In cloud, that means putting real boundaries between the two: a separate account (or subscription, or project) with its own identity plane, and a separate region for geographic durability. The backup account should be a one-way destination — production can push copies into it, but production credentials cannot read, alter, or delete what lands there.

Figure: real backups sit in their own account and region so a single compromise or region loss can never reach every copy at once.

Design the isolation deliberately:

• Separate the identity boundary. The backup account uses its own directory, its own administrators, and its own multi-factor authentication. A tenant-wide or domain-wide compromise of production must not carry authority into the backup account.
• Make the copy flow one-directional. Production writes to the vault; only a small, tightly scoped role in the backup account can restore. Nobody logged into production should be able to purge the vault.
• Cross the region boundary too. A backup in the same region as production survives an account compromise but not a regional outage or a mistaken region-wide deletion. Tier-1 data belongs in at least one other region, and for the most critical workloads, another provider.
• Watch the vault like tier-0. Alert on any attempt to change retention, disable logging, or delete a copy. Those actions are the earliest signal of an attacker who found the backups.

This is the structural difference between a copy that happens to exist and one you can count on. It also underpins broader cloud security posture: recovery data held outside the identity and network perimeter that an attacker has already breached.

Object lock: the copy ransomware cannot delete

Isolation stops an attacker from reaching the vault with production credentials. Immutability stops anyone — including a compromised backup administrator — from destroying what is inside it. Object-lock storage writes each copy once and forbids modification or deletion until a defined retention date passes. In compliance mode, not even the account root can shorten that clock.

Ransomware crews hunt backups first, because deleting recovery copies is what forces payment. Object lock removes that option. To make it effective:

• Prefer compliance-mode locks for tier-1 data, where retention cannot be reduced by any human until it expires. Governance mode, which privileged users can override, is a weaker control reserved for lower tiers.
• Set retention longer than attacker dwell time. Human-operated ransomware often lingers for weeks before it detonates. If your immutable window is seven days, the only clean, pre-intrusion restore point may already have aged out. Thirty days or more for critical data is a reasonable floor.
• Separate the lock authority from production. The role that sets retention must not be the same identity that runs day-to-day operations.

Object lock turns backups from a target into a guarantee, and it is a core building block of resilient managed backup and disaster recovery.

The gaps everyone forgets: SaaS and cloud databases

Two categories of data routinely fall through the cracks because teams assume the provider handles them.

SaaS platforms. Microsoft 365 and Google Workspace run a shared-responsibility model: they keep the platform available, but your mail, files, chat history, and sites are your responsibility. Native recycle bins and retention windows are short-term safety nets — typically 30 to 93 days of soft deletion — not backups. A compromised account that purges files, a malicious insider, or a misconfigured retention policy can destroy data permanently, and the provider will not restore it. Back these platforms up to independent, immutable storage held outside the same tenant identity.

Managed cloud databases. Automated database backups and point-in-time recovery are convenient, but they usually live in the same account and region as the database and are governed by the same credentials. Treat them like snapshots, not backups:

• Export logical or physical backups to an isolated backup account on a defined schedule that meets the workload's recovery point objective.
• Copy at least one recent restore point cross-region.
• Apply object lock so the database backups inherit the same immutability as the rest of the estate.
• Store encryption keys and restore credentials outside the production account, so a compromise of production does not also lock you out of the keys you need to recover.

The workloads people are most confident about — the managed database, the SaaS tenant — are frequently the least independently protected.

Restore testing and the recovery time you actually get

A backup you have never restored is a hope, not a plan. In cloud, the headline risk is not a missing copy but a recovery time that turns out to be several times longer than assumed. Restoring terabytes from cold, cross-region object storage is bandwidth- and API-bound; rehydrating archived tiers adds retrieval latency measured in hours. The number on the storage tier's data sheet is not your recovery time objective.

Make testing routine and honest:

1. Restore full systems, not single files. A single-file restore proves the copy exists; a full-system, application-level recovery in an isolated account proves you can actually run.
2. Time every drill end to end and compare it against the documented recovery time objective. If reality exceeds the objective, the objective is fiction until you close the gap.
3. Test the isolated-account path, assuming production identity and networking are gone. That is the scenario after a real compromise.
4. Rotate responders so recovery does not depend on one reachable person, and run a drill after every significant architecture change.
5. Track findings like incidents and close them on a deadline.

Restore rehearsals are also where you discover that a warm-tier copy meets a two-hour target while the cheaper archive tier does not — which is a lifecycle and cost decision, not a technical afterthought.

Lifecycle tiers keep it affordable

Immutable, cross-region, multi-copy backups can get expensive fast if every copy sits on hot storage forever. Lifecycle policy is how you keep resilience affordable without weakening it:

• Keep recent restore points on warm storage so tier-1 recovery meets aggressive recovery time objectives.
• Transition older copies to colder, cheaper tiers as they age past the window where fast recovery matters, while preserving the object lock.
• Match retention to compliance, not habit. Paying to hold seven years of hot copies when regulation requires archival-grade retention is wasted spend; expiring data a regulation still requires is a violation.
• Tier by workload. Mission-critical systems justify frequent, warm, long-retained immutable copies; dev and test data can take a daily copy to cheap cold storage.

Right-sizing backup tiers is part of running an efficient cloud footprint — you buy the cheapest protection that still meets each workload's recovery and retention targets, and no more.

Build backups the blast radius cannot reach

Cloud-native backup is not a snapshot schedule. It is an isolated, cross-region, immutable copy of your data — including SaaS and managed databases — held outside the account an attacker would compromise, tiered for cost, and proven by restores you have actually run. If your recovery plan today rests on snapshots in the same account as production, or you have never completed a full-system restore into an isolated environment, that is exactly where the risk lives. intSignal designs, operates, and tests cloud backup and recovery for organizations that cannot afford to guess. Talk to our cloud team to build immutable, isolated backups and prove the restores before you need them.