What Is Object Lock and How Does S3 WORM Storage Work?

Object lock, S3's write-once-read-many (WORM) storage feature, answers a specific question a lot of backup and compliance discussions eventually run into: how do you stop even a compromised admin account from deleting your data. AWS's own description is direct about the mechanism, it "blocks permanent object deletion during a customer-defined retention period," enforced at the storage layer itself, not through a permissions policy someone with the right access could simply change. This article covers how object lock actually works, the real difference between its two enforcement modes, and where AIOZ Storage's own documented gaps leave it relative to this specific feature.

TL;DR:

• Object lock blocks an object version from being deleted or overwritten for a set retention period, enforced by S3 itself, not by IAM permissions someone could reconfigure.
• Compliance mode is absolute, AWS states plainly that a locked version "can't be overwritten or deleted by any user, including the root user." Governance mode allows an exception for users with special permission.
• AIOZ Storage's documentation doesn't describe object versioning at all, the feature object lock is built on top of, so it doesn't support object lock either, a real, citable gap worth knowing before assuming otherwise.

What Is Object Lock?

AWS's own feature page states the mechanism plainly: object lock "prevents locked object versions from being permanently deleted (accidental or intentional) or overwritten." The "accidental or intentional" framing matters, this isn't just a safeguard against fat-fingering a delete command, it's specifically designed to survive an intentional deletion attempt too, including one from an attacker who has already gained legitimate-looking access to the account. That's a meaningfully stronger guarantee than a permissions policy provides, since permissions can be changed by whoever controls the account, a lock enforced at the storage layer itself can't be talked around the same way.

How It Actually Works: Versioning Is the Foundation

Object lock isn't a standalone feature bolted onto a bucket, it's built directly on top of object versioning. AWS states this requirement directly: "With S3 Object Lock, S3 Versioning is automatically enabled, and these features work together to prevent locked object versions from being permanently deleted." That dependency makes sense once you see what's actually being protected: object lock doesn't prevent a new version of a key from being written, it protects a specific existing version from being deleted or overwritten, which only means something if multiple versions of an object can exist side by side in the first place.

Compliance Mode vs Governance Mode: A Real Difference in Absoluteness

The two enforcement modes aren't just different default settings, they're genuinely different guarantees. In Compliance mode, AWS's language leaves no exception: "A protected object version can't be overwritten or deleted by any user, including the root user in your AWS account," and "you cannot change the retention mode, and you cannot shorten the retention period." Once set, nobody, not a compromised admin credential, not AWS support, not the account owner, can undo it before the retention period expires.

Governance mode keeps the same day-to-day protection, "users can't overwrite or delete an object version or alter its lock settings unless they have special permissions," but leaves a deliberate escape hatch: "you can still grant some users permission to alter the retention settings or delete the object if necessary." That's a real, meaningful trade-off, not a lesser version of the same feature: Compliance mode is for requirements that must survive literally any internal actor, regulatory retention being the standard case, while Governance mode fits situations that need strong day-to-day protection with a documented, permissioned way to make a legitimate exception.

Legal Hold: A Separate, Open-Ended Protection

Object lock includes a second, independent mechanism worth distinguishing from retention periods. AWS states legal holds plainly: "A legal hold remains in place until you explicitly remove it," and critically, "legal holds are independent from retention periods." A retention period is a countdown with a known end date, set once and left to expire. A legal hold has no end date at all until someone with the right permission actively lifts it, better suited to an open-ended situation like active litigation, where nobody can know in advance when the protection should actually end.

Why This Matters Specifically for Ransomware

The 3-2-1-1-0 backup framework's own reasoning applies directly here: modern ransomware targets backups specifically, not just production data, because a backup that's technically a separate copy but still writable by a compromised environment can be encrypted or deleted right alongside the original. Object lock's Compliance mode is a direct, concrete answer to that specific threat: even an attacker holding valid, legitimate-looking root credentials cannot delete or overwrite a locked version before its retention period ends. That's the exact gap a permissions-only defense can't close, since permissions are exactly what a compromised credential already has.

Where AIOZ Storage Fits

