Protect backups across your Organization with Logically Air-Gapped vaults using a single policy

When you manage AWS Backup at scale through Organizations backup policies, the standard approach uses copy_actions to replicate backups into a protected vault. This works, but introduces friction:

• copy_actions.target_backup_vault_arn does not support a $region placeholder. You must hard-code one copy action per region.
• Each additional region adds policy size. The Organizations limit of 10,000 characters per backup policy becomes a constraint as regions grow.
• Copy actions create a second recovery point, increases storage costs.

The solution

Use target_logically_air_gapped_backup_vault_arn in your Organization backup policy. This is the only field in the backup policy language that supports both $region and $account placeholders. A single policy rule automatically resolves to the correct LAG vault in each member account and region no copy actions, no cross-region transfer, no per-region duplication.

For supported resources, AWS Backup creates the backup directly in the LAG vault.

What you get

• One policy, all accounts, all regions. The $region and $account placeholders resolve per member account. Adding a region means adding one entry to the regions array.
• No cross-region data transfer. Backups stay in the source region.
• Vault Lock compliance mode built in. LAG vaults prevent deletion or modification of recovery points, even by privileged users.
• Reduced storage costs. For fully managed resources, only one recovery point exists (in the LAG vault), not two.

What you give up

• Vault Lock is irrevocable after the cooling-off period. Validate retention values before applying to production.
• AWS-owned KMS key by default. If your compliance framework requires a customer-managed key, configure it at vault creation time.
• Not all resource types support direct LAG backup. Non-fully managed resources (EBS, EC2, Aurora, FSx) create a temporary recovery point in the standard vault first, then copy to LAG. The temporary point is deleted automatically after copy completes.
• Resources encrypted with AWS managed keys (e.g., aws/ebs, aws/rds) cannot be copied to LAG vaults. They must use a customer-managed KMS key or be unencrypted.

Prerequisites

• AWS Organizations with all features enabled
• BACKUP_POLICY policy type enabled
• A LAG vault with the same name deployed in every member account and region you want to protect
• A standard backup vault in each member account (required as the primary target for non-fully managed resources)
• AWSBackupDefaultServiceRole present in each member account

Implementation

1. Ensure a LAG vault exists in each member account

Deploy a LAG vault with a consistent name (e.g., org-lag-vault) in every member account and region. Use CloudFormation StackSets or your preferred deployment mechanism.

The vault name must be identical across all accounts and regions so the policy ARN resolves correctly.

2. Create the Organization backup policy

Attach this policy at the Organization root or target OU.

{
  "plans": {
    "OrgBackupPlan": {
      "regions": {
        "@@assign": ["us-east-1", "eu-west-1", "ap-southeast-1"]
      },
      "rules": {
        "DailyBackup": {
          "schedule_expression": { "@@assign": "cron(0 5 ? * * *)" },
          "target_backup_vault_name": { "@@assign": "Default" },
          "target_logically_air_gapped_backup_vault_arn": {
            "@@assign": "arn:aws:backup:$region:$account:backup-vault:org-lag-vault"
          },
          "lifecycle": {
            "delete_after_days": { "@@assign": "35" }
          }
        }
      },
      "selections": {
        "tags": {
          "BackupSelection": {
            "iam_role_arn": { "@@assign": "arn:aws:iam::$account:role/service-role/AWSBackupDefaultServiceRole" },
            "tag_key": { "@@assign": "Backup" },
            "tag_value": { "@@assign": ["true"] }
          }
        }
      }
    }
  }
}

Key points:

• target_backup_vault_name is required. It serves as the primary vault for non-fully managed resources (temporary recovery points land here before being copied to LAG).
• target_logically_air_gapped_backup_vault_arn must use both $region and $account. Literal account IDs are rejected by the service.
• Adding a new region means adding one entry to regions.@@assign. No new policy needed.

How it behaves per resource type

Resource type	Behavior
Fully managed (EFS, S3, DynamoDB)	Backs up directly to LAG vault. No recovery point in standard vault.
Non-fully managed (EBS, EC2, Aurora, FSx)	Creates a temporary recovery point in the standard vault, copies to LAG vault, then deletes the temporary point automatically after copy completes.
Unsupported or AWS-managed-key encrypted	Backs up to standard vault only. Backup job completes with informational message.
Locked backup vaults	If your target backup vault has vault lock enabled, temporary recovery points cannot be deleted manually and will be retained until either the copy completes or the retention period expires.

Things to watch

• Validate retention before production. LAG vault min/max retention is enforced. If your policy lifecycle falls outside the vault's range, backup jobs fail.
• Ensure the LAG vault name is consistent. If the vault doesn't exist in a given account/region, backup jobs targeting it will fail.
• Monitor for "Completed with issues." This status means a resource couldn't back up to LAG (unsupported type or encryption mismatch). Use EventBridge or Backup Audit Manager to catch these.
• This is not cross-account centralisation. Backups remain in each member account's LAG vault. If you need a single backup account, you still need copy_actions with literal cross-account ARNs.

Conclusion

target_logically_air_gapped_backup_vault_arn with $region:$account gives you immutable, Vault Lock-protected backups across your entire Organization with a single policy. No copy actions, no cross-region transfer, no per-region policy bloat. The tradeoff is that backups live in each member account rather than a central backup account but with Vault Lock compliance mode, they're protected from deletion regardless of who has access to the member account.