What Is S3 WORM Storage? Object Lock Modes and Setup

S3 WORM storage is Amazon S3 Object Lock: a write-once-read-many setting that stops an object version from being deleted or overwritten until its retention date passes. In compliance mode, AWS says no user can remove it, not even the root user. That is why backup teams use it against ransomware.

TL;DR:

• S3 Object Lock is AWS's WORM feature. A locked object version can't be deleted or overwritten until its retention period ends, and S3 enforces that itself, not an IAM policy someone could edit.
• Compliance mode has no exception: a locked version "can't be overwritten or deleted by any user, including the root user." Governance mode lets users with a special permission make exceptions.
• Object lock is built on versioning. A legal hold adds protection with no end date, and variable retention starts the clock on a business event.
• AIOZ Storage doesn't list versioning or object lock among its features (docs checked Oct 28, 2026), so keep any WORM copy with a provider that documents it.

Updated Oct 28, 2026: definition-first opening, question headings, a labelled diagram of the three protection types, and a new section on how AIOZ Storage handles deletes.

What Is S3 WORM Storage?

WORM means write once, read many: you can read the data as often as you like, but nobody can change or remove it for a set period. On Amazon S3 the WORM feature is called Object Lock, and AWS says it works with versioning "to prevent locked object versions from being permanently deleted (accidental or intentional) or overwritten."

The words "accidental or intentional" matter. A permissions policy stops honest mistakes, but anyone who controls the account can rewrite it. Object Lock is enforced by S3 itself, so even an attacker with valid admin credentials can't remove a locked version early. If your threat model includes a stolen root key, that difference is the reason to use it.

Object Lock Is Built on Versioning

Object lock isn't a separate switch bolted onto a bucket. AWS puts it plainly: "With S3 Object Lock, S3 Versioning is automatically enabled, and these features work together to prevent locked object versions from being permanently deleted."

The dependency makes sense once you see what gets protected: object lock doesn't stop you from writing a new version of a key. It protects one existing version, which only means something when several versions of a key can sit side by side. If that model is new to you, how S3 object versioning works covers version IDs and delete markers.

What Is the Difference Between Compliance and Governance Mode?

Compliance mode leaves no exception. In AWS's words, "A protected object version can't be overwritten or deleted by any user, including the root user in your AWS account." Once it's set, "you cannot change the retention mode, and you cannot shorten the retention period." AWS adds one blunt note: the only way to delete an object under compliance mode before its retention date is to delete the associated AWS account.

Governance mode gives 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." The difference is a deliberate escape hatch, since "you can still grant some users permission to alter the retention settings or delete the object if necessary."

So choose by who you need to stop: compliance mode is for rules that must hold against every insider, and regulatory retention is the standard case. Governance mode fits data that needs strong protection plus a documented, permissioned way to fix a mistake.

Legal Hold: Protection With No End Date

Object lock has a second, independent mechanism. AWS says "a legal hold remains in place until you explicitly remove it," and "legal holds are independent from retention periods." A retention period is a countdown with a known end date, while a legal hold has no end date until someone with permission lifts it. That suits open-ended situations like active litigation, where you can't know in advance when the protection should stop.

How to Turn On Object Lock for a Bucket

You have to enable Object Lock on a bucket before any object in it can be locked, and versioning must be on too. On a new bucket it takes 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 you run either one: "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." One more restriction is easy to miss. A bucket with Object Lock can't be the destination for server access logs, so keep your logs in a separate bucket, as S3 server access logging vs CloudTrail explains.

Retention Periods in Practice

A retention period belongs to one object version, not to a key and not to the whole bucket. That has a few consequences you should plan for:

• A default rule is only a default. When you upload a version with its own mode and period, those settings override the bucket's default.
• Different versions of one key can have different periods. In 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 creates a new version with 60 days, while the older version keeps its schedule and becomes deletable in 15 days.
• Under compliance mode you can extend a period but not shorten it. To extend, send 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 for Event-Based Deadlines

Fixed retention is the classic type: you give a retain-until date up front. AWS's documentation now describes a second type, variable retention, which 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 keeps moving: AWS describes it as the current time plus the duration. Two safeguards stop anyone from weakening it. Decreasing the duration never sets an earlier date than the current one. You can also add an explicit minimum retain-until date, so the object stays protected until at least then even if the hold ends 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}}'

To release it later, you send EventHold: OFF in the same call. Variable retention fits deadlines tied to a business event rather than a calendar date, such as contract completion, account closure or a resolved claim. AWS also suggests it for a configurable recovery window against ransomware or accidental deletion.

What Happens When You Delete a Locked Object?

It depends on how you send the delete, and the result isn't always the error people expect:

The second row surprises most people. AWS says 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 you can still recover it by version ID. So a locked bucket can look empty to an application that only reads current versions.

To override governance mode, you need two things at once: the s3:BypassGovernanceRetention permission and the x-amz-bypass-governance-retention:true request header. AWS notes that the S3 console sends that header by default, so a user with the permission can delete governance-locked objects straight from the console. Compliance mode has no bypass for any user.

The Seven Object Lock Permissions

