- Without versioning (the default), each S3 object key maps to a single object. Uploading a new object with the same key or deleting an object permanently removes the previous content.
- Versioning protects against accidental deletions and overwrites by preserving prior object versions so you can retrieve or restore them later.
- Recover from accidental overwrites or deletions.
- Maintain an audit trail of object changes.
- Support application workflows that require historic object states.
Important: once you enable versioning on a bucket you cannot return it to an unversioned state; you can only suspend versioning. Suspending does not delete or consolidate existing versions.
How versioning works
When versioning is enabled, each object upload receives a unique version ID (a long opaque string). Multiple uploads for the same key create multiple versions instead of overwriting the previous one. The newest version is called the latest (or current) version and is returned when you request the object without specifying a version ID.
null version ID.
Delete behavior and delete markers
With versioning enabled, a delete operation that does not specify a version ID does not remove prior versions. Instead, S3 creates a special version called a delete marker. The delete marker becomes the latest version and makes the object appear deleted when requested without a version ID. The prior non-marker versions remain and can be restored by removing the delete marker (deleting that version).
If you delete a specific version by providing its version ID, that specific version is permanently removed (unless restored via backups outside S3). Deleting the delete marker itself restores the previous latest non-marker version to visibility.
Delete markers are themselves versions. Removing a delete marker (by deleting that version) restores the previous non-marker version as the latest visible object.
file1.txt has two stored versions of 10 GB and 15 GB, your storage billing will reflect 25 GB.
Keep these cost drivers in mind:
- Frequent updates to large objects produce many versions.
- Delete markers incur minimal storage, but previous full versions remain charged.
- Use lifecycle policies to transition or expire older versions to control costs.
null version ID (same as an unversioned bucket). Later re-enabling versioning causes new uploads to again receive unique version IDs.
Note: uploading an object with a null version ID will overwrite any existing null version for that key, but earlier non-null versions remain preserved and retrievable by version ID.
- Changing the bucket’s versioning state (enable/suspend) requires MFA.
- Deleting specific object versions or removing delete markers requires MFA.
- Plan versioning before enabling it—once enabled you cannot revert to unversioned.
- Combine versioning with lifecycle rules to transition older versions to cheaper storage classes or to expire unwanted versions.
- Use object lock or backups for additional immutability and retention guarantees where required.
- Monitor storage growth and tagging patterns to manage costs and governance.
- Versioning preserves every version of an object in a bucket, enabling retrieval and restoration of prior states.
- Versioning is disabled by default and must be enabled at the bucket level.
- Buckets have three states: unversioned (disabled), enabled, and suspended.
- Once enabled you cannot return to an unversioned state; you can only suspend versioning. Suspending keeps existing versions but stops generating new version IDs.
- You are charged for every stored version—costs can accumulate without lifecycle policies.
- MFA Delete adds an extra layer of protection for changing versioning state and deleting versions; it must be enabled via CLI/API with appropriate account privileges.
Be sure to plan versioning and lifecycle policies (such as object expiration or version cleanup) before enabling versioning, because once enabled it cannot be undone and you will be billed for all stored versions.