AIOZ Storage's own documentation doesn't describe an object versioning feature, already established elsewhere in this series as a real, citable gap, and confirmed fresh again while researching this article: /docs/concepts/definitions contains no mention of versioning, object lock, WORM, immutability, retention periods, or legal holds anywhere. Since object lock is built directly on top of versioning, and AIOZ Storage doesn't document versioning at all, it follows directly that object lock isn't available either, not a separate gap, the same underlying one.

That's a real limitation for a specific use case, anyone whose requirements call for object-lock-grade immutability, ransomware-resistant Compliance mode retention, or legal-hold-style open-ended protection can't get it from AIOZ Storage's documented feature set as it stands today. It's not a limitation that affects most other use cases this series covers, and it's worth stating plainly rather than either hiding it or overstating it.

What to Do Instead

If object-lock-grade immutability is a genuine requirement, the honest options are the same ones already covered for AIOZ Storage's broader versioning gap: put a version identifier directly in the object key rather than relying on a platform feature to preserve prior versions, or layer a tool built for this specifically, like DVC, on top of the bucket. Neither is a true substitute for storage-layer-enforced immutability the way Compliance mode provides it, an application-level convention can still be bypassed by whoever controls the application, but they're real, working answers to "how do I avoid silently losing data to an overwrite" short of object lock itself. For a genuine Compliance-mode requirement specifically, that likely means the truly immutable copy in a 3-2-1-1-0 strategy needs to live on a provider that documents object lock directly.

Frequently Asked Questions

What is S3 object lock?
A WORM (write-once-read-many) feature that blocks a specific object version from being deleted or overwritten for a set retention period, enforced by the storage system itself rather than by permissions policy alone.

What's the difference between Compliance mode and Governance mode?
In Compliance mode, no user, including the root account, can delete, overwrite, or shorten the retention period once set. Governance mode gives the same day-to-day protection but allows specifically permissioned users a documented way to make an exception.

Does object lock require versioning?
Yes. AWS states that enabling object lock automatically enables S3 Versioning, since object lock protects a specific object version, which only means something if multiple versions of an object can exist at once.

What is a legal hold, and how is it different from a retention period?
A retention period has a defined end date and expires automatically. A legal hold has no end date, it remains in place until someone with the right permission explicitly removes it, suited to open-ended situations like active litigation.

Why does object lock matter for ransomware protection specifically?
Because Compliance mode survives even a compromised account with valid-looking root credentials, an attacker who gains access can't delete or overwrite a locked version before its retention period ends, closing the exact gap a permissions-only defense can't.

Does AIOZ Storage support object lock?
No. AIOZ Storage's documentation doesn't describe object versioning, the feature object lock depends on entirely, so object lock isn't available either. This was confirmed directly against AIOZ's own concept-definitions page.

What should I use instead if I need immutable storage and AIOZ Storage doesn't support object lock?
For general overwrite protection, a version identifier in the object key or a tool like DVC layered on top. For a genuine Compliance-mode requirement, specifically surviving a compromised account, that likely needs a provider that documents object lock directly, since neither workaround is storage-layer-enforced the way object lock is.

Related Reading

• The 3-2-1 Backup Rule: A Practical Framework Explained - the broader backup framework object lock's immutable-copy requirement fits into.
• How to Use AIOZ Storage Effectively: A Practical Checklist - the versioning gap object lock depends on, and the workaround this article builds on.
• Using AIOZ Storage as a Dataset and Model-Output Backend - the same no-native-versioning limitation, covered for AI/ML workloads specifically.
• What Is Data Replication? How Distributed Storage Systems Stay Available - a different kind of protection, surviving hardware failure, distinct from surviving a compromised account.
• What Is S3 Object Versioning and How Does It Work? - the underlying mechanism object lock is built directly on top of, covered on its own terms.
• SSE-S3 vs SSE-KMS vs SSE-C: S3 Encryption Types Explained - a different, independent protection layer, encryption, that applies regardless of whether an object is locked.

References

• AWS: S3 Object Lock
• Scality: S3 Object Lock - Immutability and WORM