AWS Backup Vault Lock: governance against compliance mode, cross-account copies and restore testing

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Use governance mode while you are proving a retention design, because a suitably permitted administrator can still remove it. Use compliance mode only when the retention numbers are settled, because after the grace time nobody can remove it while the vault holds recovery points. Put the locked vault in a separate account, then run scheduled restore tests against that vault, proving on one resource first that the copies are selectable, since a backup that cannot be deleted can still be a backup that cannot be restored.

Commands below come from the AWS CLI reference or the AWS Backup Developer Guide, or are assembled from those options and marked "written for this article". None was run in a lab. Account IDs, ARNs and names are placeholders.

Why it matters

A deletion control only matters when somebody with real privileges is acting badly or by mistake. AWS states that any user, including the root user, who tries to delete a backup or change its lifecycle in a locked vault is denied.

The same strength makes configuration errors expensive. Backups in a locked vault cannot be deleted until their lifecycle completes, and standard storage charges keep applying. A wrong retention value in compliance mode is therefore a bill you may be unable to stop.

Vault Lock also protects only part of the path. It does not make a backup restorable, does not protect the encryption key, and does not cover every API that touches the underlying snapshot. Each of those gaps has its own control, covered below.

How it works

A recovery point is one backup held in a backup vault. Vault Lock is an optional setting on the vault, and each vault can have one lock.

Two modes, one API

The mode is chosen by one parameter on PutBackupVaultLockConfiguration. Omit ChangeableForDays for governance mode; include it for compliance mode.

The CLI reference calls the grace time a 72-hour cooling-off period, so the value must be 3 or greater. The guide gives the accepted range as 3 to 36,500 days. During that window the lock can be removed with DeleteBackupVaultLockConfiguration or changed with another put. Afterwards the delete call returns InvalidRequestException.

What minimum and maximum retention actually do

• MinRetentionDays is optional. Backup and copy jobs with a shorter retention fail. The shortest value is 1 day. It is required when the lock is created through CloudFormation.
• MaxRetentionDays is optional. Jobs with a longer retention fail. The longest value is 36,500 days.
• Neither bound changes a recovery point already in the vault. Those points keep their previous lifecycle.

The bounds act as an admission test on incoming jobs. A backup's own retention is defined when it is created and is independent of the lock's minimum and maximum. So a lock with a 35-day minimum does not extend a 7-day backup that was already in the vault when the lock was applied.

AWS sources count seven years differently: the guide says approximately 2,557 days, and the CLI reference uses 2555 days. Work out your own number from the wording of the retention obligation, then add a margin.

What the lock does not cover

Read these four limits before relying on the feature. The first three come from AWS's Vault Lock page. The fourth rests on the KMS page and is partly our reading.

• Direct EC2 APIs. Vault Lock and vault access policies govern actions taken through AWS Backup, not sharing or tier changes made directly through Amazon EC2 APIs. EBS snapshot recovery points can still be shared with ModifySnapshotAttribute and moved with ModifySnapshotTier, although EC2 still cannot delete snapshots that AWS Backup manages.
• Disabled AMIs. Disabling an AMI can temporarily block restores of EC2 instances, including backups under a vault lock or legal hold. AWS suggests denying ec2:DisableImage with IAM policies.
• Account closure. AWS suspends a closed account for 90 days with backups intact. If the account is not reopened, AWS deletes the vault contents even with Vault Lock.
• Encryption keys. Deleting a KMS key makes data encrypted under it unrecoverable, after a mandatory waiting period of 7 to 30 days. The vault lock page does not list key deletion as a protected action, so treat the key as a separate control.

AWS recommends denying ec2:ModifySnapshotAttribute and ec2:ModifySnapshotTier with IAM policies or SCPs, while exempting the roles your backup plans use. The exemption matters because AWS Backup uses those actions for cross-account copy and cold storage transitions. An SCP (service control policy) is an AWS Organizations policy that limits what accounts can do.

Do not confuse this feature with Amazon Glacier Vault Lock, which is a different feature.

Applying a lock in a safe order

1. Find anything that would become permanent

AWS warns specifically about recovery points with a retention of "Always": once compliance mode grace time ends they are retained forever and cannot be altered or deleted. Check before locking.

# Written for this article from the list-recovery-points-by-backup-vault reference
aws backup list-recovery-points-by-backup-vault \
  --backup-vault-name central_locked \
  --query 'RecoveryPoints[].[RecoveryPointArn,Status,Lifecycle.DeleteAfterDays,CalculatedLifecycle.DeleteAt]' \
  --output table

The response fields include Lifecycle.DeleteAfterDays and CalculatedLifecycle.DeleteAt. As an editorial reading, a row with no delete date, or with DeleteAfterDays of -1, which is how the API expresses "Always", needs a decision before you go further.

