Business Challenge
The opening sentence is the one people quote:
“While a snapshot is locked, it can't be deleted by any user, regardless of their IAM permissions.”
The next sentence is the scope, and it is just as plain: “You can continue to use a locked snapshot in the same way that you would use any other snapshot.”
Both are accurate. Together they say the lock defends the object's existence and nothing else — not its readability, not its distribution, not the things it depends on. That boundary is where the design work is.
Three bullets from the considerations list, each unremarkable alone:
- “You can delete the KMS key used to encrypt a locked snapshot.”
- “You can deregister an AMI that has associated snapshots that are locked.”
- “The only way to delete a snapshot that is locked in compliance mode before its lock expires is to close the associated AWS account.”
Read together they describe a reachable state. KMS is explicit about the consequence: “After a KMS key is deleted, you can no longer decrypt the data that was encrypted under that KMS key, which means that data becomes unrecoverable.” So the end state is a snapshot that cannot be deleted by anyone, for up to a century, and cannot be read either. The WORM guarantee holds perfectly and protects nothing you can use.
The saving grace is that key deletion is not instant. “AWS KMS requires you to set a waiting period of 7 – 30 days. The default waiting period is 30 days.” and “To recover the KMS key, you can cancel key deletion before the waiting period ends.” That window is the whole of your protection here, and nothing about the snapshot lock will tell you the clock is running.
This is the same shape as the disabled-AMI case in #98, where a recovery point stays intact and undeletable while being unrestorable. The lock is a statement about one object's lifecycle, and a restore is a statement about a chain of dependencies.
FixProtect the key with the same seriousness as the snapshot, and alarm on the waiting period rather than relying on noticing. A compliance-mode lock whose KMS key can be scheduled for deletion by one role is a retention control with a single point of failure that the lock itself will never report — but the 7 to 30 day window before the key actually goes is long enough to catch, if something is watching.
The two modes split the way they do for backup vaults. Governance mode is reversible: “users with appropriate IAM permissions can unlock the snapshot and modify the lock mode and lock duration or expiry date at any time”, and “the snapshot is locked immediately; there is no cooling-off period”.
Compliance mode has a cooling-off period, and the detail that matters is that it is optional: “You can lock a snapshot in compliance mode without a cooling-off period by omitting the cooling-off period in the request.” Do that and there is no window at all — “you can't unlock the snapshot, change the lock mode, or decrease the lock duration or expire date; you can only increase”, from the moment the call returns.
Where a window exists it is short: “The cooling-off period can range from 1 to 72 hours.” Put that next to #98's backup vault lock, where grace time “must be at least 3 days (72 hours)”, and the comparison is exact: the vault lock's shortest possible grace period is the snapshot lock's longest.
The duration on the other side is generous: “The duration can range from 1 day to 36500 days (100 years)”, or an expiry date instead.
FixUse governance mode unless a regulation names immutability, and if you reach for compliance mode, specify a cooling-off period rather than omitting it. Omission is a valid request that produces an unrecoverable state with no confirmation step, and the longest window on offer is three days.
The guidance is unusually direct:
“We recommend that you do not lock snapshots created by AWS Backup. AWS Backup already ensures that its snapshots are not deleted before their retention period expires. To add an additional layer of security for snapshots managed by AWS Backup, we recommend that you use AWS Backup Vault Lock.”
That draws the line cleanly. If a snapshot is managed by AWS Backup, its retention is the vault's business and the vault has its own lock. Snapshot lock is for snapshots you own directly — taken by hand, by Data Lifecycle Manager, or by your own automation.
Two more boundaries worth knowing before you plan around it:
“You can't lock snapshots during creation or during AMI registration”, so
locking is always a second step, and a snapshot locked while still being written carries a
condition —
“If you lock a snapshot while it is in the pending state and the snapshot
creation fails for any reason, the lock is canceled.”
Decide which system owns retention for each snapshot before locking anything. Two retention mechanisms on one object is not twice the protection; it is two sources of truth, and AWS has told you which one it expects to win.
Architecture
What the lock stops, and what it leaves alone
| Operation | Under a lock | AWS's words |
|---|---|---|
| Delete the snapshot | Blocked, for everyone | “can't be deleted by any user, regardless of their IAM permissions” |
| Use it — create volumes, copy, share | Unchanged | “use a locked snapshot in the same way that you would use any other snapshot” |
| Archive it | Allowed, both directions | “You can lock archived snapshots. And you can archive locked snapshots” |
| Deregister the associated AMI | Allowed | “You can deregister an AMI that has associated snapshots that are locked” |
| Delete the KMS key that encrypts it | Allowed | “You can delete the KMS key used to encrypt a locked snapshot” |
The bottom two rows are the ones to design around. Everything that makes the snapshot useful lives outside the lock.
The four states, and which one is a one-way door
| State | Can be deleted? | Can be unlocked? |
|---|---|---|
governance | No | Yes, with permissions |
compliance-cooloff | No — “A snapshot can't be deleted during the cooling-off period” | Yes, with permissions |
compliance | No | No — duration can only be increased |
expired | Yes — “The snapshot is not locked and can be deleted” | n/a |
Only compliance is a one-way door, and a snapshot enters it either when a cooling-off
period elapses or immediately, if the request omitted one.
How it compares with the backup vault lock
| EBS snapshot lock | AWS Backup Vault Lock | |
|---|---|---|
| Unit of protection | One snapshot | A vault and everything in it |
| Reversible window | Cooling-off, “1 to 72 hours”, optional | Grace time, “at least 3 days (72 hours)”, required for compliance mode |
| Can be immediate and irreversible | Yes, by omitting the cooling-off period | No |
| Ends on its own | Yes — the lock expires and the snapshot becomes deletable | No; the vault stays locked while it holds recovery points |
| Escape hatch | The same one: close the account, and after 90 days AWS deletes the data regardless | |
The row that matters operationally is the fourth. A snapshot lock has an end date by construction, so it is a retention period. A vault lock is a property of the container, so it is a retention regime. Choosing between them is choosing which of those you actually need.
The escape hatch is identical, and it is worth stating plainly
“If you close your AWS account while you have locked snapshots, AWS suspends your account for 90 days with your snapshots intact. If you do not reopen your account within the 90 days, AWS deletes your snapshots, even if they are locked.”
Word for word the same behaviour as a locked backup vault. Immutability is a property of the object inside the account, never of the account.
Why This Architecture Holds Up
A narrow guarantee, stated narrowly
AWS could have described snapshot lock as protecting your data. It describes it as preventing deletion, and then says in the next sentence that everything else is normal. A control that claims exactly what it does is one you can reason about; the KMS-key bullet exists in the documentation rather than in an incident report because of that habit.
Pointing customers away from the feature is the right call
“We recommend that you do not lock snapshots created by AWS Backup” costs AWS a use case and saves customers a conflict between two retention systems. It also implies the useful design rule: the thing that created the backup should be the thing that governs its lifetime.
Letting the lock expire is a real design choice
A lock that ends on its own matches how retention obligations actually work — keep this for seven
years, then stop. The alternative, a lock that never lifts, converts every retention requirement into a
permanent storage cost. The expired state is what makes snapshot lock usable for ordinary
compliance rather than only for the extreme case.
Key Architecture Decisions
| Decision | Choose this | Because |
|---|---|---|
| Which lock | Vault Lock for AWS Backup snapshots; snapshot lock for everything else | AWS says so directly, and two retention systems on one object is two sources of truth |
| Mode | Governance unless a regulation names immutability | It is the only mode you can undo, and AWS offers it as the way to “test your lock configuration before locking a snapshot in compliance mode” |
| Cooling-off period | Always specify one; prefer the 72-hour maximum | Omitting it is a valid request with no confirmation step and no way back |
| Lock duration | The retention obligation, not the 36500-day ceiling | You can only ever increase it once compliance mode is effective |
| KMS key policy | Protect it as part of the retention control | The key can be deleted while the snapshot cannot, and nothing in the lock reports that |
The audit worth running
For every locked snapshot, find the key that encrypts it and ask who can schedule that key for deletion. That set of principals is the real blast radius of your retention control, and it is usually wider than the set who could have deleted the snapshot before you locked it.
List locks by state and look for compliance with a long duration. Those
are the irreversible ones. A snapshot in that state with a 36,500-day duration is a decision nobody can
revisit, and it should have been deliberate.
Check whether any locked snapshot was created by AWS Backup. AWS recommends against it, and a snapshot governed by both a vault lifecycle and an independent lock will eventually surprise whoever is trying to clean up.
Closing Thought
Snapshot lock is a good control, and the reason it is a good one is that it does not overstate itself. It says deletion is impossible and that everything else is normal, and both halves are true.
The work it leaves you is the work the sentence implies. A snapshot that cannot be deleted is not the same as data you will be able to read in seven years, because reading it depends on a key, and the key has its own lifecycle, its own policy, and its own set of people who can end it.
#100 was about a number that measures something other than what you want to know. This is about a guarantee that covers something narrower than it sounds. Both are answered the same way: read the sentence after the one you were quoting.
Security & Identity — Block public access for Amazon EBS snapshots: what the account-level setting blocks, what it does not undo about snapshots already shared, and how it interacts with copies in other Regions.
Official AWS Reference
- Amazon EBS snapshot lock — the statement that a locked snapshot cannot be deleted by any user regardless of IAM permissions, the statement that it can still be used in the same way as any other snapshot, and the pricing note that locking is free while standard snapshot storage costs apply
- Amazon EBS snapshot lock concepts — governance mode being reversible and immediate, compliance mode and its optional cooling-off period of 1 to 72 hours, what can and cannot be changed after that period expires, the lock duration range of 1 to 36,500 days, and the four lock states including expired
- Considerations for Amazon EBS snapshot lock — that you can delete the KMS key encrypting a locked snapshot, deregister an associated AMI, lock and archive in either order, the recommendation against locking AWS Backup snapshots, the inability to lock during creation or AMI registration, the pending-state conditions, and the account-closure behaviour after 90 days
- AWS Backup Vault Lock — the grace time minimum of 3 days (72 hours) used in the comparison above, and the vault-level equivalent AWS recommends for snapshots it manages
- Delete an AWS KMS key — the statement that data encrypted under a deleted key becomes unrecoverable, the mandatory waiting period of 7 to 30 days with a 30-day default, and the ability to cancel deletion before that period ends
- Unlock a snapshot — further reading on the unlock operation and its permissions; no claims in this post are drawn from it
Comments