Immutable backups with S3 Object Lock: what it protects and what it does not

Ransomware operators learned years ago that encrypting production is only half a job. The other half is deleting the backups first, and they do it with the credentials they already found on the machine they already own.

Against that specific attack, almost every backup control fails. Versioning fails. Lifecycle rules fail. Cross-region replication fails. All of them are operations your credentials are permitted to perform, which means they are operations the attacker is permitted to perform.

S3 Object Lock is the exception, because it is enforced below the permission layer.

What Object Lock actually does

Object Lock puts a retain-until date on an object version. Until that date passes, no credential can delete that version. Not the one that wrote it, not an administrator, not the account root. In compliance mode, not AWS support either.

Two modes, and the difference matters more than the documentation suggests:

Governance mode is the right default for most teams. Compliance mode is a one-way door, and people underestimate how one-way.

The part people find out too late

You cannot shorten a compliance-mode lock, and you cannot delete the objects, and you keep paying for them the entire time.

The realistic incident is not an attacker. It is a misconfiguration. Someone sets a seven year compliance lock on a bucket receiving hourly backups of a 200 GB database, and discovers three weeks later that the organisation has committed to storing several petabytes for seven years, with no mechanism on earth to stop it. The bucket cannot be emptied. The account cannot be closed with objects under compliance lock.

The rule that follows: start in governance mode with a short window, and lengthen it deliberately once you know your real data volume. Going from 7 days to 30 is easy. Going from 7 years to 30 days is impossible.

What Object Lock does not protect you from

It is worth being precise, because "immutable" gets sold as though it solves backups generally.

• It does not stop an attacker writing garbage. They cannot delete your good version, but they can write a thousand useless new ones and inflate your bill.
• It does not detect a bad backup. A truncated dump locked for a year is a truncated dump for a year.
• It does not help if the bucket itself goes. Account closure, region loss, and provider failure are outside its scope entirely.
• It does not make a restore work. Nothing about immutability tests whether the artifact opens.

Object Lock answers exactly one question: can someone with my credentials delete this. That question is worth answering, and it is one question.

Why we treat protection and cleanup as separate settings

Most tools bundle immutability and expiry into a single "retention" number. We split them, and the reason is that they are opposites.

Expiry is what we delete for you. It is a cleanup policy, it bounds your storage bill, and it is the thing you tune.

A lock is what nobody may delete, us included. It is a protection policy, it is a promise to the artifact, and it should be boring and rarely changed.

Collapsing them means every time you want to keep less, you weaken your ransomware posture, and every time you want stronger protection, your bill grows in ways you did not intend. Splitting them means you can say "expire after 90 days, and for the first 30 nobody can touch it", which is what people actually want and cannot easily express when it is one field.

One caveat about enabling it

Object Lock can only be enabled on a bucket at creation time, and it requires versioning. If your backup bucket already exists without it, you are creating a new bucket and pointing your backups at it. Plan for that, because discovering it mid-incident is a bad time to learn it.