AWS Backup Air-Gapped Vaults: The Primary-Backup Cost Win's Catch

The first time I moved a non-fully-managed workload straight into a logically air-gapped vault, the job went green and I went to lunch. The recovery point never landed. The temporary snapshot AWS Backup creates in the standard vault had been encrypted with an AWS-managed key, and AWS-managed keys cannot be shared across accounts - so the copy into the service-owned vault silently failed while the local snapshot sat there looking like success. The backup plan said protected. The vault said empty. That gap between "job completed" and "copy reached the isolation boundary" is the whole reason this feature deserves more than a press-release read.

AWS announced direct primary backup to logically air-gapped vaults in November 2025, building on the vaults it introduced in August 2024. The pitch is real: you no longer have to stage a copy in a standard vault first, which removes the duplicate-storage cost that kept a lot of teams off air-gapped vaults entirely. But the cost win is conditional, the encryption rules are unforgiving, and the same-Region constraint quietly forces a second architecture for anyone with a disaster-recovery mandate. I have run these workflows in production. Here is where the savings are real, where they evaporate, and the checks I run before I trust a vault to actually hold a recovery point.

For the official mechanics, AWS's own walkthrough is the primary source for this article. What follows is the operator's read on top of it.

What direct primary backup actually changes

A logically air-gapped vault is immutable backup storage that lives in a separate, AWS-owned account, encrypted with service-owned or customer-managed KMS keys. The isolation is the point: backup data is structurally separated from the credentials of the account that holds the workload, so an attacker who owns your production account does not automatically own your backups. Recovery still works through AWS Resource Access Manager sharing and multi-party approval, which means restoration cannot be authorized by a single compromised identity.

Before this change, the 3-2-1 model forced you to write a backup to a standard vault and then copy it into the air-gapped vault - you paid to store the same data twice. Direct primary backup removes the first copy for the resources AWS fully manages. That is the entire cost story, and it is genuine. But it splits cleanly along one line that decides everything downstream.

If your protected estate is mostly S3, DynamoDB, and EFS, the savings are immediate and you can stop reading the fine print. If it is EBS, Aurora, or FSx - and for most teams it is - the "direct" in direct primary backup is marketing for those services. They still create a temporary snapshot, copy it, and clean it up. The exposure window the feature claims to close stays open for exactly the resources most people are trying to protect.

The encryption rule that turns success into silent loss

This is the failure mode I opened with, and it is the one that costs people real recovery points. Non-fully-managed resources have to be copied across an account boundary to reach the vault. That copy is only possible if the resource is encrypted with a customer-managed key (CMK) or is unencrypted. Resources encrypted with AWS-managed keys cannot be shared across accounts - full stop - so the copy step fails.

The trap is that the local snapshot still succeeds. The job completes in your account. Nothing in the default console flow screams that the recovery point never made it to the isolation boundary. You discover it during an incident, which is the worst possible time to learn your air-gapped vault is empty for a class of resources. The fix is unglamorous: identify every non-fully-managed resource on an AWS-managed key, create CMKs, re-encrypt, and confirm the vault's key policy accepts that CMK before you schedule the job. Re-keying large volumes is slow and it delays the moment real protection begins, so audit encryption state before you flip the feature on, not after.

Same-Region by design, and what AWS quietly changed

Direct primary backup requires the vault to sit in the same AWS account and Region as the source. Cross-Region direct writes are not supported for this feature; you fall back to a copy step. AWS frames this as a recovery-speed optimization - keeping resources and backups in one account boundary means faster restores without a copy operation - and that framing is honest as far as it goes.

Here is my position, and it is where I part company with the "just enable it everywhere" advice. For any workload with a real DR requirement, the same-Region rule means this feature is your local ransomware control, not your DR strategy, and you must pair it with a second mechanism. AWS itself recommends cross-Region replication of primary resources or cross-Region recovery-point copies to a locked vault for geographic redundancy.

The wrinkle worth knowing is that AWS has been chipping at the same-Region constraint. In February 2026 it added single-action cross-Region database snapshot copies to air-gapped vaults for Aurora, Neptune, and DocumentDB. So the blanket "same-Region only" rule is already service-dependent. Check the compatibility matrix for your specific resources rather than trusting any general statement, including this one.

One more constraint that bites at scale: there is a non-adjustable limit of 30 cross-Region copy jobs per vault. If you centralize copies from many source accounts into one vault, that ceiling becomes a bottleneck. AWS RAM sharing from a single account sidesteps it better than building separate bunker accounts does.

Where the money actually goes

The storage premium for an air-gapped vault is about 15% over a standard vault - roughly $0.0575 versus $0.050 per GB-month in EU West, per AWS pricing analysis. That is the fixed, predictable cost, and removing the duplicate copy for fully managed resources offsets a chunk of it. The variable cost that surprises people is cross-Region data transfer, which only appears once you add the DR leg the same-Region rule forces. As illustrative figures from AWS's pricing documentation: moving 2,000 GB of EFS data across Regions runs about $80 at $0.04/GB, and 3,200 GB of EBS snapshots about $64 at $0.02/GB - per cycle, scaling with frequency and retention.

That last clause is the operational lever. For non-fully-managed resources, every backup spins up a temporary snapshot, holds it until the copy completes, then deletes it. Run those jobs hourly and you keep multiple temporary snapshots alive at once, paying for overlapping storage and erasing the efficiency the feature was supposed to deliver. AWS's own guidance lands on 24-hour intervals or greater for maximum cost optimization; shorter windows still give you the security and compliance benefits, but the cost advantage shrinks fast as cadence climbs. Sub-daily backups for non-fully-managed resources are a deliberate trade - more recovery granularity for measurably more spend - not a default to leave on.

The pre-flight checklist I run before trusting a vault

I do not consider a vault protective until every line below is true. None of this needs anything but the AWS console and the CLI.

1. Classify each protected resource as fully managed, non-fully managed, or unsupported. Your real exposure window lives in the second group.
2. For every non-fully-managed resource, confirm it is on a CMK (or unencrypted), never an AWS-managed key. This is the single most common reason a copy silently fails.
3. Verify the air-gapped vault's key policy actually accepts that CMK.
4. Always designate a standard vault alongside the air-gapped one - unsupported resources land there, and skipping it leaves them unprotected.
5. After the first job, open the vault and confirm the recovery point is actually sitting there. A "completed" job status is a separate fact, and for non-fully-managed resources the two routinely disagree.
6. Set non-fully-managed frequency to 24 hours or greater unless a compliance mandate forces tighter, and budget cross-Region transfer separately if you add a DR copy.
7. Confirm multi-party approval teams are configured before you need a restore, not during the incident.

Skip step 5 and you will believe you are protected for months. The vault enforces a seven-day minimum retention and refuses deletion while recovery points remain, so the safety rails on the way out are strong - but nothing on the default path forces you to verify the recovery point ever arrived on the way in.