AWS Backup Vault Lock: Retention Boundaries Before the Grace Period Ends
Design AWS Backup Vault Lock around recovery-point retention, governance versus compliance mode, the irreversible grace deadline, and tested restores.
AWS Backup Vault Lock adds a retention guardrail to an AWS Backup vault. It can prevent privileged users, including the account root user, from deleting protected recovery points or shortening their lifecycle before the configured retention expires. It does not prove that a backup is complete, restorable, independent of the source account, or protected from every way a workload can be disabled. Treat it as one control in a recovery design, not as a substitute for restore drills or account separation.
Vault Lock is specifically an AWS Backup feature. It is not the similarly named Amazon S3 Object Lock feature and is not Glacier Vault Lock. The service, resource model, permissions, and retention lifecycle differ. A design that combines services should name the exact control applied to each backup copy rather than using “immutable” as an unqualified status.
Decide which lock mode matches the recovery objective
Governance mode restricts changes to principals with sufficient IAM permissions. It is useful when a separate, tightly controlled operator role must retain a documented override path. Compliance mode has a cooling-off period called the grace time. While that window is open, an authorized operator can review, change, or remove the configuration. After it expires, the lock becomes immutable; if the vault contains recovery points, the vault lock cannot be changed or deleted by a customer or AWS. A compliance-mode grace time must be at least 72 hours and can be configured up to 36,500 days.
Do not use the existence of a grace period as a reason to experiment in a production vault. Select the mode, account boundary, encryption key, backup plan, and intended restore path before creating the lock. Record who can request the change, who independently reviews it, which event starts the deadline, and who verifies the effective configuration before the grace time expires. A change request that reaches the wrong account or vault is still dangerous even if the CLI returns success.
Retention limits affect new jobs differently from existing recovery points
Minimum and maximum retention values are optional in the API. AWS’s documentation separately requires the minimum when creating a vault lock through CloudFormation, so do not assume the API’s optionality carries over to every provisioning tool. If a bound is omitted where allowed, Vault Lock does not enforce it. When configured, the bounds are evaluated against backup and copy jobs created after the lock is applied. A job whose lifecycle falls outside the configured range fails. Recovery points already in the vault before the lock are not retroactively changed by the lock’s minimum or maximum settings; they continue with their existing lifecycle.
This distinction should be tested against every backup plan and copy action. Inventory the resource types, planned retention periods, and existing recovery points before applying a bound. A value that appears to improve policy enforcement can instead cause future jobs to fail. Monitor job status after a staged rollout and alert on lifecycle incompatibility rather than assuming a successful lock change means backups are still being produced.
The other side of the same rule is cost. A recovery point with retention set to Always can remain indefinitely, and a locked recovery point cannot be deleted early just to stop storage charges. Estimate retention volume and cost over the complete lock period, including copies and failed operational cleanup. A legal or regulatory retention requirement should be mapped to a specific lifecycle and owner, not implemented as an unlimited value by default.
Inspect the target without changing it
Before any mutation, confirm the account, region, vault name, KMS key, backup plans, and recovery-point inventory. The following command is read-only and returns the vault’s lock status and configured bounds:
aws backup describe-backup-vault \
--backup-vault-name 'REPLACE_WITH_REVIEWED_VAULT' \
--region 'REPLACE_WITH_REVIEWED_REGION' \
--query '{name:BackupVaultName,locked:Locked,lockDate:LockDate,min:MinRetentionDays,max:MaxRetentionDays,key:EncryptionKeyArn}'Do not put a real account or region into a shared runbook unless it is intentionally environment-specific. Compare the Locked, LockDate, minimum, and maximum values with the approved change record. The date is UTC; calculate the remaining review window from the returned timestamp, not a local calendar guess. A read-only inspection of configuration is not proof that the next backup job will succeed or that a restore will work.
If infrastructure as code manages the lock, review the generated plan and provider version before applying it. Keep compliance-mode creation separate from unrelated backup-plan changes so reviewers can see the irreversible boundary. Never include a copyable command that silently creates a compliance lock with placeholder retention and an unreviewed grace period.
Preserve recovery paths outside the lock itself
A locked recovery point can still be unusable if the encryption key is inaccessible, the source service or account is disabled, the restore role was removed, or the application needs data outside AWS Backup. AWS documents cases where a separately disabled resource, such as an AMI, can block recovery even while its recovery point remains locked. Test the complete restore workflow with the intended security controls and record the required keys, roles, service quotas, network paths, and validation steps.
Vault Lock is not an account-survival guarantee. AWS documents that, after an account is closed and not reopened during its 90-day suspension period, AWS deletes the vault contents even if Vault Lock was in place. Keep account lifecycle and organizational recovery authority in the threat model, and verify that any separate backup account can actually be accessed during an incident.
Separate routine backup writers from lock administration and restore operators. Alert on backup and copy failures, changes to vault policy or encryption, and any change that affects the source resources needed to restore. A second account or logically air-gapped destination may reduce shared administrative risk, but the organization still needs an accessible recovery identity and tested key custody. A lock prevents specific deletion or lifecycle changes; it does not stop an attacker from corrupting the source before the next backup or from making the application unavailable.
Acceptance criteria
Before declaring the control production-ready, verify in a non-production vault that the intended roles can create and inspect recovery points, that jobs inside the retention range succeed, and that deliberately out-of-range jobs fail with an understood signal. Confirm the grace deadline and removal procedure with a second reviewer. Then restore representative data into an isolated target and validate the application, not just the existence of a recovery point. Keep a dated record of the lock configuration, backup-plan revision, restore-test result, and person responsible for the next review.
Vault Lock is effective when its exact retention behavior is understood, backup jobs continue to pass, privileged changes are separated, and recovery has been demonstrated. A lock without that operational evidence can preserve data that nobody can restore.
Related:
- Amazon S3 Object Lock: Immutable Retention and Recovery Boundaries
- How to Back Up and Restore Kubernetes etcd Without Creating a False Recovery Plan
Sources: