Chris Armstrong | Wed, 12 Dec 2018
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)
GS::RuleNamemacro so that you can pair a backup rule with a deletion rule by matching on the added tag.
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):
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!