Ransomware-Resilient Backup Architecture: Immutable Storage, Object Lock, Air-Gapped Vaults and Recovery Drills

Most backup systems that fail during a ransomware attack were working perfectly the day before. Jobs ran green, retention was set, and dashboards were full. Then an attacker who already held administrator credentials deleted the recovery points, shortened the retention, or disabled the key that decrypts them, and only then started encrypting production. A ransomware resilient backup design starts from that scenario, not from a disk failure.

This matters now because every major cloud has shipped primitives that make deletion-proof backups practical without tape: S3 Object Lock, AWS Backup Vault Lock and logically air-gapped vaults, Azure immutable vaults with multi-user authorization, and Google Cloud backup vaults with enforced retention. NIST also finalised its CSF 2.0 ransomware profile in June 2026. The tools exist; the failures now come from architecture and identity mistakes.

You will leave with a threat model, a reference architecture across AWS, Azure and Google Cloud, worked retention cost math, and a recovery drill runbook you can run next quarter.

What this covers: the admin-credential threat model, immutability modes and their escape hatches, logically air-gapped vaults, identity separation, the 3-2-1-1-0 rule, malware scanning of restores, illustrative cost math, drills, and failure modes.

Context and Background

Classic backup design answered a hardware question: if a disk, server or site dies, can we get the data back within the recovery time objective (RTO) and with no more loss than the recovery point objective (RPO)? The 3-2-1 rule, three copies on two media types with one off-site, was built for that world. It assumes the failure is accidental and that whoever runs the backups is on your side.

Ransomware breaks that assumption. Modern intrusions are human-operated: the attacker spends days or weeks inside the network, escalates to domain or cloud administrator, maps the backup estate, and destroys it before detonating the encryptor. If the backup console trusts the same identity provider as production, the attacker owns the backups the moment they own an admin account. An off-site copy that the same admin can delete is not off-site in any useful sense.

Regulators and agencies have tracked this shift. The CISA #StopRansomware Guide (September 2023 revision) tells organisations to “maintain offline, encrypted backups of critical data”, to regularly test their availability and integrity in a disaster recovery scenario, and to keep golden images and infrastructure-as-code templates offline. NIST published IR 8374 Rev. 1, Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile, as a final report in June 2026, superseding the 2022 original. It maps ransomware outcomes across all six CSF 2.0 functions, including Govern and Recover.

The industry answer has been to extend 3-2-1 into the 3-2-1-1-0 backup rule, popularised by backup vendors: three copies, two media, one off-site, one immutable or offline, and zero errors on verified restore. The last two digits are the ones that matter against an adversary, and they are the ones teams most often fake.

Cloud platforms have since turned immutability from a tape-vault procedure into an API setting. That shifts the hard part to design: which mode, who can unlock it, which identity can restore, and how you prove it works. Kubernetes teams face the same question one layer up; our Velero 1.18 backup and disaster recovery runbook compared with Kasten and CloudCasa covers the cluster-level tooling. This post is about the storage and identity layer underneath any tool, and it takes the view that backup isolation is an identity problem first and a storage problem second.

The Ransomware Resilient Backup Reference Architecture

A ransomware resilient backup architecture keeps at least one copy that no production identity can delete, shorten or decrypt, stores it under a compliance-mode retention lock, restores it into an isolated environment controlled by a separate identity, and scans and tests every candidate recovery point before cutover. Immutability without identity separation and tested restores is not resilience.

Figure 1: Reference architecture for a ransomware resilient backup estate, with three copy tiers, separate key management and a recovery path owned by a different identity.

The diagram has three tiers of copies and two separate planes of identity. The local backup vault serves everyday restores with a short RTO. A cross-Region copy covers regional outages. The logically air-gapped vault holds the copy you rely on when the attacker controls your production administrators. Recovery runs through an isolated recovery environment (IRE) that is owned and approved by an identity outside the blast radius, with key management in a separate account so a production admin cannot revoke decryption.

Start from the threat model, not the storage tier

Write down what the attacker can do before choosing products. The realistic model for 2026 is an adversary with full administrator rights in your production cloud account or tenant, domain admin on-premises, access to CI/CD secrets, and possibly the ability to call your cloud provider’s support line with a convincing story. They have days of dwell time and they read your runbooks.

