Day 2 - Snapshots and Volumes

AWS Cost Optimisation Advent Calendar 2024

4 min read time

#aws #ebs

Welcome to day 2 of the unofficial AWS Cost Optimisation Advent Calendar 2024, where every day we will be sharing new tips or tricks to help you optimise your cloud costs before Christmas 2024.

Today the topic is snapshots and volumes.

There are various reasons that unneeded snapshots might be hanging around. Some examples include snapshots created whilst creating AMIs, snapshots that were made as a safety net backup before some change, or actual backups that you want to be there forever.

It is a good idea to periodically review your snapshots and see which are actually needed for instant access, or are there because of active AMIs.

So, today is that day. Go and review your snapshots and you might be surprised what you find there.

The 4 most common types of snapshots you are likely to find are:

1. Backups that have been made at various intervals
2. Snapshots that were created when creating an AMI
3. Snapshots you have no idea where they came from or what they do
4. Snapshots that are just obviously duplicates or no longer needed

It goes without saying, the 4th kind can just be deleted immediately and we will focus on the other 3.

Archiving Snapshots

For the backups, you should have a retention policy in place that makes sense for your business. Some snapshots might be useful to have instantly available.

But most are probably just for that "if we ever need to go back and look" scenario, and these are the ones you want to take advantage of the archive snapshot feature in AWS.

When archiving snapshots you can save up to 75% of the cost of the snapshot.

Snapshots from AMIs

You only ever need the latest snapshot from an AMI you use, so check the reference to the AMI of any snapshots you have, and delete the older ones that are no longer needed. Now would be a good time to clean up any unused AMIs too.

Snapshots you have no idea where they came from

This is a bit more tricky, but you can start by looking at the descriptions or tags of the snapshots to see if there are any clues as to their origination.

If you have CloudTrail enabled, they have been logging EBS activity since around 2021, so if the snapshot is newer than that you may have a record of where it came from in CloudTrail.

You can also create a volume from a snapshot and mount it to an EC2 instance to have a peek what it is and try to understand why it might be hanging around.

AWS will usually be quite diligent in telling you when you are trying to delete a snapshot that is currently in use, but that is not to say the snapshot might be hanging around for some undocumented reason.

For this reason, if upon investigation things are still unclear, these snapshots are usually best to Archive. In addition you can also set an internal note that they will be scheduled for deletion in the future if no valid reason is found to keep them hanging around.

Volumes

The strategy for unattached volumes is similar to snapshots, however there is no ability to archive volumes without creating a snapshot of them first.

Once that is done the strategy is the same for either getting rid of or archiving them.

We are only looking at detached volumes today and will go into more detail on how to manage and optimise attached volumes in future posts.

Final Notes

As orphan snapshots and volumes are a common issue that soak up unneccessary cost, it is always best practice to ensure that any data which is deliberately being stored, has a clear description, tags, and where applicable deletion protection or a snapshot lock to ensure that it doesn't get cleaned up on one of these sweeps.

That said, deleting data is one of the scariest things you can do in IT, so triple checking with as many people as possible before doing so is always a good idea.

Join us tomorrow for the next edition!

To be one of the first to know when the next edition is published please follow us on LinkedIn, X or subscribe to the RSS feed.