Versioning refers to maintaining multiple variants of an object in the same Amazon S3 bucket. It is used for the preservation, retrieving and restoration of every version of each object that is stored in the S3 bucket. Versioning can be used to recover from unintended user actions and application failure easily. An S3 bucket can be used to store multiple objects that have the same key, but they would have different version IDs.
Version-enabled buckets help the user to recover objects in case they have been accidently deleted or have been overwritten.
If the user has an object expiration lifecycle policy in their non-version enabled bucket, and they wish to maintain the same permanent delete behaviour when they enabled the versioning of the S3 bucket, the user will need to explicitly add a noncurrent expiration policy. The noncurrent expiration lifecycle policy will help in managing the deletes of the noncurrent object versions in the versioning enabled bucket.
Versioning enabled buckets help in the maintenance of a single current object version and zero or more non-current object versions.
An Amazon S3 bucket can be present in one of the 3 states which are mentioned below:
Once a bucket has been enabled for versioning, it can never be made to move back to an unversioned state. But the same bucket can be moved to a suspended version state.
S3 bucket can be versioning in the below mentioned methods:
Note: REST API calls can be made from the code as well, but this is a little complicated since it would involve writing code to authenticate user requests.
Every bucket created in Amazon S3 comes with a versioning sub-resource which is associated with it. The bucket is unversioned by default, and on the same lines, the sub-resource versioning stores empty versioning configuration as shown below:
To make sure that versioning is enabled, a request has to be sent to Amazon S3 along with a versioning configuration that has a ‘status’, as shown below:
In order to suspend versioning, this same ‘status’ value can be set to ‘Suspended’.
The below mentioned users have the permissions to configure the state of versioning of the bucket:
Note: The SOAP API doesn’t support versioning, and support of SOAP over HTTP has also been deprecated, but can be used with HTTPS. Amazon S3’s new feature doesn’t support SOAP services.
When an object is PUT in the versioning-enabled bucket, the no current version doesn’t get overwritten. Instead, Amazon S3 generates a new version ID for the same object. This way, when a user accidentally overwrites or deletes an object, its previous version can be restored. The below image shows the same:
When an object is used with DELETE, all the versions of that object will remain in the bucket, and Amazon S3 just puts in a delete marker. This has been shown in the below image:
The delete marker is stored as the current version of that object. The GET request retrieves the most recently updated version by default. When GET request is sent to retrieve the most recent version of the object (which has a delete marker, i.e has been deleted), it returns a ‘404 Forbidden error’.It has been shown in the below image:
But it is possible to get the non-current version of the object with the help of the GET request, by specifying the version ID of the object. This has been shown in the image below:
An object can be permanently deleted from the S3 bucket by specifying its version. This can be done only if the user trying to delete the object is the owner of the bucket. When an object is permanently deleted, no delete marker is inserted into it. It has been shown in the below image:
Additional security can be provided by configuring the bucket to be MFA (Multi Factor Authentication) enabled. When this is enabled and an object from the bucket is tried to be deleted, the user who created the S3 bucket will have to include two authentication forms in the request to delete the object. This holds true even while changing the version state of the object.
In this post, we understood the significance of versioning.