Against that adversary, five capabilities must be denied. They must not be able to delete recovery points. They must not be able to shorten retention so that recovery points expire quickly. They must not be able to destroy or disable the encryption keys. They must not be able to block or corrupt the restore path. And they must not be able to poison backups silently for longer than your retention window, so that every copy you hold already contains their foothold.

The last point is the subtle one. Immutability protects the bytes you wrote; it does nothing about bytes that were already malicious when written. If dwell time exceeds retention, every immutable copy is immutable malware. Retention sizing is therefore a security parameter, not only a cost parameter, and it should be set against measured dwell times in your incident history rather than a round number.

Immutability is a mode, and every mode has an escape hatch

Each cloud implements write-once-read-many (WORM) storage with a permissive mode and a strict mode. On Amazon S3, Object Lock has governance mode, where users with the s3:BypassGovernanceRetention permission can override retention by sending the bypass header, and compliance mode, where no user, including the root user, can overwrite or delete a protected object version until its retention date. AWS documents that the only way to delete compliance-locked objects early is to delete the AWS account. Object Lock requires S3 Versioning, and a lock protects a specific object version, not a key name.

AWS Backup Vault Lock follows the same pattern for recovery points. Governance mode can be removed by users with sufficient IAM permissions. Compliance mode is created by supplying ChangeableForDays, which sets a grace period with a minimum of three days (72 hours) and a maximum of 36,500 days. During grace time you can change or delete the lock; after the lock date, AWS states that neither the customer nor AWS can remove it. Optional MinRetentionDays and MaxRetentionDays make backup jobs with out-of-range lifecycles fail.

Azure Blob immutable storage offers time-based retention policies in unlocked and locked states, plus legal holds. A locked container-level policy cannot be deleted or shortened, and Microsoft documents a limit of five extensions over its lifetime, with retention between 1 and 146,000 days. Azure Backup adds immutable vaults, where the locked setting cannot be reversed, and soft delete with a default of 14 days that can be extended to 180 days. On Google Cloud, Cloud Storage Bucket Lock makes a retention policy permanent and irreversible, up to 100 years, and Backup and DR backup vaults enforce a minimum retention between 1 day and 99 years that can be permanently locked from an effective date.

The pattern matters more than the product names. Every permissive mode has an identity that can bypass it, so governance mode is only as strong as the controls on that identity. Every strict mode has a configuration window before it hardens, so an attacker who arrives during that window, or who controls the policy that creates new vaults, can still win.

Logical air gaps replace tape, with caveats

A physical air gap means no network path at all. Cloud providers now sell logical air gaps instead: backups stored in provider-managed accounts or tenants that the customer cannot administer directly. AWS describes a logically air-gapped vault as a specialised vault that is always equipped with Vault Lock in compliance mode, encrypted by default with an AWS-owned key or optionally a customer managed KMS key, and shareable to other accounts through AWS Resource Access Manager (RAM) or multi-party approval (MPA) so a different account can restore.

The MPA integration is the important part. AWS documents that, with MPA, you can still restore or copy from a logically air-gapped vault even if the vault-owning account is closed, maliciously or otherwise, until the account’s post-closure period ends. Approvers are defined as an approval team rather than as roles inside the compromised account. That is identity separation built into the product.

Azure’s security overview is explicit that its vaulted backup data lives in a Microsoft-managed subscription and tenant separate from production, and equally explicit that this is not a physical or offline air gap. Treat every logical air gap the same way: a strong control against an attacker inside your tenant, not a defence against a provider-level failure or against data that was already compromised.

Identity separation is the real air gap

Storage immutability stops deletion of data. It does not stop an attacker from deleting the vault’s access policy, revoking the KMS key grant, disabling the backup plan so no new copies are made, or closing the account. Each of those is an identity action. The architecture therefore needs a second identity plane that production administrators cannot reach.

In practice that means a separate AWS Organization, Entra ID tenant or Google Cloud organisation for recovery, with its own break-glass accounts, its own hardware-backed multi-factor authentication, and no federation trust from the production identity provider. AWS’s own cyber recovery reference, published on the AWS Architecture Blog in May 2026, recommends exactly this second-organisation model for cyber events, with MPA approvers defined in the separate organisation through IAM Identity Center.

Inside production, use preventive guardrails as well. Service control policies (SCPs) can deny backup:DeleteBackupVault, backup:DeleteRecoveryPoint, backup:PutBackupVaultAccessPolicy and kms:ScheduleKeyDeletion to everyone except a narrowly scoped role. Our guide to AWS IAM policy evaluation, SCPs and permission boundaries explains why an explicit SCP deny wins over any identity policy, which is what makes it useful here. Remember that SCPs do not apply to the management account, which is one more reason not to run workloads or backups there.

Walking Through the Attack: What a Ransomware Resilient Backup Actually Stops

A ransomware resilient backup earns its keep only if each control blocks a specific attacker action. The sequence below replays a typical destructive phase against an estate built to the reference design.

Figure 2: An attacker holding production admin credentials attempts to destroy backups; compliance locks, versioned Object Lock and a separate recovery identity deny each step.

The attacker first tries to delete recovery points in the AWS Backup vault. In a compliance-locked vault this fails: the Vault Lock documentation states that AWS Backup denies deletion or lifecycle changes by any user, including the root user. Next they try to shorten the retention policy. After the grace period has passed, the lock can no longer be changed or removed, so that also fails.

They then turn to S3 data protected with Object Lock. A versioned DELETE that names a locked version returns 403 Forbidden. A simple DELETE without a version ID returns 200 OK, which looks like success, but it only adds a delete marker; the protected version remains. Applications and dashboards that read only current versions will report the data as gone, which is a real operational trap during an incident even though nothing was lost.

Finally the attacker goes after the recovery path itself: removing RAM shares, deleting cross-account roles, or closing the account. Because restore access is granted by an approval team in a separate organisation, there is no trust path from production to cut. The approvers grant restore access to a clean account, and recovery proceeds.

The gaps this sequence does not close

Three attacks survive the design and need their own controls. The first is pre-positioning: changing backup plans weeks in advance so that new recovery points go to an unlocked vault, or so critical resources quietly drop out of the backup selection. Detect it with configuration monitoring and backup audit reports that alert on any plan, selection or vault policy change, and treat a coverage drop as a security event.

The second is key sabotage. If the vault uses a customer managed KMS key in the production account, an attacker can disable it or schedule its deletion, leaving locked but unreadable recovery points. Keep backup keys in a separate account, deny kms:DisableKey and kms:ScheduleKeyDeletion by SCP, and consider the provider-owned key option for logically air-gapped vaults, which AWS recommends by default. Our post on envelope encryption, KMS and HSM key management with key rotation covers why the key hierarchy, not just the data, needs a blast-radius design.

The third is poisoning. If the attacker’s implant is inside the workload image or the database itself, every recovery point after initial access contains it. Only scanning, integrity checks and a sufficiently long retention window solve this, which is why the recovery drill below starts by establishing an event boundary.

Mapping the 3-2-1-1-0 Backup Rule to Cloud Primitives

The 3-2-1-1-0 backup rule is easy to recite and easy to satisfy on paper. The table maps each digit to concrete primitives and to the mistake that most often makes it fictional.

Digit	Requirement	AWS	Azure	Google Cloud	Common way it is faked
3	Three copies	Source plus vault plus copy	Source plus vault plus geo-redundant vault	Source plus backup vault plus second region	Counting replicas that mirror deletions
2	Two media or storage systems	Backup vault and S3 Object Lock	Backup vault and immutable blob	Backup vault and locked bucket	Two buckets in the same account
1	One off-site	Cross-Region copy	Cross-region restore or GRS	Cross-region vault	Same Region, different name
1	One immutable or air-gapped	Logically air-gapped vault, compliance lock	Locked immutable vault plus MUA	Backup vault with locked enforced retention	Governance mode with a widely held bypass
0	Zero errors on verified restore	Restore testing plus GuardDuty backup scans	Restore drills plus threat detection	Restore drills plus scan in IRE	Checking job status, not restoring

Replication deserves a special warning. Cross-Region replication, database read replicas and synchronous mirrors are availability tools. They faithfully replicate encrypted files and dropped tables within seconds, so they count toward neither the immutable digit nor the off-site digit for ransomware purposes unless the destination is independently versioned and locked.

The zero is the most neglected digit. A backup job status of “completed” says the bytes were copied. It says nothing about whether the application starts, whether the database is consistent, or whether the restore fits inside your RTO. AWS Backup has a restore testing feature that restores recovery points on a schedule and records the result. Azure and Google Cloud users typically script the equivalent. Either way, measure success as a working application, not a finished job.