2. Start in governance mode

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name central_locked \
  --min-retention-days 7 \
  --max-retention-days 30

This is the AWS governance form: the compliance example without --changeable-for-days. Use the values your retention design needs. Then let real backup plans and copy rules run against it. Any job outside the bounds fails, which is exactly what you want to discover now.

3. Read back what the service recorded

aws backup describe-backup-vault --backup-vault-name central_locked

The guide lists the fields to inspect:

Locked: true does not tell you the lock is permanent. Compare LockDate to the current time. If no lock date was specified, the settings can be changed or removed at any time, which is what governance mode looks like.

4. Decide whether compliance mode is justified

This is an irreversible retention decision, not a command to run from this article. AWS documents compliance lock creation and changes during its grace period, but the cited pages do not establish a governance-to-compliance conversion procedure. Do not assume a repeated put safely converts an existing lock, and do not remove a working lock to try it.

A qualified owner should validate the exact path on a disposable vault, inventory all existing recovery points, check for Always retention, and approve both the bounds and the whole-period storage cost. Specify a grace window long enough for a second person to inspect the actual configuration and to exercise backup, copy and restore behaviour. Three days is the documented minimum, not a recommended review period.

Before the grace deadline, the decision record must say whether the tested outcome is accepted and who is responsible for any vendor-supported change or cancellation. Once the lock becomes permanent while recovery points remain, ordinary administrative access cannot undo it. No activation, conversion or lock-removal commands are supplied here.

Use the read-only describe-backup-vault result to retain the bounds, lock state and lock date. Backup Audit Manager also provides a control for resources protected with Vault Lock; that is ongoing configuration evidence, not proof of restorability.

Cross-account copies into a locked vault

A lock in the production account still leaves the backups inside the account being protected. A second account separates them from that account's credentials and from its closure. The requirements are specific.

Both accounts must belong to the same organisation in AWS Organizations, and cross-account backup must be enabled from the management account, in the console or through UpdateGlobalSettings.

# From the management account; the command errors in any other account
aws backup update-global-settings --global-settings isCrossAccountBackupEnabled=true

# Confirm from a member account
aws backup describe-global-settings

The update call returns an error if the account is not the management account, and describe-global-settings reports the flag.

On the destination vault, attach a policy allowing backup:CopyIntoBackupVault. The action must appear in both the role's identity policy and the destination vault's resource policy. The source role also needs backup:CopyFromBackupVault. Without the vault policy, attempts to copy in are denied. Scope the policy with aws:PrincipalOrgID or named accounts, using the AWS example forms.

Once enabled, any member account user can configure their account as a destination, so AWS recommends SCPs to limit destinations.

Limits that shape the design

Whether a resource type can be copied at all is listed in the feature availability table. A resource type without cross-Region or cross-account support cannot be copied in any scenario, including to another vault in the same account.

Where retention collides with the lock

Copies retain their source configuration, including creation date and retention, unless you override retention. Because copy jobs that do not conform to the lock bounds fail, the copy rule's retention must fall inside the destination's range.

Two traps follow from AWS's wording:

• Setting a copy to "Always" does not make it permanent. It keeps the source recovery point's expiry date. AWS says to make the source never expire, or to set the copy to expire 100 years after creation.
• Very short copy retention undermines incrementals. If the only recovery point in the destination expires, the next copy must be full; AWS advises at least one week.

If a transition to cold storage is configured, the expiry value must be more than 90 days beyond the transition value.

One security note: if a destination account later leaves the organisation it keeps the backups, so AWS suggests an SCP denying organizations:LeaveOrganization.

Check a copy by inspecting describe-copy-job, whose output includes a StatusMessage. A copy job in CREATED may be retrying, for up to 2 hours, or queued behind another job on the same resource.

Restoring from the other account

AWS Backup does not restore directly from one account to another. You either copy the backup back to the source account and restore there, or restore in the destination account. The destination needs the service-linked role for that resource type, which may not exist if the account has never used the service.

Restore testing the locked copies

Restore testing runs on a schedule, starts the same restore jobs as an on-demand restore and deletes the result afterwards. It supports these resource types: Aurora, DocumentDB, DynamoDB, EBS, EC2, EFS, FSx, Neptune, RDS, Redshift and S3. AWS's stated best practice is to designate an account for restore tests.

A plan and its selections are separate API objects. Create the plan first, then one selection per resource type.

# Written for this article from the create-restore-testing-plan reference
aws backup create-restore-testing-plan --restore-testing-plan '{
  "RestoreTestingPlanName": "central_locked_weekly",
  "ScheduleExpression": "cron(0 15 ? * SUN *)",
  "ScheduleExpressionTimezone": "Australia/Sydney",
  "StartWindowHours": 8,
  "RecoveryPointSelection": {
    "Algorithm": "RANDOM_WITHIN_WINDOW",
    "IncludeVaults": ["arn:aws:backup:ap-southeast-2:111122223333:backup-vault:central_locked"],
    "RecoveryPointTypes": ["SNAPSHOT"],
    "SelectionWindowDays": 30
  }
}'

