Instructor: Okay, so now let's do a deep dive
into EBS snapshots.
So we can know that we can make a snapshot
at any point of time of your EBS volume, okay?
And it's not necessary to detach your volume
to do snapshots, but it's recommended
because if a volume is attached to an instance,
that means that you may have some kind of consistency issue.
Now you can copy a snapshot across AZs or Region.
That means that you can take US-EAST-1 and US-1B.
So you have an EBS volume in here,
then you have an instance in US-1B,
and so you take an EBS volume, you make a snapshot from it,
and then you restore it in another AZ
which is the action of migrating a snapshot, okay?
Next, there is a service with an EBS
called Amazon Data Lifecycle Manager
which is used to automate the creation, retention
and deletion of EBS snapshots, and EBS-backed AMI.
So it's a way for you to schedule backups,
do cross-account snapshot copies automatically,
or to delete outdated backup using policy.
Use resource tags to identify the resources
you want to back up, for example, EC2 instances
or EBS volumes.
And so here's an example.
We can tag an EBS volume with Environment Prod
to make sure that it automatically gets backed up
by Amazon Data Lifecycle Manager.
Or we can tag directly an EC2 instance
with this Environment Prod,
and then the instance itself would be,
and its EBS volumes backed up.
So it goes into Data Lifecycle Manager
and we can create snapshots and AMIs out of it.
It cannot be used to manage snapshots or AMIs created
outside of DLM, so everything has to be contained
within Data Lifecycle Manager.
And it cannot be used to manage instant-store backed AMIs.
Next, one little feature that could be really really helpful
but really really expensive,
is called Fast Snapshots Restorative, FSR.
So the idea is that your EBS snapshots internally,
they are stored in Amazon S3.
So you don't see them, but this is how they're stored
internally in AWS.
And so when you restore a snapshot into an EBS volume,
and you access a specific block of data, okay?
There's a latency on this I/O operation.
The first one, because the block is going to be pulled
from Amazon S3 every time.
And so there a solution for it,
to force the initialization of the entire volume
by reading the entire volume from the EC2 instance
using the dd or the fio command.
This is the previous solution.
And so the idea is that you start an EC2 instance,
you attach an EBS volume, and you read the entire volume.
Then therefore, all the blocks
will be accessed and initiated.
Or you can do something called
a Fast Snapshot Restore of FSR.
So the idea with FSR is that you can enable it
on any snapshot at any time.
And what FSR will do is that it will do this initialization
of the entire volume for you, okay?
And then once a volume is fully initialized,
you can restore it into an EBS volume
on which there will be no I/O latency.
So to show you an EBS snapshot being restored
into an EBS volume may only have a few blocks initialized,
and as you read the blocks,
they will be pulled from Amazon S3.
But if you enable FSR on the snapshot and FSR is complete,
what will happen is that the entire EBS volume
is going to be ready and available to use
at best performance right away.
So you enable this for a snapshot in particular,
it's billed per minutes
and it's honestly very very expensive.
So leaving FSR on all the time can be very costly,
around $500 per month.
But the use case in the real world is to take a snapshot,
enable FSR so that AWS will initialize the snapshot for you,
and then you restore it into an EBS volume,
and then you disable FSR, okay?
So finally, you can use Data Lifecycle Managers, DLM
to enable this on snapshots directly.
Although personally speaking, this could be not recommended
and very very expensive.
So some features you need to know about for EBS snapshots
is the first one, an EBS Snapshot Archive.
So it allows you to move your snapshots
to another storage tier called an archive tier.
And that tier is 75% cheaper.
So your snapshot is going to be moved, you know,
manually or whatever, however you set to the archive tier.
But if you have it in your archive, it takes you
between 24 to 72 hours to restore from the archive.
So these are for snapshot that are not very important to you
to restore in a rush, okay?
But you wanna save some costs on them.
The second feature is around recycle bin for EBS snapshots.
So by default, when you delete snapshots they're gone.
But you can set up a recycle bin,
and the recycle bin will have all those snapshots
that are deleted.
And then after a while, maybe you can specify from one day
to one year, the snapshots are gone from the bin.
So on deleting a snapshot, it would go into recycle bin,
and you may have, for example one year
to recover the snapshot,
which allows you to protect yourself
against accidental deletion.
Okay, that's it for this lecture, I hope you liked it,
and I will see you in the next lecture.