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
Try It Today
Sign-up for our 30 day free trial or sign-in to your Skeddly account to get started.