S3 Object Lock: retention modes, legal holds, and a safe test

S3 Object Lock protects a stored object version from deletion or replacement under configured retention rules. It is useful when a backup, record, or dataset must survive an accidental deletion or a compromised application account. The important detail is the version: locking yesterday's file does not stop someone from uploading a different file under the same name today.

This guide explains the controls and gives you a small governance-mode exercise to try in a disposable bucket. Start with synthetic files, record the expected results, and prove that you can retrieve the protected version before choosing a production retention policy.

What S3 Object Lock protects

Amazon S3 stores objects under keys, which often look like file paths. With S3 Versioning, each upload to the same key can create a separate version. A request for the key normally returns the current version; an older version remains addressable by its version ID.

Object Lock adds write-once-read-many, or WORM, protection to individual object versions. A retained version keeps its own protection even when a new version becomes current. Different versions of the same key can have different retention settings.

For example, an application writes reports/monthly.csv, then later uploads an incorrect replacement. Keeping the first version helps only if your recovery process can identify and read it. A filename alone is not enough evidence that the intended record remains available.

For a broader explanation of where S3 fits alongside disks and shared files, see our Amazon cloud storage guide.

Governance mode and compliance mode

The two retention modes differ in who can override protection:

• Governance mode: a suitably authorized user can bypass retention. AWS requires the s3:BypassGovernanceRetention permission and an explicit bypass request.
• Compliance mode: even the AWS account root user cannot delete the protected version or shorten its retention period while protection is active.

Use governance mode for the exercise below. Before adopting compliance mode, agree on the retention requirement and the consequences of keeping incorrect or unnecessary data. A product setting does not establish that your whole records process meets a legal requirement.

A governance test can be misleading if you run it with an administrator account. The S3 console automatically includes the bypass header for users with the required permission. AWS documents this behavior in its Object Lock considerations. Use a test role without bypass permission when checking whether ordinary deletion is blocked.

Retention periods, legal holds, and event holds

Fixed retention has a retain-until date. A legal hold is a separate control without a scheduled end; an authorized user must remove it. Both can protect the same version. Removing one does not remove the other.

The legal-hold API applies an ON or OFF setting to the selected object version. Treat permission to change that setting as a distinct operational responsibility. A hold without an owner or review process can leave data retained long after the original reason has ended.

AWS also supports variable retention through event holds. An event hold keeps the version protected; releasing it starts the configured retention duration. This differs from removing a legal hold, which ends that hold's protection immediately, although other retention settings may still apply. Check the current retention API fields before automating this behavior. The exercise uses fixed retention to keep the expected timeline simple.

Enable Object Lock with a clear scope

Object Lock requires versioning on an S3 general purpose bucket. AWS allows it on new and existing eligible buckets. Once enabled, you cannot disable Object Lock or suspend versioning for that bucket. Follow the current AWS configuration instructions.

Enabling the capability and protecting every intended version are separate steps. A default retention rule supplies settings for new uploads that do not specify their own retention. It does not retroactively apply that rule to all existing versions.

For existing data, identify the versions that need protection and apply retention explicitly. S3 Batch Operations can handle this at scale. Its manifest should specify version IDs when the target is a particular version; otherwise, the operation targets the latest version. Inspect a small result set before running a large job.

Why a locked object can appear deleted

In a versioned bucket, a delete request without a version ID normally creates a delete marker. A request to permanently delete a particular version supplies its ID. These are different operations, as the DeleteObject reference explains.

A delete marker can become current while the older protected version remains intact. Your application may then behave as though the file is missing. This is why “the object disappeared from the normal listing” and “the protected bytes were deleted” are different test results.

Record the bucket, key, and version ID together. During recovery, inspect versions and retrieve the intended one explicitly before making it current again.

A small governance-mode test

The following is a procedure to run in your own non-production environment. It is not a claim that a test has been performed on your AWS account. Use a new, clearly named test bucket and two tiny text files containing different, non-sensitive content.

1. Prepare the bucket and test identity

Keep public access blocked. Enable versioning and Object Lock, then configure a one-day default retention period in governance mode. AWS recommends allowing 15 minutes after first enabling versioning before issuing writes. Record the bucket name, Region, test owner, and planned cleanup time.

