AWS Backup Vault Lock protects recovery points from deletion and lifecycle changes that would violate the vault-lock configuration. It is designed for write-once-read-many style backup governance, including environments where an attacker or administrator with broad credentials must not be able to shorten retention or remove recovery points before they expire.
Inside the AWS Architecture and Operations cluster, Vault Lock is one layer in a recovery system. Backup plans create recovery points, vault lock protects them, restore testing proves they are usable, and retention policy controls how long the organization pays to keep them.
The existing AWS backup recovery design article provides the broader recovery-planning context.
Governance mode can still be changed by privileged administrators
Vault Lock governance mode is intended for environments where designated administrators should retain the ability to manage or remove the lock. Users without the required permissions cannot bypass the configured protection, but an IAM principal with sufficient privilege can remove the lock.
This is useful during early adoption, testing, or governance scenarios where the organization wants strong protection without making the vault permanently immutable.
Governance mode should not be described as the same control as compliance mode. It reduces accidental or unauthorized changes but still leaves an administrative escape path.
Compliance mode becomes immutable after its grace period
Compliance mode includes a configurable grace period before the lock becomes immutable. AWS requires that period to be at least three days. During the grace period, the organization can change or remove the lock if it discovers a configuration problem.
After the grace period expires, the vault lock cannot be changed or removed by a user or by AWS. Recovery points cannot be deleted until their lifecycle retention completes. That is the core WORM-style property that supports strict retention requirements.
The grace period should therefore be used as a deliberate validation window, not just accepted as a default countdown.
Minimum and maximum retention are enforcement rules for new jobs
Vault Lock can define a minimum retention period, a maximum retention period, or both. New backup and copy jobs targeting the vault fail if their lifecycle retention falls outside those bounds.
The retention bounds do not rewrite the lifecycle of recovery points that were already in the vault before the lock was configured. Existing recovery points keep their previous lifecycle settings, although the vault lock still protects them from prohibited deletion and lifecycle changes while the lock is active.
That distinction matters during migration. Creating a lock does not retroactively normalize every existing recovery point to the new minimum or maximum.
Retention mistakes can become permanent cost mistakes
Compliance mode intentionally removes the ability to correct some mistakes after the grace period. AWS explicitly warns about recovery points configured for indefinite retention because they can become impossible to delete and create persistent cost.
Before the lock becomes immutable, inventory every existing recovery point, lifecycle, legal requirement, and backup plan that writes to the vault. Confirm that minimum and maximum retention align with policy and that no “always retain” setting was added casually.
This is one of the rare AWS configurations where “we can fix it later” may stop being true by design.
Vault Lock does not replace restore testing
An immutable backup that cannot be restored is only an immutable failure. The organization still needs recovery drills that prove the protected recovery points can restore the systems, data, keys, permissions, and application dependencies needed for service recovery.
The existing ransomware recovery testing article is directly relevant. Attackers target backup systems because destroying recovery options increases leverage.
Restore tests should use the same locked recovery points and recovery accounts or Regions the real incident plan would use.
Lock configuration should be separated from backup-plan ownership
A team that owns application backups may not be the right team to control the immutable-vault policy. Separating backup-plan administration from vault-lock administration can reduce the chance that one compromised role can both change what gets backed up and weaken the retention protection.
Organizations can also use cross-account backup patterns so recovery points live in an account with a narrower trust boundary than the workload account.
The design should make it difficult for a single operational credential to erase both production and the recovery copy.
Copy jobs need to satisfy the destination vault’s retention controls
Vault Lock applies to backup and copy jobs targeting the locked vault. If the lifecycle on a copy job does not meet the configured minimum or maximum, the job fails rather than silently storing a noncompliant recovery point.
This should be tested before production because a new lock can break an existing cross-Region or cross-account copy plan whose retention differs from the newly enforced policy.
Monitoring should alert on failed backup and copy jobs so compliance controls do not create an unnoticed protection gap.
Compliance evidence should include configuration and recovery behavior
For audit purposes, the useful evidence is more than “Vault Lock is enabled.” Teams should record the mode, grace period, minimum and maximum retention, the vault ARN, backup-plan relationships, and the restore-test history that proves protected recovery points are usable.
Control evidence should also show which principals can administer governance-mode locks and which accounts own the immutable recovery copies.
This turns backup immutability from a checkbox into an operationally defensible control.
Use immutability where the organization is prepared to live with it
Vault Lock is powerful precisely because it can remove administrative flexibility. Compliance mode should therefore be reserved for backup sets whose retention requirement is well understood and whose cost has been reviewed.
Later in this cluster, S3 Object Lock and Immutability covers the related object-storage control. The two services solve similar immutability goals in different storage contexts and should be chosen based on the recovery workflow and data type being protected.
Vault selection should follow recovery scope. A single locked vault can simplify policy, but mixing unrelated workloads with very different retention requirements can force one maximum or minimum that does not fit every dataset. Separate vaults can make legal hold, short operational backups, long-term compliance retention, and cross-account copies easier to reason about without weakening the lock.
Before compliance mode becomes immutable, the team should test restore permissions as well as backup creation. A locked recovery point can still be operationally useless if the recovery account lacks KMS permissions, the target service has changed, or restore metadata is incomplete. Recovery testing should use the identities and Region the real incident would use.
Monitoring should include lock configuration drift during the grace period. In governance mode, privileged administrators can remove or change the lock; in compliance mode, changes are still possible before the grace period expires. CloudTrail and configuration monitoring can alert when a vault-lock setting changes unexpectedly during that window.
Cross-account design can strengthen separation of duties. Workload accounts can create backups and copy recovery points to a dedicated backup account where fewer principals have administrative access. Vault Lock in the destination then protects the copy even if the production account is compromised. The copy schedule and retention still need to satisfy the destination vault’s limits.
Recovery-point lifecycle should be aligned with application dependencies. Restoring a database from an immutable backup may also require application configuration, secrets, IAM roles, and infrastructure templates from the same period. Protecting only the data layer can leave the organization unable to recreate a functioning service after a destructive event.
Finally, legal and compliance teams should confirm that technical retention maps to the actual obligation. Minimum retention that is too short creates noncompliance; maximum retention that is too long can conflict with data-minimization requirements. Vault Lock enforces the configured rule exactly, so policy translation has to be correct before immutability removes the ability to revise it.
Encryption-key availability belongs in the same recovery design. A locked backup that depends on a KMS key should be recoverable even during the incident scenario the organization is planning for. Key policy, cross-account access, key rotation, and the recovery account’s permissions should be tested with the backup rather than assumed from configuration.
Backup plans should also avoid writing noncompliant lifecycles to a locked vault repeatedly. If a plan’s retention falls outside the Vault Lock limits, the job fails. A deployment pipeline can validate backup-plan retention against the vault policy before promotion so the first indication of incompatibility is not a failed production backup.
Deletion protection should be combined with monitoring for missed backups. Vault Lock prevents a protected recovery point from being removed early; it does not guarantee that a new recovery point was created successfully today. Dashboards should therefore show both immutable inventory and backup-job success/freshness.
The organization should rehearse emergency access without weakening immutability. Recovery teams need enough permissions to restore, copy, inspect, and validate recovery points, but they should not require privileges that could remove the compliance lock. The recovery role and backup-admin role can be designed as separate operational identities.
Document the lock activation as a change record with named approvers, the grace-period end date, and the exact retention values. Compliance mode intentionally turns a configuration into an irreversible control, so the approval evidence should be strong enough that another team can verify why the vault was locked that way years later.