Guardrail code: deny backup destruction by policy

The following SCP is a minimal example of denying destructive backup and key actions across an AWS organisation unit, with an exception for a single break-glass role. Treat it as a starting template; test it in a sandbox OU because a wrong deny on kms:* actions can break unrelated workloads.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBackupDestruction",
      "Effect": "Deny",
      "Action": [
        "backup:DeleteBackupVault",
        "backup:DeleteRecoveryPoint",
        "backup:UpdateRecoveryPointLifecycle",
        "backup:PutBackupVaultAccessPolicy",
        "backup:DeleteBackupVaultAccessPolicy",
        "backup:DeleteBackupVaultLockConfiguration",
        "backup:DeleteBackupPlan",
        "kms:ScheduleKeyDeletion",
        "kms:DisableKey",
        "s3:BypassGovernanceRetention",
        "s3:PutBucketObjectLockConfiguration"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/BackupBreakGlass"
        }
      }
    }
  ]
}

Two cautions apply. First, the Vault Lock documentation notes that the lock governs only actions taken through AWS Backup; direct EC2 calls such as ModifySnapshotAttribute and ModifySnapshotTier are not covered and must be restricted with IAM or SCPs, exempting the backup plan roles. Second, a break-glass role is itself a target. Require hardware MFA, alert on every assumption, and store its credentials offline with dual control.

The compliance-mode lock on a vault is a one-way door, so script it and review it like a schema migration:

# Compliance-mode lock: 3-day grace period, 35-day minimum, 400-day maximum retention.
# After the grace period ends, nobody (including AWS) can remove this lock.
aws backup put-backup-vault-lock-configuration \
  --backup-vault-name prod-critical-vault \
  --changeable-for-days 3 \
  --min-retention-days 35 \
  --max-retention-days 400

# Verify the lock date before the grace window closes
aws backup describe-backup-vault --backup-vault-name prod-critical-vault \
  --query '{Locked:Locked,LockDate:LockDate,Min:MinRetentionDays,Max:MaxRetentionDays}'

Use the grace period as a real test window. Run a backup job, confirm that a lifecycle shorter than the minimum fails, and confirm restore works before the lock date passes. A mistake found on day four is permanent.

Scanning Restores in a Ransomware Resilient Backup Pipeline

Immutability guarantees you get back exactly what you stored. If what you stored contains the attacker’s web shell, scheduled task or poisoned container image, a perfect restore re-infects you. Restore validation therefore needs a malware and integrity gate, run before any recovery point is promoted.

AWS now offers this natively. GuardDuty Malware Protection for AWS Backup scans Amazon EBS snapshots, EC2 AMIs and Amazon S3 recovery points, including S3 continuous backups, and AWS documents support for locked vaults holding EBS and EC2 recovery points in supported Regions. Scans are incremental, covering new or changed blocks or objects as backups are created, and you can run on-demand scans of any supported recovery point, explicitly including verifying a backup before restore. GuardDuty scans a read-only copy and does not modify the backup.

Azure’s security overview describes a threat detection capability, in preview at the time of writing, that uses Microsoft Defender for Servers signals to flag potentially infected Azure VM recovery points; Microsoft states that it does not scan backup data directly. On Google Cloud, and for anything the native scanners do not cover, the practical pattern is to restore into the isolated recovery environment and scan there with your endpoint detection and response (EDR) agent and file-integrity tools before any network path to production exists.

Signature scanning alone is weak against a targeted intrusion, because the implant may be custom. Add integrity checks that do not depend on signatures. Compare binaries and configuration against golden images or infrastructure-as-code definitions, diff database user and role tables against a known-good baseline, look for scheduled tasks, cron entries and new service accounts created after the event boundary, and check that application checksums match release artefacts. A recovery point passes only when all checks pass.

Retention, RPO and Cost: Worked Illustrative Numbers

Retention for a ransomware resilient backup has two lower bounds. The operational bound comes from your RPO and recovery needs. The security bound comes from dwell time: you need clean recovery points older than the earliest compromise, plus margin for the investigation to find it. Public incident-response reports have shown median dwell times falling over recent years, but the long tail matters more than the median, and your own incident data is the right input.

