One way to support your backup and recovery processes is to ensure that versioning and lifecycle rules are enabled for S3 buckets. S3 versioning and lifecycle rules also provide a way to keep your content accurate and up-to-date. AWS makes it fairly simple to properly configure these rules, plus you can enable bucket versioning on both new buckets and buckets that already exist. 

In this demo, we will show you tips and tricks of S3 versioning and lifecycle rules, including: 

To create lifecycle rules, open the Management tab on an existing bucket, the select Create Lifecycle Rule. Next, you’ll choose the Rule Scope and then choose from several sets of Lifecycle Rule Actions. 

For a visual guide on how to create S3 versioning and lifecycle rules, watch the full demo. 

You see, here, that we are logged in to our S3 console. We’ll go ahead and create a bucket and we’ll give it a, hopefully, unique name. That looks good. So, we’ll go ahead and turn this on. You can also enable this on buckets that already exist. We’ll show where to do that in just a second. While we’re at it, we’ll also go ahead and enable encryption, because we like encryption, encryption is great security control and provides some additional protection of our data. We’ll go ahead and enable S3 encryption and go ahead and create that bucket. 

Alright, so we have our bucket name here. If you were enabling this on an existing bucket, you would go under “Properties” here and you would enable versioning here. You can see our options now are “Suspend” and “Enable.” “Suspend” has the effect of not creating any new versions of files as they are uploaded, but existing versions of files are not affected while in “Suspend” mode. 

Now, let’s come over here to our “Objects” and we’ll go ahead and upload a file. We’ll just grab some placeholder text and upload that. You see, sure enough, we have a file. Now, to see the versioning in action, let’s go ahead and upload the same file again. All you need to do to create multiple versions is upload a file with the same name. That will create the second version of the file. Sure enough, that successfully uploaded. You see, here, we also have a “List Versions” so we can see that we now have two versions. We have the current version, the one we just uploaded, as well as the previous version. If we were to delete this file, this will only delete the most current version, in which case it will make our next most current version the current version of the file. That’s how you revert back. If you needed to go back several versions of the file, you would have to download the file, specifically, then upload it again as the new version within the console or using the CLI commands. 

With that in place, let’s go look at lifecycle management rules. We’ll come here under “Management” and then “Create Lifecycle Rule.” We’ll just give it a name, randys lifecycle rule. We’ll make this rule apply to all objects. Yes, I acknowledge that it will do that. Now we get these checkboxes for the different actions that we could make our lifecycle rule take. We can transition current versions between storage classes. Storage classes in S3 are a great way to save a little money. Different storage classes have different access parameters to them. With the standard retail rate on S3 being the most expensive option, you can move to infrequently accessed or other storage classes and save some money for objects that maybe you need to keep around, but you probably don’t need to access them on-demand like you would any other object in the traditional, standard, retail class. Then, we can also transition previous versions between storage classes. As we add these checkboxes, we are getting different configuration boxes down here. So, if I turn this on, just to demonstrate, you see how the different boxes’ configuration options are changing down here. Then, it’s just a matter of setting these numbers up. We’ll try, I don’t know, we’re just going to make some stuff up. We’re going to transition to Standard-IA for current objects after 30 days. We will transition for noncurrent versions, you know what? We’ll also do that for 30 days. We’ll expire objects’ current versions after six months. We’ll permanently delete objects 60 days after we actually mark the deletion. When you delete a file in S3, you’re marking it for deletion. You’re not actually deleting it. That’s what we’re configuring, here, is the clean-up action to actually go back and delete those items. Actually, we’re doing that one here. 60 days after we mark something for deletion, we’ll go ahead and automatically remove it. As we set these things up, we get the different timeline summaries for current versions as well as for previous versions. 

So, we get to see how these rules are actually going to react. We’ll go ahead and create our rule and now we have a lifecycle rule set up to manage our S3 content, along with versions, so that we’re not unnecessarily keeping information around for a really long time. That concludes our video on S3 versioning.