MFA Delete vs Object Lock

Both features protect versioned objects from being destroyed, and both require versioning on the bucket. They protect against different things.

MFA Delete

MFA Delete requires two forms of authentication — credentials plus a code from an MFA device — for two specific operations: permanently deleting an object version, and changing the bucket’s versioning state.

Only the bucket-owning account’s root user can turn MFA Delete on or off. Ordinary administrators cannot, however privileged their IAM policies.
It cannot be configured in the console at all. It is set through aws s3api put-bucket-versioning with the --mfa parameter, or the equivalent API call, passing the device serial number (or ARN, for a virtual device) and the current code.
It cannot be used together with lifecycle configurations.

The administrative overhead is therefore high, not low: every change means using root credentials with a physical or virtual MFA device on the command line, which is precisely the workflow that well-run accounts try to avoid. That, rather than any weakness in the mechanism, is the usual reason teams choose Object Lock instead.

What MFA Delete is good at is blunting credential compromise and accidental destruction on a bucket whose delete operations are rare and deliberate.

Object Lock

Object Lock enforces a write-once-read-many (WORM) model: an object version cannot be deleted or overwritten until its retention period expires, or ever, if a legal hold is in place. It must be enabled when the bucket is created.

Two retention modes:

Governance mode — a principal with the s3:BypassGovernanceRetention permission can shorten retention or delete the object. Suitable for protecting against mistakes while leaving a deliberate, audited escape hatch.
Compliance mode — nobody can delete the object or shorten its retention until the period ends. Not an administrator, not the account root user, not AWS support. This is the mode that satisfies regulatory retention requirements such as SEC Rule 17a-4.

Legal hold is separate from retention: it blocks deletion indefinitely, with no period attached, and is removed by a principal holding the right permission.

Object Lock cannot be switched off once a bucket is created with it, and a compliance-mode retention period cannot be shortened — that immutability is the point of it, and also the reason to be careful with the retention period chosen.

Choosing

	MFA Delete	Object Lock
Protects against	Credential compromise, accidental deletion	Deletion by anyone, including administrators
Configured by	Bucket owner’s root user only, CLI or API only	Any principal with the right permissions, at bucket creation
Can be turned off	Yes, by the root user	No
Works with lifecycle rules	No	Yes
Satisfies a compliance mandate	No	Yes, in compliance mode

For a regulatory retention requirement, Object Lock in compliance mode is the only one of the two that qualifies. For general protection of a small number of critical buckets in an account where root access is already tightly controlled, MFA Delete is a reasonable extra layer — as long as the team understands that every future change to it goes through root and the CLI.

Neither is a backup. Both protect what is in the bucket; neither helps if the bucket itself was never populated with the data that mattered.