WORM (Write Once, Read Many) retention for S3 objects — required for some regulators and the simplest ransomware defense for cloud storage.

Modes¶

Mode	Behavior
GOVERNANCE	Locked; can be shortened/overridden by a special role
COMPLIANCE	Locked; cannot be shortened, even by root
LEGAL HOLD	Locked indefinitely until hold removed

Pick COMPLIANCE for true regulatory locks, GOVERNANCE for ransomware defense (admins can still recover in edge cases).

Enabling at bucket level¶

```bash cd s3 bucket object-lock enable --bucket acme-immutable

Object Lock can only be enabled at bucket-create time on existing data, NEW buckets¶

```

For existing buckets: create new bucket with lock enabled, copy data over with lock applied.

Default retention¶

bash cd s3 bucket object-lock default \ --bucket acme-immutable \ --mode COMPLIANCE \ --retention-days 2555

New objects inherit. Existing objects unaffected — apply explicitly:

bash cd s3 object-lock put --bucket acme-immutable --key path/to/object \ --mode COMPLIANCE --retain-until 2033-01-01

IAM separation¶

For GOVERNANCE mode: only principals with s3:BypassGovernanceRetention can shorten. Audit this permission tightly.

For COMPLIANCE mode: no principal can shorten. The bucket-level setting must be enabled at bucket-create time and cannot be disabled.

Cost implications¶

Immutability prevents you from deleting old data — bucket size grows with no escape until retention expires. Plan storage for the full retention window.

Archive-class immutable storage is the standard pattern for 7-year compliance.

Related¶

• Object Lock — Operation
• Object Lock — Troubleshooting
• S3 Object Storage

Putting a legal hold¶

bash cd s3 object-lock legal-hold put --bucket acme-immutable --key path/to/object --status ON

Legal holds are independent of retention. An object can have both — must be unblocked by both retention expiry and hold removal.

bash cd s3 object-lock legal-hold put --bucket acme-immutable --key path/to/object --status OFF

Querying lock status¶

```bash cd s3 object-lock get --bucket acme-immutable --key path/to/object

Returns: mode, retain-until-date, legal-hold-status¶

```

For bulk audit:

bash cd s3 inventory generate --bucket acme-immutable --include-object-lock

CSV output enumerates every object's lock state.

Metrics¶

Metric	Notes
objlock.locked_object_count	How many objects under lock
objlock.locked_bytes	Storage held by locked objects
objlock.legal_holds_count	Active legal holds
objlock.delete_attempts_24h	Attempts blocked by lock — investigate spike
objlock.governance_bypass_24h	Uses of bypass permission — audit each

Workflows¶

Compliance archive: lifecycle moves objects to Archive class + applies COMPLIANCE retention. Set-and-forget.

Ransomware-resistant backup: BaaS writes to a GOVERNANCE bucket with 30-day retention. Attacker with admin access can't delete recent backups.

Legal hold for litigation: discovery process tags objects with a hold; production team can't accidentally delete during normal lifecycle.

Lifecycle interaction¶

Lifecycle policies that would delete an object during its retention period are silently skipped. The object remains until retention expires; then the policy applies on the next sweep.

For retention-aware lifecycle, configure expiration longer than the retention period.

Related¶

• Object Lock — Administration
• Object Lock — Troubleshooting

"Cannot delete object: Object Lock is enabled"¶

Working as designed. Verify retention:

bash cd s3 object-lock get --bucket acme-immutable --key path/to/object

If retention hasn't expired: - GOVERNANCE mode + you have BypassGovernanceRetention — pass --bypass-governance-retention - COMPLIANCE mode — you cannot delete; wait for expiry - Legal hold ON — remove the hold first (if authorized)

Object Lock not honored after enabling¶

Symptom: enabled Object Lock at bucket level, but objects can still be deleted.

• Object Lock applies only to new objects + objects you explicitly lock
• Existing objects need: cd s3 object-lock put --bucket --key --mode --retain-until
• Check the bucket's default retention; new uploads inherit only if it's set

Cannot enable Object Lock on existing bucket¶

ERROR: Object Lock can only be enabled at bucket creation

Correct — existing buckets can't retroactively enable. Workaround: create new bucket with lock, copy objects over (with lock applied during copy).

Storage cost climbing forever¶

Immutable retention means deletion is impossible until expiry. The storage bill grows with each new retention period.

Mitigations: - Move old objects to Archive class (lower cost-per-GB) - Shorter retention if regulator allows - Lifecycle to Archive with COMPLIANCE retention applied to Archive copy

Bypass permission audit¶

Quarterly: who has s3:BypassGovernanceRetention?

bash cd s3 iam policy report --action s3:BypassGovernanceRetention

Should be a small number (1-3 senior engineers). Audit recent uses:

bash cd s3 audit query --action ObjectLockBypass --since 90d

Each use should have a documented reason.

Legal hold persists after intended removal¶

Status remains ON despite a legal-hold put --status OFF call:

• Multiple holds: legal holds can be cumulative across compliance officers. Check audit log for all hold-puts on the object.
• Lifecycle re-applied a hold (unusual)
• Permissions issue silently failed the status change (check audit log)

Restoration of accidentally-locked objects¶

If someone accidentally locked dev data with a long retention: you wait. The data sits there, billable, until retention expires. There's no override for COMPLIANCE mode.

This is why dev/staging buckets should never have COMPLIANCE mode enabled.

Related¶

• Object Lock — Administration
• Object Lock — Operation