And welcome back now in today's video, we'll be discussing about these three lifecycle policies now,
generally, most of the organizations, the amount of storage required to store important data in S.T.
ranges in terabytes.
Now, when you have terabytes of data stored in history, one of the primary factor that comes into
the picture is the cost.
Now, we already know that most other times what happens is that the users will directly upload the
data as part of the S3 standard storage class, and this is much more expensive.
So depending upon the access patterns, the criticality of the data, what you need is you need to store
it in the appropriate storage class.
Now, one of the things that can be used here is the S3 intelligent hearing, which can go ahead and
move the data between the standard and the infrequent access.
However, there are other storage classes that are much more cheaper that can also be used, but it
is not directly supported with the intelligent theory.
So you need some kind of automation system which can automatically transition the data between multiple
storage classes.
So let's say that we want to store one month of loss within the Amazon is very similar to these logs
might be accessed quite frequently, maybe for security related purposes, for debugging related purposes,
troubleshooting related purposes and so on.
After one month, the chances of accessing the log is very minimal.
So what we need automatically these logs should be transferred to the standard infrequent access.
And after storing it in infrequent access for a certain amount of time, let's say one more month,
then the chances of accessing the logs are very minimal.
But you still need the logs for the compliance purposes.
So what you need after may be some amount of time.
You want to move those logs to Galatia.
So automatically transitioning the data between multiple storage classes is something that can be achieved
with the help of lifecycle policies.
So this can be better understood with the diagram here where you have a video stored industry standard.
So what you want initially it might be accessed a lot.
However, after 30 days, the chances of video being access is very minimal.
So what do you do?
You move it to a different stories, class of standard, infrequent access after 30 days and after some
amount of time in the infrequent access, let's say after 60 days, the chances of you having access
is almost nil.
However, you still need this specific video.
So what you do after 60 days, the video goes to the glacier.
So this transition actions that are happening in an automated way is something that is taken care of
by their lifecycle policies in S3.
So let's quickly look into it now for today's video.
I have a sample size three bucket and this is three bucket has one object.
Now, this object has the associated storage class of S3 standard.
Now, when we are discussing about this transition actions, as we discussing this is possible with
the help of lifecycle policies.
Now, lifecycle policies are not enabling a three by default.
So whatever object that is being stored, it will continue to remain in the standard storage class.
So in order to go ahead and create transition actions, what you need to do, you have to go to the
management and within a year you have lifecycle rules.
So let's go ahead and create a lifecycle rule here within the lifecycle rule.
Let's call it the module and within the rules scope.
I just specify apply to all of the objects here and now.
The next important thing is lifecycle rule actions.
The first one is transition current version of objects between storage classes.
So I'll go ahead and select it now.
The first conversion of storage class from Standard needs to go to standard, infrequent, frequent
access after 30 days of object creation.
All right.
Now I add one more transition this time instead of intelligent during.
I'll say it later.
So after, let's say, 60 days of object creation, the object needs to go to Glacier.
While Gordon acknowledges this is basically related to the present and it is also giving you the summary
which states and zero the object gets created and this object on the data goes to this standard infrequent
taxes, and then after the 60, the object gets transition to glacier.
So this is the automated process that happens.
Audio once, then you can go ahead and create a.
So once you create a rule, you'll basically get information related to it.
So basically it starts transition to standard infrequent access and then transition to Galatia and currently
the scope is dead buckets.
All the objects that are part of the bucket will go through this specific rule.
Great.
No.
One more important thing that I wanted to show you, in fact, lifecycle policy also allows you to do
that.
Let's say that you have some data with your dad and before you need this data only for, let's say,
next 90 days, after 90 days, you do not really need it and you want to go ahead and delete it.
So all of these possibilities can also be done.
So it will quickly go to management.
And if you create a new lifecycle rule, if you look into the lifecycle rule, there are multiple actions
that are available.
One is for current version of the object.
Second is for the previous version of the object.
Considering that the other versioning and even then you also have the Xfire current version of the objects
where you can specify a number of days after which the object would expire.
You also have ocean related to permanently delete previous version of the objects and also to delete
an expired deleted marker.
So a lot of flexibility apart from transitioning the objects between storage class.
You also have the option to delete the objects after a certain amount of time with the help of lifecycle
rule actions.
That's great.
So I hope with this you understood the basics of these three lifecycle policies and will conclude today's
video.