---
title: "Immutable backups with S3 Object Lock: what it protects and what it does not"
description: "Object Lock is the only thing on this list that stops an attacker with your credentials from deleting your backups. It also cannot be undone, which is the part people find out too late."
url: "https://saved.sh/blog/immutable-backups-object-lock"
date: "2026-08-08"
author: "saved.sh"
tag: "Security"
---

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 [#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.

<Figure caption="Object Lock sits below IAM. A permission grant cannot reach past it, which is exactly why it survives a credential compromise.">
  <RetentionLock />
</Figure>

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

| Mode           | Who can shorten the retention              | Use when                                                                                         |
| -------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------ |
| **Governance** | Anyone with `s3:BypassGovernanceRetention` | You want protection from mistakes and ordinary compromise, with a break-glass path               |
| **Compliance** | Nobody, including the account root and AWS | You need the guarantee to hold against an attacker who reached root, or a regulator asked for it |

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 [#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.

<Stats>
  <Stat value="0" label="Credentials that can delete a locked version" />

  <Stat value="0" label="Ways to shorten a compliance lock" />

  <Stat value="7" unit="years" label="A typo can commit you to paying for" />
</Stats>

The rule that follows: &#x2A;*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 [#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 [#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.

<Aside title="A safe way to start" tone="accent">
  Enable Object Lock in governance mode with a 7 day retain period on your backup
  bucket, and leave it there for a month while you watch storage growth. If the
  numbers look how you expect, extend. You will have closed the credential-deletion
  hole in an afternoon without committing to anything you cannot walk back.
</Aside>

## One caveat about enabling it [#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.