S3 Object Lock in Compliance Mode is actually less about immutability and more about predictable immutability.
Let’s see it in action. Imagine you’re storing financial records that need to be tamper-proof for a decade.
# Create a bucket with Object Lock enabled
aws s3api create-bucket \
--bucket my-regulated-data-bucket \
--create-bucket-configuration LocationConstraint=us-east-1 \
--object-lock-enabled-for-bucket
# Upload a file with a 10-year retention period in compliance mode
aws s3api put-object \
--bucket my-regulated-data-bucket \
--key financial_report_2023.pdf \
--object-lock-mode COMPLIANCE \
--object-lock-retain-until-date 2033-10-27T00:00:00Z
# Attempt to delete the object before the retention period expires
aws s3api delete-object \
--bucket my-regulated-data-bucket \
--key financial_report_2023.pdf
The delete-object command will fail with a PreconditionFailed error, specifically stating the object is locked in compliance mode. You can’t even override this as an AWS root user.
This feature directly addresses the stringent requirements of regulations like SEC Rule 17a-4(f), FINRA Rule 4511, and HIPAA, which mandate that certain types of data be retained in an unalterable format for specific periods. Object Lock, when configured with a retention policy, ensures that once an object is written, it cannot be modified or deleted until its retention period expires. Compliance mode is the stricter of the two modes (the other being Governance Mode), as it prevents even the root AWS account from overriding the lock.
The core mechanism relies on two key settings applied at the object level: ObjectLockMode and ObjectLockRetainUntilDate. When you set ObjectLockMode to COMPLIANCE, you’re telling S3 that this object is subject to a strict, unchangeable retention policy. The ObjectLockRetainUntilDate defines the exact moment in time when S3 will permit operations that would otherwise be forbidden, such as deletion or overwriting.
You can also apply a default retention policy to a bucket. This means any object uploaded to that bucket will automatically inherit the policy unless a different, more restrictive policy is explicitly set during the upload.
# Set a default retention policy for the bucket
aws s3api put-object-lock-configuration \
--bucket my-regulated-data-bucket \
--object-lock-configuration '{
"ObjectLockEnabled": "Enabled",
"Rule": {
"DefaultRetention": {
"Mode": "COMPLIANCE",
"Days": 3650
}
}
}'
This configuration ensures that any object uploaded to my-regulated-data-bucket will be protected by a 10-year compliance-mode lock, even if no specific lock parameters are provided during the put-object operation.
The real magic, and the part that often trips people up, is understanding how versioning interacts with Object Lock. Object Lock is built on top of S3 Versioning. When you enable Object Lock for a bucket, you must also enable versioning. Each version of an object gets its own independent Object Lock settings. This means you can’t just "delete" an object and expect it to be gone forever if it has multiple versions, each with its own retention policy. Deleting an object in compliance mode only adds a delete marker, but the underlying object versions remain locked until their respective retention periods expire. To truly remove data, you have to wait for all versions to pass their RetainUntilDate.
The most surprising truth is that Object Lock in Compliance Mode doesn’t technically make data immutable. It makes it predictably unmodifiable by enforcing a timer. If you misconfigure the RetainUntilDate and set it too short, or if you decide you absolutely need to remove data early for a critical, documented reason (which is almost never the case for regulated data), you can’t. The system is designed to prevent even emergency overrides. This lack of flexibility is its primary strength for regulatory compliance but also its most significant operational constraint.
The next hurdle you’ll encounter is managing the lifecycle of these locked objects, particularly when dealing with large datasets and the need for eventual data purging after compliance periods have ended.