Most companies describe their backup strategy in SOC 2 documentation as protecting against data loss and ransomware, but a backup that a compromised admin credential — or a disgruntled insider with sufficient permissions — can delete isn't actually immune to either scenario. AWS Backup Vault Lock closes that gap by making backups genuinely immutable, in a way even the account root user can't undo once locked in compliance mode.
Why Standard Backups Don't Fully Solve This
Standard AWS Backup vaults protect against accidental deletion through IAM permissions, but permissions can be escalated, misconfigured, or bypassed by a sufficiently privileged compromised credential. If an attacker gains admin access to an account, deleting backups is often part of a ransomware playbook specifically to prevent recovery without paying — which means a backup strategy that relies entirely on IAM permissions for protection has a single point of failure.
What Vault Lock Actually Enforces
Vault Lock applies a Write-Once-Read-Many (WORM) policy to a backup vault, and in compliance mode, that policy cannot be deleted or shortened by anyone — including the AWS account root user — once a defined cooling-off period passes. This is a meaningfully stronger guarantee than a standard resource policy, which any sufficiently privileged principal can modify.
import boto3
backup = boto3.client("backup")
backup.put_backup_vault_lock_configuration(
BackupVaultName="production-critical-vault",
MinRetentionDays=90,
MaxRetentionDays=365,
ChangeableForDays=3, # cooling-off period before compliance mode becomes truly immutable
)
The ChangeableForDays parameter matters: during that window, the lock configuration itself can still be adjusted or removed, giving you a grace period to catch a misconfiguration before it becomes permanent. Once that window closes, the policy locks fully — no API call, console action, or support ticket to AWS can override it before the minimum retention period expires.
Governance Mode vs. Compliance Mode
Vault Lock also supports governance mode, which allows specific authorized users to remove the lock or delete backups under defined conditions — useful for organizations that want strong-but-not-absolute protection with a documented override path. Compliance mode is the stronger guarantee and the one that maps most directly to regulatory retention requirements, but it also means genuinely no one can shorten retention early, so the retention period needs to be chosen deliberately.
What This Produces as Evidence
For SOC 2 and similar frameworks, Vault Lock configuration itself — visible via get_backup_vault_lock_configuration — is direct, verifiable evidence that backups meet an immutability and retention standard, rather than a policy document asserting that backups "should" be protected. This is a stronger artifact than a written backup policy alone, because it demonstrates enforced, not just intended, protection.
Rolling This Out Without Breaking Legitimate Operations
Before locking a vault in compliance mode, confirm the retention window aligns with actual business and regulatory needs — a mistake here can't be corrected quickly once locked. We typically roll this out first in governance mode for a trial period, validate that legitimate backup lifecycle operations (rotation, testing restores) work as expected, then move to compliance mode for the vaults protecting the most critical data.
Frequently Asked Questions
Can we still restore from a locked backup vault normally?
Yes — Vault Lock prevents deletion and retention-period shortening, not restoration. Normal restore operations work exactly as they would on an unlocked vault.
What happens if we need to delete a backup for a legitimate reason, like a GDPR erasure request?
This requires careful planning before locking — compliance mode doesn't accommodate early deletion for any reason, including erasure requests, so vaults containing data subject to erasure obligations may need a different retention and lock strategy.
Does Vault Lock protect against ransomware that targets the backup vault directly?
Yes, this is one of its primary use cases — even with compromised credentials that would normally allow deletion, a compliance-mode locked vault cannot have its backups deleted before the retention period expires.
How do we choose the right retention period before locking?
Retention should be driven by your actual regulatory requirements and business recovery point objectives, reviewed with both compliance and engineering stakeholders before locking, since the choice becomes effectively permanent for existing backups once compliance mode is active.
See what an AWS infrastructure audit finds in your backup and DR posture → rutagon.com/contact or call 907-841-8407.