All figures below are illustrative, using a round storage price of $0.05 per GB-month for backup-tier storage. Real prices vary by service, Region, storage tier, and whether the provider bills logically air-gapped storage differently; check the AWS Backup, Azure Backup and Google Cloud Backup and DR pricing pages for your workload before budgeting.

Assume 20 TB of protected data with a 2 percent daily change rate, which is 400 GB of new incremental data per day. Consider three policies.

Policy	Daily retention	Weekly retention	Approx. stored data	Illustrative monthly cost
A, short	14 days	none	20 TB full plus 14 times 0.4 TB, about 25.6 TB	about $1,280
B, balanced	35 days	13 weeks	20 TB plus 35 times 0.4 TB plus 13 weekly deltas at 1.5 TB, about 53.5 TB	about $2,675
C, long	35 days	52 weeks	20 TB plus 14 TB plus 52 times 1.5 TB, about 112 TB	about $5,600

The weekly delta of 1.5 TB is itself an assumption: it is less than seven times 400 GB because many daily changes overwrite the same blocks. Measure your real compaction ratio from vault metrics. If your backup service stores full copies rather than block-level incrementals for some resource types, the numbers grow sharply, so check how each service bills.

Now add the immutable tier. If the logically air-gapped vault holds a copy of policy B, the storage roughly doubles, to about $5,350 per month at the illustrative price. AWS documents a cheaper option for some workloads: primary backups written directly to a logically air-gapped vault after onboarding to MPA, keeping a single copy. That saves storage but removes the fast local copy and concentrates risk in one place, so pair it with cross-Region copies for critical systems.

The second cost of immutability is that you cannot fix mistakes. A backup plan that accidentally sets a 10-year lifecycle into a compliance-locked vault creates storage you are obliged to pay for until it expires. AWS warns that recovery points with an “Always” retention are retained forever once grace time expires. Use MaxRetentionDays on every locked vault as a financial safety rail; a job with an out-of-range lifecycle fails instead of creating a decade-long liability.

RPO interacts with cost through frequency. Moving from daily to hourly snapshots for a database with a 2 percent daily change rate does not multiply storage by 24, because the same blocks change repeatedly, but it does multiply recovery point count, API calls and scan workload. A common compromise is hourly local snapshots with short retention, daily copies to the immutable tier, and weekly copies with long retention. Ransomware recovery rarely needs hourly granularity from three months ago; it needs a clean point shortly before the event boundary.

The Recovery Drill Runbook

A ransomware resilient backup you have never restored is a hypothesis. A recovery you have never rehearsed will take far longer than your RTO says. The runbook below follows the order recommended in AWS’s 2026 cyber recovery reference and the CISA guide’s emphasis on testing backups in a disaster recovery scenario, generalised to any cloud.

Figure 3: Recovery drill runbook: set an event boundary, walk back through recovery points until one passes scanning, approve with a separate identity, rebuild in isolation, validate and cut over.

Step 1: declare and isolate. Declare the drill or incident in your incident process with a named incident commander. During a real event, isolate affected accounts and preserve logs before anything else. Our guide to incident management severity levels, on-call and blameless postmortems covers the command structure; the recovery team should be a distinct workstream from the forensic team.

Step 2: set the event boundary. Use CloudTrail, Entra ID sign-in logs, Cloud Audit Logs and EDR telemetry to find the earliest indicator of compromise. This timestamp is the event boundary. In a drill, have a red team or the drill lead pick a boundary and plant a benign marker file after it to test whether the process catches it.

Step 3: select candidates. Choose the newest recovery point before the boundary for each system. Order systems by dependency: identity, networking and secrets first, then data stores, then applications. Restoring an application before its identity provider is the most common way to burn hours.

Step 4: scan and verify. Run malware scans and the integrity checks described earlier. If a candidate fails, step back to the previous recovery point and repeat. Record how many steps back each system needed; it is the best evidence you have for retention sizing.

Step 5: approve with a separate identity. Approval for restore access comes from the recovery identity plane, for example an MPA approval team or an Azure Resource Guard owner in a separate tenant, not from production administrators. Time this step in drills; approval latency at 3 a.m. on a holiday is a real RTO component.

