Automate EC2 backup lifecycles and save money on EBS

An extremely common use case for AWS environments is the backup of EC2 instances. It is straightforward to use scripts to automate taking snapshots of your EC2 instances. However, things can quickly get out of hand as you try to keep costs under control. For example, customizing the same scripts to handle snapshot retention, and then with different retention policies for different accounts. Beyond that, AWS accounts can accumulate unwanted snapshots and images arising from CI/CD processes. These can slowly escalate AWS costs if they are not removed after they are needed.

GorillaStack has a comprehensive suite of actions. You can use automate EC2 backups, cleanup EBS snapshots, images and volumes across multiple AWS Accounts. On top of that, you have all the access control that you’d expect from an enterprise product, all without writing a single line of code.

Automatically back up EC2 instances with Snapshots

Maintaining scripts to backup your EC2 instances on a regular basis can be a nightmare as new accounts are added, new application deployed and as policies diverge across the business. GorillaStack lets you target multiple AWS accounts and EC2 instances at the same time, so you only need to keep your automatic EC2 backup configuration in one place. It uses tag groups, which act as filters against your environment, matching tag keys and values. They have the added advantage of picking up new resources matching the same tagging policy without having to update a rule.

Create Snapshots of EC2 instances

After you have linked an AWS account to GorillaStack, it is easy to schedule a rule to create snapshots on a regular basis of your EC2 instances using the Create Snapshots action:

(NOTE: if you are targeting Windows instances, you may find the Create VSS Snapshots more useful – it operates in the same way but also lets you exclude the boot volume from snapshots)

1. On the Rules page, select Add a New Rule

  2. Set a Rule name e.g. Backup Production instances

  3. Click on Set Context. Select the accounts and regions you want to run the rule in.

   4. Click Next and then Set Trigger to choose the trigger. Most customers will schedule this action, so select Schedule (you could also choose to run it with a Manual trigger, or using a Incoming Webhook to integrate it into another part of your DevOps pipeline)

   5. To have it run every day, select Every Day and choose a time your environment is not busy e.g. after work hours for test environments. Click Next to continue.

   6. Hover over the Add Pause or Action button, click Set Action and then select the Create Snapshots action

   7. In the Targeting section, you can leave the setting as All attached volumes to back up everything in the selected accounts, or switch to Tag Targeted so that only volumes matching a particular tag are backed up

   8. In the Snapshot Tagging section, you can set if the target snapshots have tags copied from the Volumes and/or from the Instances, and even add your own additional tags. A handy trick here is to add a tag with a value of the rule name using the GS::RuleName macro so that you can pair a backup rule with a deletion rule by matching on the added tag.

   9. Select Overview to return to the rules screen, click Save Rule, and you’re done! GorillaStack will now automate the hard work of backing up the volumes of your EC2 instances.

Learn more about automatically creating snapshots of your EC2 volumes.

Automatically clean up old snapshots of your EC2 volumes

The flipside of a backup policy is a retention policy. GorillaStack can also automate the deletion of snapshots

GorillaStack’s Delete Snapshots action lets you schedule the deletion of snapshots across your AWS Accounts. You can target the snapshots to be removed using the tags on the snapshots themselves (or you can opt to remove all snapshots).

As well as the tags, GorillaStack engine has two ways of determining if it should remove a snapshot (assuming it matches the selected tag group):

1. Keep last (x) snapshots: this option retains the last x count of snapshots per region. Use the Keep Snapshots by Volume option to keep the last x count of snapshots per volume (grouped by VolumeId)

  2. Created greater than (x) days ago: this variation deletes snapshots older than a specific number of days. It can optionally keep the latest snapshot for the region or by volume.

Learn more about automating your snapshot deletion.

Delete Orphaned AMI Snapshots

When you create an Amazon Machine Image (AMI) in EC2, an Elastic Block Store (EBS) snapshot is created to back it. However, when you delete this AMI, the snapshot is not deleted with it. If you have automated AMI creation, especially as part of a CI/CD pipeline, these snapshots can accumulate very quickly. They are a common source of wasted EBS usage, but thankfully, one of the easiest to clean up in GorillaStack.

Similar to backing up instances, the Delete Orphaned Snapshots action can be run with a Schedule trigger to regularly remove orphaned EBS snapshots:

Learn more about automatically deleting orphaned snapshots.

Remove unused detached volumes

Another way to save on your EBS costs is to delete EBS Volumes after a certain period of non-usage. GorillaStack is able to track volumes over time and use rules to automate their removal using the Delete Detached Volumes action.

Similar to the other actions described above, you can schedule a regular rule to remove detached EBS volumes based on their tags. You choose a number of days they have been detached from their EC2 instance before they are removed.

Learn more about deleting detached EBS volumes.

Delete Amazon Machine Images (AMIs)

If you also have CI/CD generating AMIs of your product, especially in a development environment, you may wish to clean up old AMIs that are no longer in use.

Like snapshots, you have two options for retention:

1. Keep last (x) images: this option retains the last x count of images per region
2. Created greater than (x) days ago: this variation deletes images older than a specific number of days. It can optionally keep the latest image for the region.

As always, if you’d like to discuss your infrastructure and how our software can help you – get in touch!