Amazon S3 Object Lock protects specific object versions from overwrite or deletion using a write-once-read-many (WORM) model. Current S3 supports fixed or variable retention periods, governance and compliance retention modes, legal holds, bucket-level default retention, and Batch Operations for applying retention at scale. Object Lock operates only with S3 Versioning, so the immutable unit is an object version rather than an object key name.
Within AWS Architecture and Operations, immutability is a data-governance control, not simply a backup feature. It changes who can delete data, when capacity can be reclaimed, how legal evidence is preserved, and whether incident-response or ransomware recovery can trust a stored copy.
The existing S3 lifecycle design article provides the storage-lifecycle context. Object Lock must be coordinated with lifecycle rules rather than treated as an independent switch.
Object Lock protects versions, not key names
When a protected object is overwritten, S3 creates a new version while the protected previous version remains locked according to its retention configuration.
A delete marker can also be added above protected versions; the locked version still exists underneath and cannot be permanently deleted until policy allows it.
Operations must therefore reason in terms of version IDs when restoring, deleting, applying legal hold, or auditing retention.
Governance mode allows controlled administrative bypass
Governance mode protects object versions from ordinary deletion or shortened retention but lets a principal with s3:BypassGovernanceRetention override it when the request explicitly indicates bypass.
This is useful while testing retention policies or for operational environments that need an emergency exception path.
Because the S3 console automatically sends the bypass header when the user has permission, the safest policy is to grant bypass to a very small break-glass role rather than broad administrators.
Compliance mode is intentionally much stronger
In compliance mode, a protected version cannot be deleted or have its retention shortened by any principal, including the AWS account root user.
Retention mode cannot be changed during the period.
Use it only when the organization has confirmed the legal retention requirement, because an accidental multi-year compliance setting is not an IAM problem that an administrator can simply reverse.
Legal hold is independent from retention period
A legal hold has no automatic expiration and remains until explicitly removed by an authorized principal.
An object version can have a legal hold, a retention period, or both.
Removing the hold does not shorten a still-active retention period; both controls must permit deletion before the object version becomes removable.
Default bucket retention applies to new versions
A bucket can define default Object Lock retention so newly created object versions receive protection automatically.
Per-object retention settings can override the bucket default when supplied on PUT according to current S3 behavior.
Use bucket policy conditions such as the remaining-retention-days condition key to enforce minimum and maximum bounds so application callers cannot choose unsafe values arbitrarily.
Variable retention can start from an event hold
Current S3 Object Lock supports variable retention based on an event hold plus a duration. While the hold remains active, the retain-until date moves forward with time; when the event hold is released, the retain-until date becomes fixed based on the configured duration.
This fits business processes where the retention clock should begin after an event such as case closure, account termination, or regulatory milestone.
The event-release operation becomes a governed business action and should be auditable.
Retention can be extended but not shortened casually
Authorized principals can extend a fixed retain-until date by applying a later date.
Compliance retention cannot be shortened; governance retention can be shortened only through the explicit bypass mechanism and permission.
Lifecycle policies should never assume they can delete an object merely because it reached a storage-age threshold while Object Lock still protects the version.
Batch Operations can apply retention and legal holds at scale
S3 Batch Operations supports Object Lock retention actions over large manifests of object versions.
This is useful for retroactive governance, litigation response, or changing retention across existing datasets.
Test manifests and target version IDs carefully. Applying compliance retention to millions of wrong versions can create an irreversible storage and legal problem.
Replication needs Object Lock-aware configuration
When immutable data is replicated across Regions/accounts, replication configuration and permissions must preserve Object Lock metadata as required.
Disaster-recovery design should test that the replica version has the expected retention and can survive loss or compromise of the source account.
Multi-Region disaster recovery is relevant because immutable copies only improve resilience when the recovery account/Region remains independently accessible.
Object Lock is not the same as backup isolation
WORM protection blocks deletion and overwrite of protected versions, but the same account can still expose object contents to authorized readers, incur cost, or suffer policy mistakes elsewhere.
For ransomware and forensic resilience, combine Object Lock with cross-account replication, restricted KMS usage, MFA/identity controls, logging, and separate recovery administration.
Immutability protects data history; it does not automatically protect credentials or recovery operations.
Object Lock succeeds when retention is treated as irreversible policy
The mature design chooses governance versus compliance deliberately, protects bypass permissions, maps legal holds to a case process, uses bucket defaults and policy bounds, audits version-level state, validates replication, and tests restore procedures without attempting to delete protected evidence.
WORM storage is valuable precisely because it resists administrative convenience. The retention design should therefore be approved before data enters the immutable path.
Object Lock should be enabled and tested before the retention requirement becomes urgent. Buckets can be configured for Object Lock with versioning, and organizations should standardize the creation path through infrastructure-as-code. Emergency manual creation during an audit or ransomware event is the wrong time to discover a bucket was never prepared for the required WORM controls.
Default retention should align with data-classification policy. One bucket-level default is convenient, but files with materially different legal lifetimes may need separate buckets or explicit object retention. Avoid mixing seven-year regulatory records and short-lived operational logs in one immutable namespace unless the longer retention cost and deletion behavior are acceptable for both.
Governance mode works best as a proving ground. Teams can validate applications, lifecycle policies, replication, backup tooling, and legal workflows while a controlled break-glass path still exists. Once the process is proven, compliance mode can be used for data whose retention must be impossible to shorten administratively.
Legal-hold authority should be separated from ordinary storage administration. The role that can upload, restore, or manage lifecycle should not automatically be able to remove a litigation hold. Record case ID, requestor, approver, object versions, hold timestamp, and release evidence so the hold can be defended later.
Lifecycle transitions still work while versions are locked, subject to service rules, and can move immutable data into colder storage classes to control cost. Lifecycle expiration cannot delete a version until its retention and legal-hold protections allow deletion. This means retention design and storage-class design should be modeled together over the full compliance period.
Object Lock metadata should be included in inventory and restore tests. When an application restores or copies data, confirm whether the new version receives the intended retention and whether the recovery workflow preserves legal requirements. A recovered object that is writable/deletable may not satisfy the purpose of the immutable backup even if the bytes are correct.
Cross-account replication can strengthen ransomware resilience because the recovery copy can be administered under a separate security boundary. Use separate credentials, restricted KMS keys, and limited replication roles so compromise of the production account does not automatically provide the ability to delete or bypass retention in the recovery account.
Monitoring should distinguish retention-expired versions from still-protected versions and legal-hold inventory. Storage teams need to forecast when large immutable datasets become eligible for deletion so capacity/cost planning is not surprised by years of accumulated versions. Compliance teams need a separate view of which versions remain protected and why.
Object Lock should be paired with CloudTrail and S3 access logging or equivalent audit. Immutability prevents destructive operations, but the organization still needs evidence of attempted deletes, retention changes, bypass requests, and legal-hold changes. Alert on use of s3:BypassGovernanceRetention because legitimate use should be rare and highly controlled.
Bucket policies should protect retention configuration itself. Limit who can call PutObjectRetention, PutObjectLegalHold, PutObjectLockConfiguration, and bypass operations, and use conditions to constrain acceptable retention ranges. A storage administrator who can freely alter defaults can undermine the control even if existing compliance-mode versions remain protected.
Application writers should not need Object Lock administration permissions. Separate the role that PUTs business records from the role that changes retention configuration. When possible, let bucket default retention apply automatically so producers cannot accidentally omit or shorten protection on individual uploads.
Immutability exercises should test the unpleasant paths: attempt delete as the application role, admin role, and break-glass role; restore a prior version; place/release a legal hold; replicate to the recovery account; and wait through a small test retention window. A control is easier to trust after the organization has observed exactly which operations fail and which succeed.
Retention reports should reconcile legal policy with actual object versions. A bucket can contain several versions of the same key with different retention dates or modes, so auditors need version-level evidence rather than a simple bucket flag. Periodically export inventory or API data that shows retention, hold status, version ID, storage class, and expected eligibility date for deletion.
Do not use Object Lock as the only defense against compromised credentials. An attacker who cannot delete compliance-locked data may still encrypt new versions, exfiltrate readable content, or attack other systems. Pair immutability with least privilege, anomaly detection, cross-account recovery, and incident isolation so the immutable copy is one part of a layered recovery architecture.
