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, but things can quickly get out of hand as you try to keep costs under control by 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, and 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 your EC2 backups, as well cleanup EBS snapshots, images and volumes across multiple AWS Accounts and with all the access control you’d expect from an enterprise product, all without writing a single line of code.
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 on 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.
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)
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.
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):
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.
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.
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.
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:
As always, if you’d like to discuss your infrastructure and how our software can help you – get in touch!