Hello and welcome to this lecture covering the first element of the S3 Bucket Properties, this being versioning.

This is a bucket feature that allows for multiple versions of the same object to exist. This is useful to allow you to retrieve previous versions of a file, or recover a file should it subjected to accidental deletion, or intended malicious deletion of an object.

Versioning is managed automatically against objects when you overwrite or delete an object in a bucket that has versioning enabled. To ensure you are always working with the most current version of an object, only the latest version of the object is displayed within the console. However, you are able to review all versions of an object should you need to.

Versioning is not enabled by default, however, once you have enabled it, you can't disable it, instead, you can only suspend it on the bucket which will prevent any further versions from being created of your objects, but it will keep all existing versions of objects up to the point of suspension. With this in mind, this means your buckets can be in the form of any one of these 3 states: Unversioned (this is the default state for buckets), Versioning-enabled, and versioning-suspended.

With versioning enabled you should also bear in mind that you will incur additional storage costs as you will be storing multiple versions of the same file, and one of the costing metrics of S3 is how much data storage you use.

So now we have a clearer understanding of what versioning is, let’s dive a little deeper into the process and its configuration.

To enable versioning is very easy and there a couple of ways of doing so. Firstly from within the AWS Management Console, you can either enable it during the creation of a bucket or enable on an existing bucket. 

When creating a new bucket, you can enable it during the 2nd step, ‘configure options’ as shown. The first option at the top of the screen is ‘Versioning’. To enable it for your new bucket, simply select the checkbox. 

To enable it on an existing bucket, select the bucket from within the S3 dashboard and select ‘Properties’. You will see a number of tiles relating to different properties o the bucket, the first one shown will be ‘Versioning’ and it will display as disabled. Select the tile and then select ‘Enable versioning’ and ‘Save.’ The tile will now show as ‘Enabled.’

Once you have successfully enabled versioning on your bucket a new parameter value is visible when you go into your buckets, this being ‘Versions’ and displays two options: ‘Show’ or ‘Hide.’ The default is ‘Hide’, however, if you select ‘Show’ you can see the ‘Version ID’ of the object.

For any new objects that are uploaded AFTER versioning has been enabled, the object will receive a new ‘Version ID’, such as the example shown. If you enabled versioning on an existing bucket with objects already in them, then their ‘Version ID’ will be displayed as ‘null’ until they have been modified or deleted. At which point they will receive a new Version ID.

Every time the same object is modified in some way it will receive a new Version ID, and the latest change will be the one object displayed within the bucket.

As you can see from the example here, I have versioning enabled on bucket ‘s3deepdive’ with an object entitled ‘s3-versioning.docx’. You can see that I have modified this file a number of times, and each time it has been saved to the same bucket, via a PUT API call, the object has received a new Version ID. The most current version is at the top and defined by the note in brackets ‘Latest version’, so the object is not overwritten, a new object is created with a new version ID. If I were to click on ‘Hide’ then only this version would be displayed.

From this view showing multiple versions I can open and load any of those previous versions if I needed to recover from an older file, or if I wanted to see what had changed. This view helps to demonstrate that using versioning can make your storage costs grow significantly if you have thousands of rapidly changing files.

Let me explain what happens when you delete objects in a version enabled bucket. Let’s assume we have our same s3-versioning.docx file and I chose to delete it from within the Console. Assuming I was ‘hiding’ the versions in the bucket, so I’m simply showing current versions only, the object would be deleted and not visible in the bucket. However, the object has not been deleted. If I clicked on ‘Show’ versions, then I would see the following.

Here we can see we have our existing 3 versions, all with the same Version IDs as expected, however, we have a 4th version at the top identified with a Delete Marker in brackets.

So what’s happened here? Well basically, this delete marker version becomes the current version of the object and ensures that any GET request to access the object will return a ‘404 not found value’. However, ALL other versions still exist, including the same version of the file that was submitted for deletion, so you can still view and open these files from the console when you have all versions shown, or by specifying the VersionID in a GET API call to call a specific version.

If you wanted to permanently delete an object in a versioned bucket then you must use the DELETE Object versionId in an AWS SDK, specifying the exact version that you want to delete. If you delete the version with the delete marker, then the object would reappear in your bucket using the latest version of the object available.