S3 Object Lock: governance vs compliance mode explained

S3 Object Lock stops object versions being deleted or overwritten for a set time. In governance mode, users with a special permission can still change or remove the lock. In compliance mode, nobody can, including the account root user, until the retention period ends. It only works on buckets with versioning enabled.

What it is

AWS describes Object Lock as a write-once-read-many (WORM) model. You can use it to meet regulatory requirements that require WORM storage, or as another layer of protection against changes or deletion. There are two kinds of protection: retention periods and legal holds. A version can have either or both.

Governance vs compliance

• Who can delete early. Governance: Users with the BypassGovernanceRetention permission. Compliance: Nobody, including root.
• Can the mode or period be shortened. Governance: By those users. Compliance: No.
• Good for. Governance: Protecting against most users while keeping an escape hatch, and testing settings. Compliance: Records that must never be altered during the period.

AWS notes that the only way to delete an object under compliance mode before its retention date is to delete the associated AWS account. Treat that as a reason to test in governance mode first. AWS itself says governance mode can be used to test retention settings before moving to compliance mode.

Things that surprise people

• Locks apply to individual object versions. A new upload with the same key creates a new version, and the old protected version stays locked.
• A simple delete without a version ID adds a delete marker and returns 200 OK. A permanent delete with a version ID on a locked version returns 403.
• You can extend a retention period but not shorten it in compliance mode.
• The AWS console includes the bypass header by default, so a user with the bypass permission can delete governance locked objects from the console.

Using it for ransomware resilience

Object Lock gives a copy that an attacker with normal write credentials cannot erase. That fits the CISA advice on protecting backups. See offline encrypted backups checklist. CISA also says to use cloud immutability with caution, so test restores, and plan retention long enough to outlast a slow breach.

Setup checklist

1. Enable versioning and Object Lock on the bucket.
2. Start in governance mode with a short period, and confirm behavior.
3. Restrict who holds the bypass permission.
4. Move critical copies to compliance mode with a retention you can live with, including cost.
5. Add legal holds only through a documented process. See legal hold vs retention period.

Costs and trade-offs to weigh

Locking data means paying to store it for the whole period, even when you would rather delete it. Compliance mode makes that commitment hard to reverse, which is exactly the point and also the risk. Estimate storage cost for the full retention before you commit. Think about personal data too: a long immutable lock sits awkwardly with deletion requests, so keep locked content to what truly needs it, such as backups and audit records, and keep personal data retention aligned with your schedule. Finally, remember that Object Lock protects against deletion, not against someone with write access uploading bad data as a new version.

Quick check

Sources

• AWS: Locking objects with Object Lock
• CISA #StopRansomware Guide

Last reviewed: 19 October 2026.