Step 6: rebuild and restore. Rebuild infrastructure from version-controlled code into the isolated recovery environment, which has no peering, trust or internet path to production. Restore validated data into it and rotate every credential, key and token that existed before the boundary. Restored systems must never rejoin the old identity domain.

Step 7: validate and cut over. Run application-level smoke tests and business checks, such as reconciling the last known order IDs. Cut over by DNS once validated, and keep the old environment isolated for forensics. In a drill, stop before cutover but measure everything up to it.

Step 8: record and improve. Capture actual RTO and RPO achieved per system, the number of failed candidates, approval latency, and every manual step that was not in the runbook. Feed the gaps into the backlog. A drill that finds nothing usually means the scope was too small.

Run a tabletop quarterly and a technical restore drill at least twice a year for crown-jewel systems, rotating which systems are included. Automated restore testing should cover the long tail continuously; humans should rehearse the parts automation cannot, especially approvals and identity rebuild. Kubernetes estates need cluster-level rehearsal as well; the Velero runbook includes namespace and persistent volume restore steps you can slot into Step 6.

Trade-offs, Gotchas, and What Goes Wrong

Choosing an immutability mode is a trade between recoverability from your own mistakes and resistance to an attacker. The decision flow below captures the questions that should drive it.

Figure 4: Choosing between governance mode, compliance mode and a logically air-gapped vault based on threat model, regulation and the need for an emergency delete path.

Governance mode becomes the default and stays there. Teams pick governance mode “for now” to keep an escape hatch, then never move on. If the bypass permission is reachable by any role an attacker can assume, governance mode protects only against accidents. Either hold the bypass in a separate identity plane or move to compliance mode.

Compliance mode locks in mistakes and costs. Wrong retention, wrong vault, or an “Always” lifecycle cannot be undone after the grace period. Account closure is the only exit for S3 compliance mode, and AWS notes that after the 90-day post-closure period vault contents are deleted even if locked. That is not a recovery tool; it is a reminder that compliance mode is permanent by design.

Delete markers look like data loss. Simple deletes against Object Lock buckets succeed and add delete markers. Monitoring, applications and humans under stress may conclude data is gone. Teach responders to list object versions, and script restoration of the previous version.

Restores are slower than you think. Restoring tens of terabytes from a vault into a new account can take hours to days depending on resource type, and some services hydrate lazily, so first reads are slow. Measure restore throughput in drills and plan the IRE capacity accordingly.

Dependencies are not in the backup. Teams back up databases and volumes but not DNS zones, IAM configuration, secrets, certificates, CI/CD pipelines or the infrastructure code itself. CISA explicitly recommends keeping infrastructure-as-code templates backed up offline. Without them, Step 6 of the runbook stalls.

SaaS and identity provider data is often missing. Entra ID, Okta, Google Workspace, Microsoft 365 and source control hosts each hold state you need to rebuild. Native retention in those services is rarely immutable against a tenant administrator. Back them up with a tool that writes to your locked storage.

Unsupported resources silently fall back. AWS documents that unencrypted Aurora, DocumentDB and Neptune clusters are not supported in logically air-gapped vaults, and that resources not fully managed by AWS Backup need a customer managed key for the copy. Audit coverage per resource type rather than assuming the vault holds everything.

Lien and project-deletion surprises. On Google Cloud, locking a bucket retention policy places a lien on the project, and the backup vault documentation states that from 1 November 2026 Backup and DR automatically applies a project lien to projects containing vaults with enforced-retention backups. That is protection, but it also blocks project clean-up automation, so update your decommissioning runbooks.

Practical Recommendations

Treat a ransomware resilient backup estate as a security system with its own threat model, owner and test plan, not as an infrastructure chore. The highest-value moves are identity separation and real restores, not another storage tier.

Start by inventorying what you actually need to rebuild the business, including identity, secrets, DNS and infrastructure code, and map each item to a copy tier. Then create a recovery identity plane: a separate organisation or tenant with its own MFA-protected break-glass accounts and no federation from production. Put your immutable tier under compliance-mode locks or a logically air-gapped vault, with restore approval held in that separate plane.

Size retention against dwell time, set maximum retention to cap cost, and use the grace period to test before locks harden. Keep backup keys outside production and deny their deletion by policy. Finally, put the recovery drill on the calendar, measure it, and fix what it finds. Landing-zone guardrails make most of this repeatable; our cloud landing zone architecture guide shows where these controls sit across AWS, Azure and Google Cloud.