# Written for this article from the create-restore-testing-selection reference
aws backup create-restore-testing-selection \
  --restore-testing-plan-name central_locked_weekly \
  --restore-testing-selection '{
    "RestoreTestingSelectionName": "rds_selected",
    "ProtectedResourceType": "RDS",
    "IamRoleArn": "arn:aws:iam::111122223333:role/restore-test-role",
    "ProtectedResourceArns": ["arn:aws:rds:ap-southeast-2:444455556666:db:example-db"],
    "ValidationWindowHours": 4
  }'

Points that decide whether the result means anything:

• RANDOM_WITHIN_WINDOW tests a random recovery point, not just the latest, which is the better check of older copies.
• SelectionWindowDays must be greater than your backup interval plus StartWindowHours, because the window is calculated from actual job start. Values run 1 to 365, default 30.
• Each run restores at most one recovery point per selected protected resource. The example names one ARN for a first run. A "*" wildcard would put every protected RDS resource in scope.
• The Restore testing page selects by vault and protected resource, but does not say whether cross-account copies in a central vault are selectable from that account, or what the plan needs to use them. This design is our reading. Prove it on one resource before relying on it.
• Tag conditions select the protected resource but do not choose the recovery point.
• Inferred defaults can fail. If the default VPC or subnet has been deleted and no metadata override is supplied, the restore fails. An account set up only to hold backups may have no default network, so plan the RestoreMetadataOverrides before the first run.

A completed restore proves only that the job finished. To prove the data is usable, send the restore-job COMPLETED event through EventBridge to a validation target such as Lambda, which reports with PutRestoreValidationResult. Valid statuses are FAILED, SUCCESSFUL, TIMED_OUT and VALIDATING. Once set, a validation status cannot be changed.

The validation window runs 0 to 168 hours, and data is deleted when validation completes or the window ends, whichever is first.

Read results with aws backup list-restore-jobs --by-restore-testing-plan-arn <arn> and describe-restore-job, which returns Status, ValidationStatus and DeletionStatus. A DeletionStatus of FAILED needs manual clean-up, and it is often caused by someone removing the awsbackup-restore-test tag.

Restore testing has its own charge per test, plus any cost of the restore jobs. AWS suggests starting small. Limits include 100 plans, 30 selections per plan and 30 ARNs per selection, none adjustable.

What to choose and why

These are editorial recommendations.

A logically air-gapped vault is always locked in compliance mode, can use an AWS owned key by default, and can be shared through AWS RAM so another account can restore from it. Check its supported resource types and Regions first.

A vault access policy can deny recovery point deletion, but it controls only AWS Backup APIs and an administrator able to change the policy can undo it. It is a lighter control, not a substitute for a lock.

Risks and limits

Warning: Compliance mode is irreversible after LockDate while recovery points remain. Do not apply it to a vault holding "Always" retention points unless permanence is intended. Storage charges continue for the whole retention period.

• The Cohasset assessment for SEC 17a-4, CFTC and FINRA concerns those US rules. It does not establish that a design meets an Australian or sector-specific obligation, so take that question to whoever advises you on it.
• Expiry is not instantaneous. AWS deletes expired backups at a randomly chosen point over the following 8 hours.
• Concurrent cross-Region or in-Region copy jobs are limited to 100 per account in the destination Region, not adjustable, for fully managed resource types. Once 100 is reached, a destination vault with fewer than 5 concurrent copy jobs can still start new ones, up to 5. Large estates may need staggered schedules.
• The restore role must reach the KMS keys for the backup and the restored resource. Key permission errors are listed among the documented restore test failures.
• Nothing here was tested in a live account. Confirm limits against the current pages for your Region before committing.

Sources

Opened 2026-11-10. Sources behind the corrections reopened 10 November 2026.

• AWS Backup Vault Lock
• Creating backup copies across AWS accounts
• Backup and tag copy
• Encryption for backups in AWS Backup
• Vault access policies
• Logically air-gapped vault
• Feature availability
• AWS Backup quotas
• Restore testing
• Restore testing inferred metadata
• Restore testing validation
• Delete an AWS KMS key
• AWS CLI reference: put-backup-vault-lock-configuration, delete-backup-vault-lock-configuration, describe-backup-vault, list-recovery-points-by-backup-vault, update-global-settings, describe-global-settings, describe-copy-job, create-restore-testing-plan, create-restore-testing-selection, put-restore-validation-result, describe-restore-job, list-restore-jobs

This article was originally published on 10 November 2026.