Object Lock operations are separate S3 actions, so you can split who may do what. AWS lists seven:

• s3:PutBucketObjectLockConfiguration and s3:GetBucketObjectLockConfiguration for the bucket setting
• s3:PutObjectRetention and s3:GetObjectRetention for retention
• s3:PutObjectLegalHold and s3:GetObjectLegalHold for legal holds
• 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." Grant that action narrowly, and check the policy evaluation rules that decide how it combines with your other policies.

Choosing a Mode, a Legal Hold or Variable Retention

AWS's own guidance maps each option to a situation:

You can combine legal holds and retention. If a retention period expires while a legal hold is on, the object stays protected 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 WORM Storage Matters for Ransomware

Modern ransomware goes after backups as well as production data. A backup that is a separate copy but still writable from a compromised environment can be encrypted or deleted along with the original. That is why the 3-2-1-1-0 backup rule asks for one copy that is offline or immutable.

Compliance mode answers that threat directly. An attacker holding valid root credentials still can't delete or overwrite a locked version before its retention period ends. A permissions-only defense can't promise that, because permissions are exactly what a stolen credential already has.

How AIOZ Storage Handles It

AIOZ Storage is S3-compatible, but it doesn't offer object lock or versioning today. Object lock depends on versioning, so the missing versioning also rules out object lock. Here is what AIOZ Storage does offer that touches the same problem:

• Durability. AIOZ Storage protects each object with Reed-Solomon erasure coding across nodes. That guards against failed nodes, not against a delete you or an attacker sends.
• Permissions per grant. Each access grant carries a permission level of All, Read, Write, List or Delete. If you give a backup reader a grant without Delete, that credential can't remove objects.
• Expiring credentials. A grant ends after 24 hours, 1 week, 1 month, 6 months or 1 year, which limits how long a leaked key stays useful.

Grants are still permissions, though, so they carry the weakness described above: whoever controls the account can issue a new grant with Delete. A quick way to confirm your copies are still there is the listing command from the AIOZ CLI guide, run with a read-and-list grant:

aws s3 --endpoint-url https://s3.aiozstorage.network ls s3://bucket-name

What the docs don't cover yet (all concept, tutorial and SDK pages read Oct 28, 2026):

• Object versioning, version IDs or delete markers
• Object lock, retention modes or legal holds
• Whether a grant with Write but no Delete can overwrite an existing key (the docs define Write as permission "to write into a bucket")

If a regulation or your ransomware plan needs compliance-mode retention, keep that copy with a provider that documents object lock, and use AIOZ Storage for copies that don't need it. To scope a grant to only the permissions a job needs, follow the Manage Access Grants guide.

Frequently Asked Questions

What is S3 WORM storage?
It is Amazon S3 Object Lock, a write-once-read-many feature. It blocks a specific object version from being deleted or overwritten for a set retention period, and S3 enforces it rather than a permissions policy.

What's the difference between compliance mode and governance mode?
In compliance mode, no user, including the root account, can delete the version, overwrite it or shorten its retention. Governance mode gives the same daily protection but lets users with s3:BypassGovernanceRetention make exceptions.

Does object lock require versioning?
Yes. AWS enables S3 Versioning automatically with Object Lock, because the lock protects one specific version of an object.

What is a legal hold, and how is it different from a retention period?
A retention period has an end date and expires on its own. A legal hold has no end date and stays until someone with s3:PutObjectLegalHold removes it.

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

What happens if I delete a locked object without a version ID?
S3 returns 200 OK and adds a delete marker as the current version. The locked version underneath stays. A permanent delete that names the version ID returns 403 Forbidden.

Can I extend or shorten an Object Lock retention period?
You can always extend it with a later retain-until date. In compliance mode you can't shorten it or change the mode; in governance mode, users with the bypass permission can, if they send the bypass header.

What is variable retention in S3 Object Lock?
A retention type that uses an event hold and a duration instead of a fixed date. When you release the hold, 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?
According to AWS, the only way is to delete the associated AWS account.

Does AIOZ Storage support object lock?
No. AIOZ Storage doesn't offer versioning or object lock as of Oct 28, 2026. It protects objects with erasure coding and lets you limit each access grant's permissions, but neither makes data immutable.

Related Reading

• What Is S3 Object Versioning and How Does It Work? - the mechanism object lock is built on.
• 3-2-1 Backup Rule Explained, and Why 3-2-1-1-0 Exists - where the immutable copy fits in a backup plan.
• How to Use AIOZ Storage Effectively: A Practical Checklist - naming keys and scoping grants when you have no versioning.
• AIOZ Storage for Dataset and Model-Output Pipelines - the same no-versioning limit, for dataset and model-output workloads.
• What Is Data Replication in a Distributed System? - protection against hardware failure, which is a different problem from a stolen account.
• SSE-S3 vs SSE-KMS vs SSE-C - encryption, an independent layer that applies whether or not an object is locked.

References

• AWS: S3 Object Lock
• AWS: Locking Objects with Object Lock
• AWS: Configuring S3 Object Lock
• AWS: Managing Object Lock
• Scality: S3 Object Lock - Immutability and WORM
• AIOZ Storage Docs: Permissions