S3 Versioning
A bucket-level Amazon S3 feature that preserves every version of every object — every PUT or DELETE creates a new version rather than overwriting or removing the previous one. Each version gets a unique **VersionId**; DELETE operations create a special **delete marker** rather than actually erasing data. The previous (non-current) version remains in storage and is recoverable until a lifecycle policy or explicit version-specific delete removes it. Versioning state is per-bucket: once enabled, only "suspended" is possible (you can't return to the never-enabled state).
Definition
A bucket-level Amazon S3 feature that preserves every version of every object — every PUT or DELETE creates a new version rather than overwriting or removing the previous one. Each version gets a unique **VersionId**; DELETE operations create a special **delete marker** rather than actually erasing data. The previous (non-current) version remains in storage and is recoverable until a lifecycle policy or explicit version-specific delete removes it. Versioning state is per-bucket: once enabled, only "suspended" is possible (you can't return to the never-enabled state).
The original S3 semantics make PUT a destructive write — accidentally overwriting an object means the prior bytes are gone. Versioning is the simplest mitigation: turn destructive writes into non-destructive ones, then let lifecycle rules expire noncurrent versions on whatever schedule matches the operator's recovery-point-objective. The cost trade-off is direct: every version is billed at the same per-GB rate as the current object, so a frequently-updated config file can multiply storage cost by the number of versions retained.
Accidental-overwrite recovery for production buckets, ransomware mitigation in conjunction with Object Lock + MFA Delete, point-in-time recovery for application state stored in S3, audit-trail use cases where every change to a JSON config / spec file is preserved, and as the substrate for higher-level replication features (versioning is a prerequisite for [S3 Replication](/node/s3-replication)).
Recent developments
- MFA Delete is root-only and CLI-only — no console UI. MFA Delete can only be enabled or disabled by the bucket owner using the root account, and you cannot enable MFA Delete from the AWS Management Console — you must use AWS CLI or the API. Per AWS docs — MultiFactorAuthenticationDelete.
- Hard limitation: MFA Delete is incompatible with lifecycle configurations. If MFA Delete is enabled, lifecycle rules can't operate on the bucket — operators must choose one or the other for noncurrent-version cleanup. Per AWS Glossary — S3 Versioning.
- Pair Versioning with
NoncurrentVersionExpirationlifecycle rules to control cost. Every version stored separately at the same per-GB rate — a 500MB config uploaded 20× is up to 10GB of billed storage unless a lifecycle rule cleans noncurrent versions. Per AWS docs — How Versioning Works. - Versioning + lifecycle as the canonical 2026 cost-discipline pattern. Per a May 2026 walkthrough, lifecycle policies with NoncurrentVersionExpiration are the recommended pattern to keep versioning costs bounded while preserving recovery-point capability. Per Medium — S3 Versioning + Lifecycle.
- Delete-marker + versioned-deletes semantics for ransomware defense. Properly-configured versioning with MFA Delete provides cryptographic protection against an attacker who acquires standard IAM credentials — they can create delete markers but cannot permanently delete versions. Per CloudWebSchool — S3 Versioning Explained.
Connections 5
Outbound 3
scoped_to1enables2Inbound 2
depends_on2