Use a role scoped to the test bucket. It needs the permissions required for the exercise, including reading versions, reading retention metadata, and attempting version deletion. Do not grant governance bypass. Check these permissions before the test: an unrelated permission denial would not prove retention works.

2. Upload two versions and inspect their settings

Upload the first file as object-lock-test.txt. Save its version ID. Upload the second file under exactly the same key and save that version ID too. Verify that both versions exist and inspect their retention mode and retain-until dates separately.

The AWS CLI retention command can make the version selection explicit. Replace the placeholders with your test values:

aws s3api get-object-retention --bucket TEST_BUCKET --key object-lock-test.txt --version-id FIRST_VERSION_ID

The expected result is governance retention with a future date. If retention metadata is missing, stop and fix the upload or default rule before testing deletion.

3. Test the protected version and the ordinary key separately

Using the test role, attempt to delete the first version by its version ID. While retention is active, the expected result is a denial. Confirm afterward that the version still exists and can be downloaded.

Next, delete only the ordinary key without selecting a version. With the relevant deletion permission, this can create a delete marker. Inspect the version list and confirm that the earlier protected version remains. Write down both outcomes; a successful marker creation is not a failed retention control.

4. Check a legal hold and the cleanup boundary

Through an appropriately authorized identity, place a legal hold on one test version. Verify its ON status. After the fixed retention period ends, the hold should still prevent deletion. Remove the hold only from that disposable test version, then confirm there is no remaining retention barrier before deleting it.

For cleanup, inspect all test versions and delete markers. Wait for each applicable retention period to end and remove only the test holds you created. Delete the empty test bucket afterward. If protection prevents cleanup, record the reason and schedule a follow-up instead of expanding permissions to force an immediate result.

Prove recovery as well as blocked deletion

Download the selected version and compare its content with the original test file. The GetObject API supports a version-specific request, which requires s3:GetObjectVersion. Archive storage classes may require a restore before the data can be read.

Include the identities and encryption keys needed for recovery. An intact encrypted object can become unusable if its key is lost. AWS explains the irreversible consequences of deleting a KMS key; retention of the object does not preserve the key for you.

Keep Object Lock within a broader cloud backup plan. Test the actual retrieval path, not just the presence of a lock indicator. Incorporate a 3-2-1 backup strategy so that versioned, locked objects complement copies on other media and locations. Our recoverability testing guide explains how to extend that check to an application and its dependencies.

Plan retention costs and lifecycle rules together

Stored versions consume capacity. S3 bills each version as a complete object, rather than storing only a difference between revisions. Frequent replacement of a large file can therefore create much more retained data than the current-version total suggests.

A Lifecycle expiration rule is not a promise that all versions disappear on that date. Current and noncurrent versions have different expiration behavior, and Object Lock prevents deletion of protected versions. Retention expiry makes deletion possible; it does not itself issue a deletion request.

Estimate current and noncurrent bytes, requests, retrieval, transfer, replication, and any applicable minimum storage duration. Use the current S3 pricing page for the chosen Region and storage class. Include a reminder to review outstanding holds and failed cleanup jobs.

Before using the policy in production

• Identify the records and versions that need protection, with a named policy owner.
• Choose the retention mode and duration deliberately; review who can bypass governance or change holds.
• Confirm new uploads receive the intended settings and existing versions are addressed separately.
• Test version-specific deletion, delete markers, retrieval, and cleanup using realistic permissions.
• Preserve recovery access and encryption-key availability for the whole retention period.
• Budget for retained versions and record when the policy will be reviewed.

Common questions

Is Object Lock the same as versioning?

No. Versioning retains separate revisions; Object Lock adds restrictions on deleting protected versions. Versioning is a prerequisite, but enabling it alone does not create a retention policy.

Can I turn Object Lock off later?

Not for an enabled bucket. A bucket's default retention rule and the protection on existing versions are separate settings. Changing a default does not remove locks already applied to versions.

Does S3 compatibility guarantee the same behavior?

No. Check the provider's supported retention operations, permissions, versioning behavior, and limitations. This guide describes Amazon S3. Do not assume another S3-compatible service implements every control described here.