S3 bucket file versioning keeps multiple versions of the same object in one bucket, so an overwrite does not destroy the old file. When versioning is enabled, each new upload of the same key gets a unique version ID, and deleting a file usually adds a delete marker instead of permanently erasing the object.

How it works

  • Before versioning: uploading a file with the same name replaces the old one.
  • After versioning is enabled: every upload creates a new version of that file.
  • Retrieval: if you request the file without a version ID, S3 returns the latest current version.
  • Deletion: a normal delete hides the object by creating a delete marker, which makes it look deleted.
  • Recovery: you can restore an older copy by removing the delete marker or explicitly requesting an older version ID.

Important details

  • Versioning is configured at the bucket level, not per file.
  • A bucket starts unversioned by default, and versioning must be explicitly enabled.
  • Once enabled, a bucket cannot go back to fully unversioned; it can only be suspended later.
  • Existing objects are not automatically rewritten, but future changes to them get version IDs.

Simple example

Imagine you upload report.pdf three times:

  1. First upload creates version v1.
  2. Second upload creates v2.
  3. Deleting report.pdf adds a delete marker, so the file looks gone.
  4. If you remove that delete marker, v2 becomes visible again.

Why people use it

Versioning is useful for protecting against accidental overwrites, accidental deletions, and application bugs. It is especially helpful when you need rollback history or a safety net for important files.

TL;DR

S3 versioning is basically file history for a bucket: uploads create new versions, deletes create markers, and old versions stay recoverable unless you permanently delete them by version ID.