A short checklist:

[ ] Threat model written for an attacker with production admin rights.
[ ] At least one copy in a compliance-locked or logically air-gapped vault.
[ ] Restore approval held by a separate organisation or tenant.
[ ] SCPs or policies deny backup, vault-policy and key destruction.
[ ] Backup keys live outside the production account.
[ ] Retention covers measured dwell time plus investigation margin; maximum retention is capped.
[ ] Malware and integrity scans gate every restore.
[ ] Identity, secrets, DNS, IaC and SaaS data are in scope.
[ ] Quarterly tabletop and twice-yearly technical drills with recorded RTO and RPO.

Frequently Asked Questions

What is a ransomware resilient backup?

A ransomware resilient backup is a backup design that assumes the attacker already has administrator credentials. It keeps at least one copy that production identities cannot delete, shorten or decrypt, typically using compliance-mode immutable storage or a logically air-gapped vault. Restore access is controlled by a separate identity, recovery points are scanned before use, and restores are tested regularly. The goal is a provably clean recovery within a known RTO, not just the existence of backup files.

What is the difference between S3 Object Lock governance mode and compliance mode?

In governance mode, most users cannot delete or overwrite locked object versions, but users with the s3:BypassGovernanceRetention permission can override retention by sending a bypass header, and the console sends it by default. In compliance mode, no user, including the AWS account root user, can delete or overwrite a protected version until its retention date, and the retention period cannot be shortened. Governance mode suits testing or cases needing an emergency path; compliance mode suits ransomware and regulatory protection.

What is the 3-2-1-1-0 backup rule?

The 3-2-1-1-0 backup rule extends the classic 3-2-1 rule. Keep three copies of data, on two different storage systems or media, with one copy off-site, one copy immutable or offline, and zero errors when restores are verified. The extra digits address ransomware: immutability stops deletion by a compromised administrator, and verified restores prove that the copies actually work. Replicas that mirror deletions in near real time should not be counted toward the immutable or off-site copies.

Is a logically air-gapped vault as safe as an offline tape backup?

Not identical, but for most cloud workloads it is the more practical control. A logically air-gapped vault sits in provider-managed infrastructure that your administrators cannot directly manage, with compliance-mode locks and restore access through sharing or multi-party approval. It still has a network path and depends on the provider. Offline tape survives a provider-level failure but is slow to restore and hard to test. Many regulated organisations keep both for their most critical data.

How long should immutable backups be retained?

Retention should cover your longest realistic attacker dwell time plus investigation margin, because you need clean recovery points from before the initial compromise. Many teams keep 30 to 35 days of daily points and several months of weekly points in the immutable tier, but your own incident data should drive the number. Balance it against cost, since locked recovery points cannot be deleted early, and set a maximum retention on locked vaults to stop accidental multi-year lifecycles.

How often should ransomware recovery drills be run?

Run automated restore tests continuously or at least weekly across a rotating sample of systems, a tabletop exercise quarterly, and a full technical recovery drill into an isolated environment at least twice a year for crown-jewel systems. Each drill should measure actual RTO and RPO, approval latency and how many recovery points failed scanning. CISA’s guidance is to regularly test the availability and integrity of backups in a disaster recovery scenario, and a drill that is never measured does not meet that bar.

References

AWS, Locking objects with Object Lock, Amazon S3 User Guide.
AWS, AWS Backup Vault Lock, AWS Backup Developer Guide.
AWS, Logically air-gapped vault and Primary backups to logically air-gapped vaults, AWS Backup Developer Guide.
AWS, GuardDuty Malware Protection for AWS Backup, Amazon GuardDuty User Guide.
AWS Architecture Blog, Cyber resilience on AWS: a reference approach for recovery from ransomware and destructive events, May 2026.
Microsoft, Overview of security features in Azure Backup.
Microsoft, Overview of immutable storage for blob data.
Google Cloud, Backup vault overview, Backup and DR Service.
Google Cloud, Bucket Lock, Cloud Storage.
NIST, IR 8374 Rev. 1, Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile, June 2026.
CISA, #StopRansomware Guide, September 2023.

By Riju — about

Ransomware-Resilient Backup Architecture: Immutable Storage, Object Lock, Logically Air-Gapped Vaults and Recovery Drills (2026)