What is the significance of AWS Versioning?

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.  

• When an object is deleted, instead of removing it permanently, S3 inserts a delete marker into it, which becomes the current version of that object. The previous versions can always be restored.  
• If an object is overwritten to, the object would have new data, which is considered as a new version of the object. Even in this case, the previous versions of the object can be restored.  

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: 

• Unversioned state (considered as the default state) 
• Version enabled state  
• Version suspended state 

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.  

• When versioning is enabled on a bucket, it is applied to all objects in that bucket. It is never enabled on just a few objects in the bucket.  
• When versioning is enabled on an S3 bucket for the first time, objects present in the bucket from then on will remain versioned. They will also be given a new and unique version ID.  
• Objects that are stored in the bucket before version-enabling have a version ID of null. When versioning is enabled, the existing objects in the S3 bucket don’t change. The only change would be the way in which Amazon S3 would handle the objects when further requests come in.  
• The owner of the bucket or any other user who has the appropriate permissions to access the bucket will have the ability to suspend the versioning so as to stop accruing the object versions.  

Configuring versioning on an S3 bucket 

S3 bucket can be versioning in the below mentioned methods: 

• Using the Amazon S3 console. 
• Programmatically versioning the buckets with the help of AWS SDKs. 
• Using the console and SDK to call REST API which is provided by Amazon S3 for the purpose of managing versioning.  

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: 

• The bucket owner, 
• The AWS account user who created this S3 bucket,  
• The authorized users who have been given permissions. 

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:

Image credit: aws.amazon.com

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:

Image credit: aws.amazon.com

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:

Image credit: aws.amazon.com

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:

Image credit: aws.amazon.com

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:Image credit: aws.amazon.com

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.

Conclusion 

In this post, we understood the significance of versioning.