A compliance team requires that audit logs in S3 cannot be deleted by anyone — including an administrator whose credentials are stolen — for seven years. How would you build that on S3, and what are the tradeoffs of the mode you choose?

## Why versioning is not the answer on its own Versioning makes deletion *recoverable*, not *impossible*. A `DELETE` without a version ID only inserts a delete marker — but a principal with `s3:DeleteObjectVersion` can enumerate versions and remove each one permanently. In a credential-compromise or malicious-insider scenario, that is exactly what happens. IAM can narrow who holds that action, and MFA delete can gate it further, but both are still *policy*, and policy is editable by whoever can edit policy. Object Lock is different in kind: it is enforced by the storage service below IAM, so no policy edit unlocks it. ## The building blocks **Prerequisite: versioning enabled.** Object Lock protects specific object *versions*; without version IDs there is nothing to protect. Object Lock was historically only settable at bucket creation; AWS now also supports enabling it on an existing bucket that has versioning on. **Retention modes.** Each protected version carries a mode and a retain-until date: - **GOVERNANCE** — the version cannot be deleted or its retention shortened by ordinary principals, but a principal holding `s3:BypassGovernanceRetention` can override it by sending the `x-amz-bypass-governance-retention: true` header. This is the mode for internal protection against accident, and the mode you pilot with. - **COMPLIANCE** — no principal can delete the version or shorten the retain-until date before it expires. Not an administrator, not the account root user, not AWS Support. Retention can only be *extended*. **Legal hold.** A separate boolean on a version, with no date attached. While it is on, the version cannot be deleted, regardless of any retention period; it is removed by a principal with `s3:PutObjectLegalHold`. Use it for the litigation case where the end date is unknown. **Default retention.** A bucket-level rule that stamps a mode and a duration (`Days` or `Years`) onto every new object version, so applications do not have to remember per-request headers. ```bash aws s3api put-object-lock-configuration --bucket audit-logs \ --object-lock-configuration '{"ObjectLockEnabled":"Enabled", "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Years":7}}}' ``` Per-object overrides use `--object-lock-mode`, `--object-lock-retain-until-date` and `--object-lock-legal-hold-status` on `PutObject`, gated by `s3:PutObjectRetention` and `s3:PutObjectLegalHold`. ## What Object Lock does *not* stop This is where candidates go wrong. Object Lock prevents deletion of a *version*; it does not freeze the *key*. - New versions can still be PUT to the same key. The protected version stays, immutable, underneath. - A version-less `DELETE` still succeeds and inserts a delete marker. The key reads as 404 while every locked version remains intact and recoverable. That is intentional and does not violate the lock. - The **bucket cannot be deleted** while it holds locked versions, since bucket deletion requires an empty bucket. In compliance mode that means the bucket is pinned for the full retention. - Lock does not encrypt, does not authenticate readers, and does not stop copying data out. ## The tradeoff to say out loud Compliance mode converts a storage decision into a **financial and operational commitment**. Seven years of retention on a mis-sized ingest — a debug log accidentally routed into the bucket, a retain-until date computed with the wrong unit, a runaway producer — is seven years of storage you must pay for and cannot delete. There is no support ticket that undoes it. The mitigations are all upstream of the lock: 1. Pilot the whole pipeline in **governance mode**, with the bypass permission held by exactly one break-glass role, and switch the default to compliance only once volumes and dates are proven. 2. Put the locked data in its **own bucket, and preferably its own account**, so a mistake in one workload cannot pin unrelated data, and so a compromised administrator in the producing account cannot reach the bucket's configuration. 3. Combine with a **lifecycle transition** to a cheap archival storage class so seven years of immutable data is not seven years at Standard prices; transitions change storage class, not content, so they coexist with retention. 4. Replicate the locked bucket to a **second account or region** — S3 Replication supports objects protected by Object Lock — so durability does not depend on one account staying healthy. ## Where MFA delete fits MFA delete is the older, weaker sibling: configured on the same `PutBucketVersioning` call, it requires the bucket owner's **root** user credentials plus an MFA token to permanently delete a version or change the bucket's versioning state. It is genuinely strong against stolen IAM credentials, but it forces root usage into a routine operation, it can only be configured via the CLI, SDKs or REST API rather than the console, and S3 does not support lifecycle configuration on a bucket with MFA delete enabled — so noncurrent versions cannot be expired automatically. For a modern seven-year retention requirement, Object Lock in compliance mode is the answer, and MFA delete is at most a supplementary control on a small, sensitive bucket.