What Is S3 Object Lock?

S3 Object Lock is a feature of Amazon S3 and S3-compatible object storage that prevents an object version from being overwritten or deleted for a fixed period of time — or indefinitely. It is the mechanism most organizations now use to make data genuinely immutable, and it is what turns ordinary object storage into a compliant WORM (write once, read many) archive.

Two design details give Object Lock its strength. Protection is applied to an individual object version rather than to a file name, and it is enforced by the storage platform rather than by the application that wrote the data. Because the rule lives below the application layer, a compromised backup server, a rogue script, or an administrator holding full credentials cannot quietly erase protected data.

How S3 Object Lock works

Object Lock depends on versioning. It can only be used on buckets that have S3 Versioning enabled, and it protects specific object versions. Object Lock can be switched on when a bucket is created, or added to an existing bucket once versioning is enabled — but the decision is permanent: after Object Lock is enabled, it cannot be disabled and versioning cannot be suspended.

With the bucket configured, retention is applied either per object at write time or through a bucket default retention setting expressed in days or years. From that point on, the platform changes how it answers write and delete requests:

• Overwrites become new versions. Writing to the same key does not replace the protected data; it creates an additional version alongside it.
• Version-specific deletes fail. A DELETE that names the locked version ID is refused with an access-denied error.
• Plain deletes create a delete marker. A DELETE that does not name a version succeeds and adds a delete marker, which becomes the current version.

That last behavior is the detail most often missed. Delete markers are not themselves protected by retention, so an object can appear deleted while every locked version underneath remains intact and fully recoverable — the object is hidden, not destroyed.

Compliance mode vs. governance mode

Object Lock offers two retention modes, and the choice between them is the single most consequential setting.

Compliance mode is absolute. No one can delete or overwrite a locked object version before its retain-until date — not an administrator, not the account owner, not the root user. The retention period can be extended, but never shortened or removed. This is the mode to use when an auditor needs assurance that records genuinely cannot be altered.

Governance mode applies the same protection by default, but leaves a deliberate escape hatch: a user who holds the bypass governance retention permission and explicitly asks to bypass the lock can shorten the retention period or delete the version. It suits teams whose main concern is accidental or malicious deletion rather than regulatory retention, and who need a controlled way to correct mistakes.

In practice, many organizations run governance mode in development and testing and reserve compliance mode for production and regulated data, where the inability to intervene is the point rather than a limitation.

Retention periods and legal holds

Object Lock provides two independent controls, and an object version can carry either, both, or neither.

A retention period sets a fixed retain-until date. It is usually applied by the application writing the data — backup software, for example, sets retention according to its own policy — or inherited from the bucket default. When the period expires, protection lapses and the version can be deleted under normal lifecycle policy.

A legal hold is a simple on/off flag with no expiry date. It stays in force until someone with the right permission explicitly removes it, which makes it the right tool for litigation, investigations, and audits where the required duration is unknown at the outset. Because the two controls are independent, a legal hold continues to protect an object version even after its retention period has run out.

Object Lock, WORM, and immutability

These three terms describe the same protection at different levels. Immutability is the property — data that cannot be changed. WORM (write once, read many) is the storage model that delivers it. Object Lock is the concrete API mechanism that applies WORM retention to individual objects in S3-compatible storage. Object Lock is how you switch WORM on; WORM is how you achieve immutability.

It is worth separating Object Lock from controls that resemble it but are not equivalent. Bucket policies and IAM deny rules can block deletion, but they are configuration — an administrator with sufficient privilege can change them. Object Lock in compliance mode cannot be changed by anyone. Snapshots, versioning alone, and air-gapped copies are complementary safeguards rather than substitutes: versioning preserves history but permits permanent deletion of versions, which is precisely the gap Object Lock closes.

S3 Object Lock and ARTESCA

Scality ARTESCA implements S3 Object Lock in both governance and compliance modes, with support for retention periods and legal holds, so backup and archive data written to ARTESCA is immutable from the moment it lands. Retention is enforced at the storage layer and cannot be switched off by a compromised administrator account.

Security is built in rather than bolted on: architectural immutability, a hardened operating system, and end-to-end cyber-resilience controls surround every object, extending Object Lock protection across the whole data path.

ARTESCA is validated with the leading backup platforms — including Veeam, Commvault, and Rubrik — which set Object Lock retention automatically as they write. The result is a compliant, ransomware-resilient immutable storage target that installs on standard servers.

S3 Object Lock FAQs

Does S3 Object Lock require versioning?

Yes. Object Lock only works on buckets with S3 Versioning enabled, because protection is applied to individual object versions rather than to file names.

Can S3 Object Lock be turned off?

Not at the bucket level. Once Object Lock is enabled, it cannot be disabled and versioning cannot be suspended. Individual retention set in governance mode can be bypassed by a specifically privileged user; retention set in compliance mode cannot be bypassed by anyone.

Can a locked object still be deleted?

A delete request naming the locked version ID is refused. A delete request without a version ID succeeds and adds a delete marker, so the object appears deleted while every protected version underneath remains intact and recoverable.

What is the difference between compliance and governance mode?

Compliance mode allows no exceptions and no shortening of retention, even for the account owner. Governance mode allows users holding the bypass permission to shorten retention or delete a locked version when they explicitly request it.

Is S3 Object Lock the same as WORM?

Object Lock is the mechanism; WORM is the model it implements. Enabling Object Lock retention is what makes S3-compatible storage behave as a WORM archive.