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, no user can undo it before the retention period expires, whether that's a compromised admin credential or the account owner. AWS's documentation adds one blunt footnote: the only way to delete an object under compliance mode before its retention date is to delete the associated AWS account.

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.

Setting It Up: Object Lock Is Enabled Per Bucket, and It's One-Way

Object Lock has to be turned on for a bucket before any object in it can be locked, and versioning has to be on too. On a new bucket that's one flag:

aws s3api create-bucket --bucket my-locked-bucket --object-lock-enabled-for-bucket

For an existing versioned bucket, you enable it with put-object-lock-configuration, which can also set a default retention rule in the same call. AWS's example sets a 50-day compliance default:

aws s3api put-object-lock-configuration --bucket my-locked-bucket \
  --object-lock-configuration '{ "ObjectLockEnabled": "Enabled", "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 50 }}}'

Read AWS's warning before running either: "After you enable Object Lock on a bucket, you can't disable Object Lock or suspend versioning for that bucket." The console makes you acknowledge that enabling it "will permanently allow objects in this bucket to be locked." A second restriction is easy to miss: buckets with Object Lock can't be used as destination buckets for server access logs, so keep those on a separate bucket, as covered in S3 access logs vs CloudTrail.

Retention Periods in Practice

A retention period is attached to an individual object version, not to a key and not to the bucket as a whole. That has a few consequences worth working through:

• A default rule is just a default. When a version is uploaded with its own explicit mode and period, those settings override the bucket's default.
• Different versions of one key can have different periods. AWS's example: an object is 15 days into a 30-day period, and you upload the same key with a 60-day period. The upload succeeds and creates a new version with 60 days, while the older version keeps its original schedule and becomes deletable in 15 days.
• You can extend a period but not shorten it under compliance mode. To extend, submit a new request with a later retain-until date. Anyone with s3:PutObjectRetention can do this.
• Governance mode is the safe place to experiment. AWS says you can use it "to test retention-period settings before creating a compliance-mode retention period," which matters because compliance settings can't be undone.

Setting retention on a specific version looks like this:

aws s3api put-object-retention --bucket my-locked-bucket --key my-image.fs \
  --retention '{ "Mode": "GOVERNANCE", "RetainUntilDate": "2027-01-01T00:00:00" }'

Variable Retention: When You Don't Know the End Date Yet

The earlier sections split protection into retention periods and legal holds, but AWS's documentation now describes two retention types within retention itself. Fixed retention is the classic one: you give a retain-until date up front. Variable retention defers that decision. You turn on an event hold and set a duration, and the object stays protected while the hold is on. When you release the hold, S3 sets the retain-until date to the release time plus the duration.

While the hold is active, the date isn't fixed: AWS describes it as the current time plus the duration, moving forward as time passes. Two safeguards keep it from being weakened: decreasing the duration never sets an earlier date than the current one, and you can add an explicit minimum retain-until date so the object stays protected until at least then, even if the hold is released sooner. Durations run from 1 to 36,500 days or 1 to 100 years.

AWS's CLI example sets a compliance-mode event hold with a 30-day duration:

aws s3api put-object-retention --bucket my-locked-bucket --key my-document.pdf \
  --retention '{"Mode":"COMPLIANCE","EventHold":"ON","EventHoldDuration":{"Days":30}}'

Releasing it later is EventHold: OFF in the same call. The fit is retention that should start on a business event rather than a calendar date, such as contract completion, account closure or a claim being resolved. AWS also suggests it for a configurable recovery window against ransomware or accidental deletion.

What Actually Happens When Someone Tries to Delete a Locked Object

The behavior depends on how the delete is issued, and it's not always the error people expect:

The second row is the surprising one. AWS states directly that retention periods and legal holds "don't prevent new versions of the object from being created, or delete markers to be added on top of the object." A simple delete hides the object from ordinary listings, but the locked version underneath is untouched and still recoverable by version ID. That's the mechanism doing its job, but it means a locked bucket can still look empty to an application that only sees current versions.

For governance mode, overriding takes two things at once: the s3:BypassGovernanceRetention permission and an explicit x-amz-bypass-governance-retention:true request header. AWS notes the S3 console includes that header by default, so a user with the permission can delete governance-locked objects straight from the console. Compliance mode has no bypass at all.

The Permissions Involved

Because Object Lock operations are separate S3 actions, you can split who may do what. AWS lists seven: s3:PutBucketObjectLockConfiguration and s3:GetBucketObjectLockConfiguration for the bucket-level setting, s3:PutObjectRetention and s3:GetObjectRetention for retention, s3:PutObjectLegalHold and s3:GetObjectLegalHold for legal holds, and s3:BypassGovernanceRetention for overriding governance mode. AWS says legal holds "can be freely placed and removed by any user who has the s3:PutObjectLegalHold permission," so it's worth granting that action narrowly, using the policy evaluation rules that decide how it combines with everything else.

Choosing Between Modes, Legal Holds and Variable Retention

AWS's own guidance maps to distinct situations:

Legal holds and retention are independent and can be combined: if a retention period expires while a legal hold is on, the object keeps its protection until the hold is removed, and removing a hold doesn't shorten a retention period that's still running. For regulated environments, AWS notes that S3 Object Lock "has been assessed by Cohasset Associates for use in environments that are subject to SEC 17a-4, CFTC, and FINRA regulations."

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.

Can I turn off Object Lock after enabling it on a bucket?
No. AWS states that after you enable Object Lock on a bucket, you can't disable it or suspend versioning for that bucket.

What happens if I delete a locked object without specifying a version?
S3 returns 200 OK and inserts a delete marker as the current version. The locked version underneath isn't deleted. A permanent delete that names the version ID returns 403 Forbidden instead.

Can I extend or shorten an Object Lock retention period?
You can extend it by submitting a new request with a later retain-until date. In compliance mode you can't shorten it or change the mode. In governance mode, users with s3:BypassGovernanceRetention can alter or remove the retention if they send the x-amz-bypass-governance-retention:true header.

What is variable retention in S3 Object Lock?
A retention type where you set an event hold and a duration instead of a fixed date. The object stays protected while the hold is on, and when you release it S3 sets the retain-until date to the release time plus the duration.

Is there any way to delete an object under compliance mode before it expires?
Per AWS's documentation, the only way is to delete the associated AWS account.

Does Object Lock stop someone from uploading a new version of a locked key?
No. Retention periods and legal holds protect the specific version they're placed on. A new upload creates a new version, and the protected version stays locked.

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
• AWS: Locking Objects with Object Lock
• AWS: Configuring S3 Object Lock