Skip to content

SYSTEM Cited by 1 source

AWS Backup logically air-gapped vault

Definition

The AWS Backup logically air-gapped vault is a vault type within AWS Backup that provides service-enforced deletion protection for backup recovery points. It is the primary AWS-native option for protecting backup storage from deletion in cyber-resilience designs.

Verbatim from the canonicalising source:

"The AWS Backup logically air-gapped vault is the primary AWS- native option for protecting backup storage from deletion." (Source: sources/2026-05-20-aws-cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events)

Load-bearing properties

1. Always in Compliance mode

"A logically air-gapped vault is always locked in Compliance mode. The service itself enforces retention, so recovery points can't be deleted by any principal, including the account root user or a compromised administrator, within the retention period."

Compliance mode = service-enforced retention that cannot be modified or shortened by any principal — including the account root user, a compromised administrator, or even AWS Support.

This is what makes the vault load-bearing for ransomware recovery: even if an attacker obtains root credentials in the Recovery Account, they cannot destroy the backups.

See concepts/service-enforced-deletion-protection for the underlying property.

2. Recovery points live in AWS service-owned accounts

"A logically air-gapped vault stores recovery points in AWS service-owned accounts. […] The vault object in your Recovery Account is the governance and access boundary where sharing, restore authorization, and Multi-party approval are configured. This separation is what makes the air-gap logical rather than network-based."

The data physically lives in AWS-owned infrastructure that the customer cannot reach to delete. The customer's vault object in their Recovery Account is just the governance handle — not the storage itself.

3. Encryption choice

"You can choose to encrypt these recovery points with either a service-owned key or an AWS Key Management Service (AWS KMS) customer managed key."

Two encryption options:

  • Service-owned key — AWS-managed; simpler operational model.
  • Customer-managed KMS key — customer controls the encryption key; required for some regulatory contexts; adds key rotation as a recovery dependency.

4. Sharing via AWS RAM

"You share recovery points across accounts through AWS RAM. You can initiate restores from the owning account or from any account with which you share the vault. This is how the Recovery Account makes recovery points available to the IRE."

AWS RAM is the cross- account sharing primitive. The Recovery Account owns the vault and shares it with the IRE for restore operations.

5. Multi-party approval (MPA) for restore

"Configure Multi-party approval for restore. MPA, configured through IAM Identity Center, requires a predefined set of approvers before a restore proceeds. This is particularly valuable when the source account might no longer be trusted."

See systems/aws-multi-party-approval for the service primitive and patterns/mpa-gated-restore-authorization for the pattern.

6. Direct backup target for fully managed resources

"AWS Backup supports the logically air-gapped vault as a primary backup target for fully managed resources (Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB, Amazon Elastic File System (Amazon EFS)), so backups can be written directly to the vault without staging in a standard vault first."

Fully managed resources can write directly to the vault — no intermediate staging. Direct support today (per the source):

7. Intelligent orchestration for non-fully-managed

"Non-fully-managed resources (Amazon EBS, Amazon Aurora, Amazon FSx) use an intelligent orchestration path where the service creates and transfers a temporary snapshot."

These resources require an extra step:

The service handles the orchestration; from the customer's POV the backup target is still the vault.

Out-of-vault fallback for unsupported services

"For S3 data outside the vault's supported resource set, Amazon S3 Object Lock in Compliance mode paired with S3 Versioning provides equivalent deletion protection at the S3 layer."

S3 Object Lock in Compliance mode + S3 Versioning = equivalent guarantee for S3 data the vault doesn't support.

For other services not yet supported by the vault:

"Cross-Region Replication to a locked bucket or service-native point-in-time recovery can serve as interim options. These are recovery-oriented copies rather than tamper-proof storage and should be treated accordingly when designing around them."

The honest framing: PITR / CRR-to-locked-bucket is recovery- oriented but not service-enforced tamper-proof storage. Weaker guarantee than the vault.

Role in cyber-resilience architectures

The vault is the storage primitive of the three-account cyber- recovery topology:

Account Owns vault? Restores from vault?
Production No No
Recovery Yes (governance + storage) No (just shares it)
IRE No Yes (validated restores)

The vault sits in the Recovery Account; the IRE pulls validated recovery points via AWS RAM sharing.

What it does NOT do

The canonicalising source is explicit:

"Deletion protection keeps the recovery point available when needed. Whether the recovery point is safe to use is determined by the validation pipeline described in the following section."

The vault ensures availability — it does not ensure safety. Recovery points may carry malware, encrypted data, or modified configuration; the multi-layer validation pipeline is what determines safety.

Relationship to other AWS Backup primitives

Primitive What it does Cyber-resilience role
Standard vault Backup storage with IAM-based access controls Routine DR; insufficient for cyber-event isolation
Vault Lock (legacy) WORM controls on a standard vault Earlier-generation deletion protection; logically air-gapped vault is the recommended path
Logically air-gapped vault Compliance-mode + service-owned-account storage + MPA-gated restore Cyber-resilience primary backup target

Seen in

Last updated · 542 distilled / 1,571 read