Skeddly Blog

Skeddly news and announcements...

Deleting EBS Snapshots in Groups

Skeddly includes an action called “Delete EBS Snapshots” which can be used to delete old EBS snapshots. The snapshots that can be deleted can be selected based on their description, originating EBS volume ID, or resource tag. When the deletion process runs, snapshots can be preserved if they are younger than a desired snapshot age, and you can choose to preserve a minimum number of the most recent snapshots.

For example, you can choose to delete any snapshot older than 7 days, but preserve a minimum of 10 snapshots. This will preserve the 10 most recent EBS snapshots across all matching EBS snapshots.

But what if you want to preserve 5 snapshots from each of 2 projects? The 10 most recent snapshots may not be the 5 most recent snapshots from each of the 2 projects.
As similar issue arises with the originating volumes. Perhaps you want to preserve the 2 most recent snapshots from 5 separate volumes.

Until now, Skeddly included an option called “Per-Volume Logic”. When enabled, the action would apply the “Minimum to Keep” field to each distinct EBS volume found.

Today, we’ve expanded this functionality further.

Snapshot Grouping

Now, as part of the “Delete EBS Snapshots” action, you can choose to group the EBS snapshots by:

The originating EBS volume, or

A resource tag on the EBS snapshot

When grouping by EBS volume, the “Minimum to Keep” is applied for each distinct originating EBS volume. This essentially is the old “Per-Volume Logic”.

Grouping by resource tags is new. This new option allows you to group your EBS snapshots by an arbitrary value that makes sense to you.

For example, if you had a tag on your EBS snapshots called “Project” and some snapshots had a tag value of “Dev-Project” and some had a tag value of “Marketing-Project”, then you can preserve a minimum of 3 snapshots for each of your 2 projects.

Copying EBS Snapshots

Here’s another use case:

When an EBS snapshot is copied (whether within the same region, or to another region), the Volume ID attached to the new EBS snapshot copy does not reflect the originating EBS volume.

As you can see, the volume ID is vol-ffffffff. This causes a problem with grouping by Volume ID.

To solve this, we can do a few things:

When we create the EBS snapshots, we put the original EBS volume ID in a tag on the EBS snapshot. This can be accomplished easily with Skeddly by using the $(VOLUMEID) macro in any of these actions:

Create EBS Snapshot

Create Multiple EBS Snapshots

Backup EC2 Instance

Backup Multiple EC2 Instances

Or using Managed Instances

In the secondary region, we group EBS snapshots by that resource tag.

In the primary region, we can group by the same tag, or we can group by EBS volume ID.

By setting up our actions in this way, it allows us to:

Create daily EBS snapshots

Copy those EBS snapshots to a secondary region

Clean up old snapshots in the original region, preserving a minimum number of snapshots for each volume

Clean up old snapshots in the secondary region, preserving a minimum number of snapshots for each volume