An AWS Backup logically air-gapped vault is a second vault type with a compliance-mode lock and storage that is not the workload account's ordinary backup vault. The point of the isolation is a recovery point the workload account cannot delete on a bad day. A standard vault in the same account, with a resource policy the same administrators can edit, is not that isolation. A cluster built to run without a network is a different design entirely. This is a backup vault. Rutagon places it in an account the workload principals do not own, copies recovery points in, and leaves restore as a deliberate path rather than a delete path.
The failure we are designing against is an identity in the workload account, stolen or mistaken, that can call delete on the only backups. Vault lock on a local vault helps, and we still use it where a local vault is the primary copy. The air-gapped vault is the copy that does not live under that identity. The vault lock article is the lock itself. This article is the vault the workload account does not own.
What an AWS Backup logically air-gapped vault locks on creation
The logically air-gapped vault documentation describes a specialized vault. Each one is equipped with vault lock in compliance mode. You set a minimum retention and a maximum retention when you create it. The minimum the API accepts is 7 days. A backup whose retention is shorter than the minimum cannot be copied in. A backup whose retention is longer than the maximum cannot be copied in either. The lock is not an optional checkbox you might remember. It is part of the vault.
Encryption is an AWS owned key by default, or a customer-managed key if you pass one. The key type stays visible in the API and in the console, including when the vault is shared, so a reviewer can see which key wraps the copy. AWS recommends the AWS owned key unless you have a reason to bring a customer-managed key, preferably from an account you still control if the workload account is the one you do not trust. A customer-managed key that only the workload account can disable is a weak isolation. We do not put the only key under the identity we are trying to contain.
The recovery points are stored in an AWS Backup service owned account. CloudTrail on your side shows that sharing as a modification outside the organization. That is the isolation boundary in one sentence: the bytes are not sitting in a vault the workload administrators can empty. A standard vault remains the place the first backup lands. The logically air-gapped vault is the copy target, or a primary target when you have chosen that mode. Shared accounts, if you share the vault, can view or restore. The copy documentation says those shared accounts do not get to create a copy. Restore is not delete.
vault_type: logically air-gapped
lock: compliance mode, set when the vault is created
min_retention_days: 7 or greater
owner: backup account, not the workload account
workload_path: copy in, no delete on the recovery points
share: individual account IDs through RAM, restore rather than delete
You cannot delete the vault while it still contains recovery points. That is true of vaults generally, and it matters here. An attacker who cannot delete the recovery points also cannot delete the vault out from under them. A restore-access view in a recovery account is not the same object. The docs say that view can be removed even when vault lock would block deleting the underlying vault. We do not treat deletion of a restore view as deletion of the backups. The backups stay with the vault that holds the recovery points.
Why the workload account cannot delete the copy
The workload account's ordinary IAM policies can delete recovery points in a vault that account owns, unless a lock in compliance mode already forbids early delete. Compliance mode on a vault the same account owns is useful, and it is still one account boundary. The air-gapped design adds the second boundary. The vault is created in the backup account. The workload account is allowed to copy a recovery point to that vault, through a backup plan or a copy job, using a role that can start the copy and cannot manage the destination vault's lock. After the copy, the recovery point ARN in the destination uses the backup service, not the original resource type. There is no DeleteRecoveryPoint for the workload role against a vault it does not own.
RAM sharing does not hand the workload account that delete. Sharing is optional, and it is by account ID, not by an entire organization or OU. The permissions in the share path the docs list are describe, list, and start restore. We share with the recovery account that should be able to restore during an incident. We do not share with the workload account if the workload account is the identity we assume may be hostile. The workload account's job ended when the copy succeeded.
Multi-party approval is the additional path when the vault-owning account itself is unavailable. AWS documents it so a closed or locked owning account does not strand the only restore. We turn that on when the business requirement is "restore even if the backup account cannot sign in," and we do not turn it on as a casual extra admin. Every extra principal is another person who can reach the vault. The design goal is a short list.
Retention still does its job inside the lock. Compliance mode means you do not shorten the minimum because a cleanup script asked. Backups that do not fit the min and max never arrive, which is a job failure you should alert on. A copy job that fails because retention is 3 days and the vault minimum is 7 days is not isolation. It is a miss. We set the plan's lifecycle so the copy is legal for the vault, and we alert on failed copy jobs. A local vault full of backups and an empty air-gapped vault is the worst reading of a green backup dashboard.
Region limits exist. The docs list Regions where this vault type is not offered. We do not promise the vault in a Region the page excludes. Cross-Region copies into a vault where the feature exists are the resiliency path the docs recommend. One copy in the same Region as the workload is still better than no second vault. It is not the whole story if the Region is the failure mode you care about.
OU backup policies can name this vault as a target once the vault exists in the account the placeholder resolves to. The policy does not create the isolation. The vault account, the lock, and the copy role do. Order matters. Create the vault in the backup account. Prove a copy lands. Then point the organization plan at it.
What Rutagon delivers
The deliverable is the vault in the backup account, the compliance lock with a minimum of at least 7 days, a copy role in the workload account that cannot delete destination recovery points, a tested restore from the recovery account, and an alarm on copy failure. AWS cloud infrastructure is that build. We do not call a network-isolated cluster this vault, and we do not call a standard vault with a hopeful IAM deny this vault. The service-owned storage and the compliance lock are the product. The account split is the part we refuse to skip.
Resource types that are not supported will not copy. Unencrypted clusters of certain databases are called out as unsupported because the vault expects encryption. We read the feature table for the resource you actually run before we tell you the recovery point is isolated. An unsupported resource left only in the workload vault is still one delete away from gone. That gap belongs in the record, not in a footnote after an incident.
Rutagon keeps backup copies for our own accounts on a vault the workload roles do not own. The pattern is the same one we put in a client organization. The test is a delete attempt from the workload account that fails, and a restore from the recovery account that succeeds. Anything short of both results is a design that has not been shown.
Frequently Asked Questions
How is this different from a backup vault in the workload account?
A standard vault lives in the account and can take an optional lock. A logically air-gapped vault is created with compliance-mode lock already on, and its recovery points are stored in an AWS Backup service owned account. We place that vault in a backup account the workload principals do not administer. A lock in the same account is a control, and a vault in another account is the isolation.
Can the workload account still delete backups if it owns the vault?
If the workload account owns the vault, its administrators are the owners. Compliance mode stops early deletion of recovery points, which is already strong, and it is still one account. The design we ship puts ownership in the backup account and gives the workload account a copy path. Shared access, when we enable it, is restore-oriented and is not a delete permission for the account that produces the data.
What retention can we set?
The create API requires a minimum of 7 days and a maximum you choose. Copies that fall outside that range fail. Set the backup plan's retention so the copy is accepted. A failed copy leaves you with only the local vault, which is the situation this vault was meant to fix.
Does sharing the vault with the organization give every account delete?
No. The vault is shared with individual account IDs through AWS RAM, not with an OU or the whole organization, so another account can view and restore. We share with the recovery account. We do not share with every workload account because the console made a list easy.
Can we delete the vault to throw away the backups?
Not while recovery points remain in it. Emptying it would mean deleting those recovery points, which compliance mode and the account boundary are there to prevent from the workload side. Removing a restore view in a recovery account does not delete the underlying recovery points. Treat a deleted view as a lost window, not as destroyed backups.
Ask us to build the isolated backup vault the workload account cannot delete. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.