Air Gap Backup: How It Works and How to Do It in the Cloud

Ransomware crews go after your backups first. In 2025, 89% of victims had their backup repositories targeted, and 34% of those backups were modified or deleted (Veeam). A backup that sits on the same network as production, reachable with the same credentials, goes down with everything else. An air gap is how you keep one copy out of reach.

What is an air gap backup?

An air gap backup is a copy of your data kept isolated from your production network, so an attacker who compromises your environment can’t reach it. The name comes from a literal gap of air: a backup on tape or a drive that’s physically disconnected. Nothing on the network can touch what isn’t connected to the network.

In the cloud, you recreate that isolation without the physical media. You put a copy somewhere your everyday credentials and systems can’t reach, so ransomware, a rogue admin, or a bad script can’t delete or encrypt it. How real the gap is comes down to how complete the separation is, and that’s where the common approaches split.

Physical vs logical air gap

The classic air gap is physical. You back up to tape or a removable drive, then disconnect it and store it offline. Ransomware can’t encrypt a tape sitting in a drawer. The tradeoff is speed: recovering from tape is slow, and someone has to manage the media.

In the cloud you’ll hear the term logical air gap for a copy kept in a separate account or subscription, with blocked network access and a policy that no one in production can delete it. AWS calls its version a logically air-gapped vault. It’s a real improvement over a backup sitting next to production, and it stops a lot of attacks.

N2W takes a firmer line on this. A copy in a separate account still lives inside the same cloud, reached through the same provider and the same control plane. Whatever compromises that control plane, or the provider account above it, can reach across the accounts under it. So we don’t count same-cloud separation as a true air gap.

A true air gap needs a boundary the attacker can’t cross with the credentials and control plane they’ve already taken. In the cloud, that means a copy in a different cloud, which the cross-cloud section below covers.

Air gap vs immutable backup

This is the comparison people search for, and the two terms get mixed up. They solve different problems, and strong ransomware defense uses both.

An immutable backup can’t be changed or deleted for a set retention period. The lock is enforced at the storage layer with write-once, read-many (WORM). Even an admin can’t remove it early.

An air-gapped backup can’t be reached in the first place. The copy is isolated, so an attacker never gets the chance to try.

	Traditional backup	Immutable backup	Air-gapped backup
Protects against	Hardware failure, accidental deletion	Modification or deletion of the copy	A network-based attack reaching the copy
Ransomware resistance	Low	High (can’t be altered)	High (can’t be reached)
Recovery speed	Fast	Fast	Fast if logical; slow if physical tape
Cost	Lowest	Low (storage plus retention)	Low if logical; higher if you manage tape or media
Cloud fit	Native	Native (S3 Object Lock, EBS Snapshot Lock, Blob immutability)	Strongest cross-cloud (a copy in a different provider); same-cloud isolation is a partial gap

For the full breakdown of how immutability works, see our pillar on immutable backups. The short version: immutability locks the copy, an air gap hides the copy, and together they close both routes an attacker uses to destroy your recovery point.

How to implement air-gapped backup on AWS

AWS gives you the pieces to build strong isolation inside one account boundary, what most vendors call a logical air gap. Treat this as the in-AWS layer; the cross-cloud step later is what turns it into a true air gap.

Isolate the backup account. Copy your backups into a separate AWS account that your production credentials can’t administer. This is the gap. A compromise of production can’t reach an account it doesn’t control. Put the backup account in its own organizational unit in AWS Organizations, and use a service control policy to block the production team from assuming roles in it. The account that holds the copy should have no trust relationship with the environment an attacker is likely to land in.

Copy across Regions. Send a copy to a second Region too, so a Region-wide event or a targeted attack still leaves a clean recovery point somewhere else. Cross-Region plus cross-account means an attacker has to break two boundaries, not one.

Lock the copy immutable. Isolation and immutability work together. Turn on S3 Object Lock for backups in S3 and EBS Snapshot Lock for snapshots, both in compliance mode, so even if someone reaches the copy, they can’t delete it before retention ends. Add MFA delete on the backup bucket for another gate on removal.

