S3 Versioning and Object Lock

S3 Versioning is a bucket-level feature that preserves every object version written to a bucket, including overwrites and deletions. Without versioning, when you upload an object with the same key, it replaces the existing object permanently. Versioning provides a safety net: you can recover from accidental overwrites, deletions, and application failures. It also serves as a foundation for other S3 features like Lifecycle Policies, Cross-Region Replication, and S3 Object Lock.

When you enable versioning on a bucket, S3 assigns a unique version ID to each object upload. The version ID is a string generated by S3 (e.g., ydlagOWnU0uA9jV.zf7W7TlWUuIqB3). If you upload an object with the same key, S3 does not overwrite the existing object; instead, it creates a new version with a new version ID. The previous version remains accessible. The bucket can have multiple versions of the same key, each with its own version ID.

When you delete an object in a versioned bucket, S3 does not actually delete the object. Instead, it inserts a delete marker—a zero-length object with a version ID—which becomes the current version. The delete marker hides all previous versions. To permanently delete an object, you must specify the exact version ID of the object version you want to delete. Delete markers themselves can be deleted, which restores the previous version as the current version.

Versioning states: - Unversioned (default): Bucket starts unversioned. You cannot recover overwrites or deletions. - Enabled: S3 assigns version IDs to all objects. Previous versions are preserved. - Suspended: Once enabled, you can suspend versioning. New uploads get a null version ID, but existing versions remain. You can still access and delete previous versions.

Enable versioning via AWS Console, CLI, or SDK. CLI example:

aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled

To suspend versioning:

aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Suspended

To list object versions:

aws s3api list-object-versions --bucket my-bucket

To delete a specific version:

aws s3api delete-object --bucket my-bucket --key mykey --version-id <versionId>

To delete a delete marker:

aws s3api delete-object --bucket my-bucket --key mykey --version-id <deleteMarkerVersionId>

S3 Object Lock prevents objects from being deleted or overwritten for a fixed retention period or indefinitely. It works only on versioned buckets. There are two retention modes:

Legal Hold is a separate setting that prevents deletion regardless of retention period. It can be set on individual object versions. Legal hold has no expiration; it must be explicitly removed.

Retention period can be specified in days or years. You can set default retention settings on the bucket (default mode and period) that apply to all new objects, or you can set retention on individual objects via PUT requests.

To enable Object Lock on a bucket, you must enable versioning first. Object Lock can only be enabled at bucket creation. CLI example:

aws s3api create-bucket --bucket my-bucket --object-lock-enabled-for-bucket

To set default retention:

aws s3api put-object-lock-configuration --bucket my-bucket --object-lock-configuration '{"ObjectLockEnabled": "Enabled", "Rule": {"DefaultRetention": {"Mode": "GOVERNANCE", "Days": 365}}}'

To apply retention on an object during upload:

aws s3api put-object --bucket my-bucket --key mykey --body file.txt --object-lock-mode GOVERNANCE --object-lock-retain-until-date 2025-12-31T00:00:00Z

To set legal hold:

aws s3api put-object-legal-hold --bucket my-bucket --key mykey --legal-hold Status=ON --version-id <versionId>

A financial services company must retain transaction records for 7 years per regulatory requirements. They use S3 Object Lock in Compliance mode with a 7-year retention period. Versioning is enabled to capture every modification. The bucket policy prevents deletion of any object version. Lifecycle policies transition noncurrent versions to S3 Glacier after 30 days to reduce costs. MFA Delete is enabled to prevent accidental suspension of versioning. Misconfiguration example: If the retention period is set too short, records could become deletable before the compliance deadline. If Object Lock is not enabled at bucket creation, they would have to migrate data to a new bucket, causing downtime.

A media company stores critical assets in an S3 bucket with versioning enabled. They use lifecycle rules to expire noncurrent versions after 90 days to manage storage costs. Cross-Region Replication sends all versions to a bucket in a different region for disaster recovery. MFA Delete is enabled on the source bucket. A developer accidentally deletes an important asset. The delete marker is created, but the IT team can easily remove the delete marker to restore the asset. Without versioning, the asset would be permanently lost. Common pitfall: Not testing the restore process; they discovered that versioning was suspended on the replica bucket, so only the current version was replicated.

A software development team uses an S3 bucket to store configuration files and build artifacts. Versioning allows them to roll back to previous configurations. They use presigned URLs with version IDs to share specific versions with team members. Object Lock is not needed here. However, they must manage version proliferation: without lifecycle policies, the bucket accumulates thousands of versions, increasing storage costs. They implement a lifecycle rule to expire noncurrent versions after 30 days. Misconfiguration: They accidentally set the lifecycle to expire current versions, causing data loss.