In Amazon S3, you can upload objects (files), choose a storage class, define who can access the file, configure automatic deletion, and more. Billing is hourly, and you can delete any object at any time to stop paying for its storage.
One feature AWS introduced is Object Lock — a mechanism that allows you to prevent objects from being deleted or overwritten. It’s designed to protect data meant for long-term retention, whether for compliance or archival purposes, from being accidentally or maliciously removed.
When creating a bucket, you can choose an Object Lock Retention Mode, which dictates how AWS will restrict object deletions:
- Governance mode — Objects are write-protected, but users with special permissions can override or remove the lock.
- Compliance mode — Objects are completely immutable for the set retention period. No one, not even the root account user or AWS support, can delete them during this time.
In both options, you can define a retention period between 1 day and 100 years, counted individually for each object from when it’s uploaded to S3.
Once Object Lock is enabled on a bucket, you can define each object's lock mode and retention period when you upload an object. If you don't specify these settings during upload, the default settings will apply.
If you change the default settings later, they will only affect new objects — existing objects will retain the lock configuration they were uploaded with.
Let’s focus on Compliance mode:
If you enable it, once an object is uploaded, no IAM Role or user — not even the root user — can delete the objects until the retention period ends. Not even AWS support can help you delete it prematurely.
You will get the following error:
“Access Denied because object protected by object lock.”
So why would you want to block it?
To reduce the damage in the event of a compromised AWS account.
Let me explain — there are three common patterns attackers follow when gaining access to an AWS account:
- Ransom & Destruction: Encrypt backups, demand ransom, and delete resources to cause chaos.
- Crypto mining: Launch expensive GPU-compute instances across all available regions to mine cryptocurrency.
- Financial drain: Provision costly resources like metal instances and massive EBS volumes, or purchase Redshift Reserved nodes to rack up charges.
One particularly nasty trick an attacker might use is to create an S3 bucket with Object Lock for a long term in Compliance mode and upload huge files using zombie EC2 instances or even content that is illegal to hold.
Later, during a cost review or anomaly detection, you may discover a bucket containing massive amounts of undeletable data, costing thousands to tens of thousands of dollars per month, with no way to remove it.
So, how do you delete a bucket with objects protected by Compliance mode?
You can’t.
The only way is to close the entire AWS account with all its resources, which is a major pain, especially for production environments.
You’ll need to migrate your entire workload to a new AWS account — a process that can take weeks or even months, similar to a full environment migration.
How do you block it?
With Resource Control Policies (RCP) — a feature in AWS Organizations that lets you enforce policies across accounts in your organization (except the management account) for resources such as S3 Buckets.
You can create a resource policy that denies any attempt to enable Object Lock(unfortunately, it’s not possible to limit it only to Compliance Mode). If someone tries to apply it, they’ll receive an Access Denied error.
Pro tip: You can also allow only specific users (e.g., the security team) to bypass the restriction, while blocking everyone else. That way, you retain control without exposing the account to unnecessary risk.
Here’s an example RCP that blocks the use of Compliance mode entirely, for existing and new buckets:
I applied the policy, created a new bucket, and when I tried to enable Compliance mode, I got the following error:
Final thoughts:
If you’re serious about minimizing long-term financial damage from misconfigurations or unauthorized access, I strongly recommend applying this policy.
By the way, Compliance mode isn’t limited to S3 — it also exists in:
- EBS Snapshots — backups of EC2 volumes (disks)
- AWS Backup Vault— AWS Backup service
You should consider blocking those as well, depending on your risk posture.
Discover even more helpful resources by visiting us at doit.com/services — your next step to success awaits!