Tighten access to the gap. The isolation only holds if the door stays shut. Give the backup account its own IAM roles with least-privilege permissions, require MFA, and grant write access only to the automated backup process. No standing human credential should be able to delete a backup. Keep the connection between production and the backup account open just long enough to write, then closed.

The principle under all of it: the backup lives where your production credentials don’t reach, and it can’t be deleted while its lock holds. It’s strong isolation, and it’s still inside AWS, so pair it with a cross-cloud copy for a true gap.

Air-gapped backup on Azure

The same pattern maps to Azure, with Azure’s own controls.

Separate the subscription. Store backups in a subscription that sits under a different management group from production, with its own access boundary. A compromise of your production subscription can’t reach one it has no rights over. Azure RBAC defines who can touch the backup, scoped to the automated process rather than standing admin accounts.

Make the copy immutable. Use immutable storage for Azure Blob with a time-based retention policy in a locked state, so the copy can’t be deleted or overwritten until retention ends. For Azure Backup, turn on immutable vaults and soft delete, so a deleted recovery point can still be brought back within the retention window. A resource lock adds one more block against accidental or malicious removal.

Copy across regions. Cross-subscription and cross-region copies give you the same isolation on Azure that a separate account and Region give you on AWS. Break the copy across two boundaries, and an attacker has to defeat both.

Keep the write path open only while a backup runs, and closed the rest of the time.

Cross-cloud: a true air gap

Everything above isolates a copy inside one cloud. That stops most attacks, and most vendors stop there. N2W’s stance is that a copy sharing the same provider and control plane isn’t fully air-gapped, because whatever takes over that control plane can reach across the accounts under it.

A true air gap puts the copy in a different cloud. Back up your AWS workloads into an Azure account you own, or the reverse, and the copy sits behind a separate provider, separate credentials, and a separate control plane. An attacker who owns your AWS environment has no path into a copy living in Azure. That’s the cloud version of pulling the tape and locking it in another building.

This is what N2W means by air-gapping. It copies backups cross-cloud into storage you own, keeps them immutable through each platform’s native locks, and recovers them fast, including restoring AWS volume backups directly into Azure. The gap stays inside accounts you control, with nothing held on an outside platform.

One caveat for regulated data: if you have data residency or sovereignty rules, check where the air-gapped copy actually lands. Some vendors’ managed vaults don’t let you choose the region, which can break a data-residency requirement. Because N2W keeps the copy in your own account, you pick the cloud and the region, so the gap never costs you residency control.

Air gap plus immutability: defense in depth against ransomware

Ransomware has shifted from encrypting data to hunting the backups that would let you recover without paying. 48% of breaches now involve ransomware (Verizon 2026 DBIR), and the crews that reach your backups make recovery far more expensive.

Strong ransomware defense stacks a few controls:

• Immutability, so the copy can’t be altered or deleted.
• An air gap, so the copy can’t be reached.
• Frequent recovery points, so your clean copy is recent.
• Tested recovery, so you know it restores under real conditions.

One caveat worth planning for: an isolated copy only helps if you can bring it back fast. The same gap that protects the copy adds a step to recovery, so rehearse the restore from the air-gapped account or subscription on a schedule, not once a year. Teams that test recovery under real conditions find the bottlenecks before an incident does.

For how to put these together, see our checklist on ransomware backup strategies, the AWS how-to on ransomware-proof AWS backups, and the ransomware protection hub.

How N2W does it

N2W is infrastructure software that runs inside your own AWS or Azure account. It never holds your data in a vendor vault, so the gap stays entirely inside your own environment, with nothing on an outside platform for an attacker to reach.

It automates the isolation: scheduled backups copied cross-account, cross-Region, or cross-cloud into storage you own, then locked immutable through the native AWS and Azure APIs (EBS Snapshot Lock, S3 Object Lock, and immutability for Wasabi and Azure Blob). There’s no agent to install and no external dependency in the path.

Two things decide how well you survive a ransomware hit: how recent your clean copy is, and how fast you can bring it back. N2W takes point-in-time backups as often as every 60 seconds and recovers them near-instantly, so your worst-case data loss is measured in seconds and your isolated copy is never far behind production. See how N2W fits a full ransomware recovery plan.

FAQ