Alright, let’s talk about MFA Delete. You know Multi-Factor Authentication from logging into your corporate VPN or your email, right? It’s that “something you have and something you know” principle. Well, AWS, in a rare moment of genuine security foresight, decided to apply that same concept to one of the most destructive operations in S3: permanently deleting object versions.

Here’s the deal: S3 Versioning is fantastic. It’s your “undo button” for the cloud. But that “undo button” itself has a big, scary, permanent “redo button” called DeleteObject or DeleteVersion. Anyone with the s3:DeleteObject permission can wipe out a version, and if they nuke all the versions of an object, it’s gone for good. MFA Delete adds a crucial second factor. Even if a bad actor gets hold of your access keys, or you accidentally grant too much permission to an IAM role (it happens to the best of us), they can’t just waltz in and delete your data without also physically possessing your MFA device.

How It Actually Works

Enabling it is a one-way street. You flip the switch, and from that moment on, any request to permanently delete a versioned object (or delete a version marker) will require two pieces of information:

  1. Your regular AWS access key and secret (the “something you know”).
  2. A six-digit code from your configured MFA device and the device’s serial number (the “something you have”).

Crucially, this only applies to permanent deletions. Operations like adding new objects, listing buckets, or even suspending versioning itself proceed without an MFA code. This is a smart design; it protects the crown jewels (your data) without adding friction to every single daily operation.

The Devil’s in the Details: Enabling and Using It

You can’t enable this via the cozy AWS Management Console. Of course not. That would be too user-friendly. You have to use the AWS CLI or API. It’s a bucket-level configuration.

First, let’s enable it. You’ll need your MFA device’s serial number, which you can find in your IAM settings. It looks something like arn:aws:iam::123456789012:mfa/YourUserName.

# Enable MFA Delete on your bucket
aws s3api put-bucket-versioning \
    --bucket my-ultra-secure-bucket \
    --versioning-configuration Status=Enabled,MFADelete=Enabled \
    --mfa "arn:aws:iam::123456789012:mfa/YourUserName 123456"

See that --mfa flag? You have to provide the serial number and the current code from your device, separated by a space, just to turn the feature on. This is AWS’s way of making sure you really, really mean it.

Now, let’s try to delete a version. You can’t just do a normal aws s3 rm. You have to use the lower-level delete-object command and, you guessed it, provide the MFA token again.

# This will FAIL without MFA
aws s3api delete-object \
    --bucket my-ultra-secure-bucket \
    --key sensitive-data.db \
    --version-id ABCDEFG1234567890abcdefg

# This is how you do it correctly
aws s3api delete-object \
    --bucket my-ultra-secure-bucket \
    --key sensitive-data.db \
    --version-id ABCDEFG1234567890abcdefg \
    --mfa "arn:aws:iam::123456789012:mfa/YourUserName 654321"

The Gotchas and Grey Areas

This is where I earn my keep. Listen up.

  1. The Root Account is a Sledgehammer: The IAM user who enables MFA Delete must be the root user or the bucket owner. An IAM user, even with full admin permissions, cannot do it. This is a good thing, but it’s a common head-scratcher.
  2. It’s Not for DELETE Markers: When you “delete” an object through the console or a simple aws s3 rm command, you’re not performing a permanent deletion. You’re adding a DELETE marker. This operation does not require MFA. MFA is only required when you go into the version list and permanently delete a specific version, including that DELETE marker itself. Wrapping your head around this distinction is critical.
  3. Lifecycle Policies are the Bypass: This is the big one. If you have a lifecycle policy that permanently expires noncurrent objects, S3 will execute that deletion without requiring an MFA token. The policy is considered an authorized, automated actor. So, if your goal is to prevent all permanent deletion, you must also guard your lifecycle policies with your life (or at least very strict IAM policies). Don’t set a lifecycle rule and then be shocked when your versions disappear on schedule.

So, Should You Use It?

Unequivocally, yes, for any bucket where data integrity is non-negotiable. Think source code archives, financial records, legal documents, or that embarrassing photo of you from the 2003 company party that you keep as leverage. The minor operational overhead of digging out your MFA device for the rare deletion is a trivial price to pay for the immense defensive boost it provides. It’s a classic example of AWS providing a powerful, granular security tool—if you’re willing to look past the CLI-centric awkwardness.