## TL;DR
Immutable backups in S3 come from S3 Object Lock with a compliance-mode retention period: nobody, not even the root account, can delete or overwrite a locked object before retention expires. Create the bucket with Object Lock enabled (it cant be added later), turn on versioning, set a default retention rule, and then actually test a restore. Compliance mode is the real protection; governance mode lets privileged users shorten retention.

```text
how to set up immutable backups in S3
```

## Use this when
- You need backups that survive an attacker with stolen admin credentials
- A compliance rule requires retaining data for N years with no early deletion
- You are building a 3-2-1 backup strategy and S3 is the offsite copy
- An audit asks for proof that backups cant be tampered with

## Not for
- Choosing what to back up or writing the backup script itself
- Cutting S3 storage costs (immutability usually raises them)
- Setting up replication or lifecycle rules in isolation

## Steps
1. Create a NEW bucket with Object Lock enabled. This setting can only be turned on at creation time, never added to an existing bucket. Use the console (Properties tab, Object Lock) or the create-bucket call with the object-lock flag, and pick a region close to your workloads.
   Expected output: the bucket exists and its properties show Object Lock as enabled.

2. Enable versioning on the bucket. Object Lock requires versioning; every backup write becomes a new version, so a corrupted or encrypted upload never destroys the good copy underneath.
   Expected output: bucket versioning status shows Enabled.

3. Set a default retention rule. In the bucket properties under Object Lock, add a default retention: choose Compliance mode (stronger, no early deletion by anyone) and a retention period that matches your policy, e.g. 30 days for operational backups or years for compliance archives.
   Expected output: new objects automatically carry a retain-until date in compliance mode.

4. Lock the bucket policy down. Write a bucket policy that denies s3:DeleteObject and s3:PutObjectRetention on the backup prefix except from your backup role, and enable MFA Delete for extra friction on version deletions. Keep a second admin path so you dont lock yourselves out of the policy itself.
   Expected output: attempts to delete a locked object return Access Denied, and only the backup role can write.

5. Run a backup into it and verify the lock. Upload a test object, then try `aws s3api delete-object` on it and try shortening its retention with a different role.
   Expected output: the delete fails with Access Denied and the retention date cannot be shortened outside compliance rules.

6. Test a full restore on a schedule. Restore to a scratch bucket or prefix, verify checksums, and document the runbook. An immutable backup you have never restored is a hope, not a backup.
   Expected output: the restored data matches the source checksums and the runbook has a real timestamp on it.

## Variant phrasings
- "S3 object lock compliance mode setup for ransomware protection"
- "how to make S3 backups undeletable"
- "WORM backups in AWS S3 step by step"
- "immutable backup bucket AWS"

## Edge cases and pitfalls
- Compliance mode retention cannot be shortened by anyone, including you: if you set 7 years by mistake, you are paying for 7 years. Start shorter, extend later.
- Object Lock works per object version, so a backup tool that rewrites the same key every run creates a new locked version each time; watch version sprawl and cost.
- MFA Delete only protects version deletes on top of Object Lock; it is not a substitute for the lock itself.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0kCt6UWgrfqQry0SM5xbrQ