S3 Object Lock, WORM, and what “immutable” actually buys you
By Dylan Wolpe
The short version
- Object Lock and WORM enforce that an object cannot be deleted or overwritten for a retention period. That is a storage-layer permission guarantee, not a statement about content.
- A content-verified guarantee is independent of where the bytes live: you can prove an archive is unaltered after copying it to a different provider, or to a tape in a drawer.
- The two are complementary, not competing. Object Lock stops the deletion; content verification survives the migration, the provider change and the vendor going out of business.
- The question that separates them: if you copied this archive somewhere else tomorrow, would you still be able to prove it is unaltered? Object Lock alone answers no.
An auditor asks whether your seven-year records are immutable. Object Lock is switched on, so the answer is yes. Both of you now believe something has been established that mostly has not, and the gap only becomes visible at the worst possible moment — during a restore, a migration, or a dispute.
What Object Lock actually guarantees
Object Lock and equivalent WORM features enforce a rule at the storage layer: for a stated retention period, this object cannot be deleted or overwritten through the provider’s API. In compliance mode not even the root account can lift it.
This is genuinely valuable, and it defends against the threats that actually destroy records in practice: ransomware, a mistaken lifecycle policy, a panicking administrator, an over-broad script. If you are not using it and your regulator expects retention, use it.
But notice the shape of the guarantee. It is a statement about permissions in one system.
| Question | Object Lock answers |
|---|---|
| Can this object be deleted here? | No, until retention expires |
| Can it be overwritten here? | No |
| Is the content what it was when written? | Doesn’t say |
| Is this restored copy the original? | Doesn’t say |
| Does the guarantee survive migration? | No |
| Can a third party verify it without the provider? | No |
Where the difference bites
You change provider. Three years in, you move to another cloud on cost. The objects arrive intact — probably. The lock did not come with them, and nothing in the new location attests that what arrived is what left. Your seven-year record now has a three-year gap in its provenance, and it happened during a routine procurement decision.
You restore from a copy. A backup of the archive is restored from somewhere that was never under lock. It looks right. There is no way to establish that it is right.
Someone asks the awkward question.“How do you know this file is the one written in 2026?” With Object Lock alone the answer is that the provider says so — which is a real answer, and it is an answer that depends on trusting a commercial third party’s control plane and their account security, indefinitely.
Object Lock protects the bytes where they are. Content verification protects the claim wherever they go.
What content-verified adds
If the archive carries its own integrity structure, the guarantee stops being a property of the location:
- Copy it to another provider, a laptop, or a tape, and it still proves itself.
- Verification runs offline, by anyone, with no account and no relationship with the storage vendor or with us.
- If something did change, you learn where — not merely that a check failed.
- It keeps working after the provider is replaced, and after we are gone.
The question to ask
Whatever you are evaluating, one question separates the two guarantees cleanly: if I copied this archive somewhere else tomorrow, could I still prove it is unaltered?
With storage-enforced immutability alone the honest answer is no — the guarantee stayed behind. If the answer is yes, you are holding evidence rather than a configuration setting, and the distinction is the one that matters seven years from now when the provider, the contract and quite possibly the company have all changed.
Ours is described on the WORM alternative page, and the related erasure problem — deleting one person from something you promised never to change — is covered in a separate piece.
Questions people ask about this
Does S3 Object Lock make my data tamper-proof?
It makes objects undeletable and unoverwritable for a retention period, enforced by the storage provider. That is strong protection against deletion and modification through that provider's API. It is not a property of the data itself — move the object elsewhere and the guarantee does not travel with it.
What is the difference between WORM storage and a tamper-evident format?
WORM is enforced by the storage layer: the system refuses to let you change the bytes. Tamper-evidence is a property of the content: the data carries the means to detect whether it changed, regardless of where it is stored. One prevents alteration in one place; the other detects it anywhere.
Do I need both?
Usually yes, and they cost little together. Object Lock prevents accidental and malicious deletion while the data sits with that provider. Content verification means the archive still proves itself after migration, provider failure, or a restore from a copy nobody can vouch for.
Can Object Lock retention be removed early?
In governance mode, yes — a sufficiently privileged account can shorten or remove it, which is often the right operational trade. In compliance mode it cannot be removed by anyone, including the root account, until it expires. Knowing which mode you are actually in matters more than the feature being switched on.