Anyone who uses AWS knows the value of EBS snapshots.  Not only are snapshots the backbone for any solid backup strategy but can also assist with instance migrations and replication.  While manual snapshots are useful for testing changes or for AMI builds, a backup strategy depends on snapshot automation and retention policies.  When I first began working with AWS, automating snapshots was done through the EBS Snapshot Scheduler.  For AWS architects and system admins, this tool was invaluable.  An AWS provided CloudFormation template provided all required resources for the scheduler to run.  The CloudFormation template launched a single stack and prompted the user for a tag name, default snapshot time, whether to enable autosnapshot deletion and, if so, what the retention period should be.  Once your config was set, you simply tagged your resources with the custom tag you entered in the stack and your backups were on cruise control (of course any Admin “worth their salt” still performed period checks and snapshot verifications).

While it was a great tool, EBS Snapshot Scheduler wasn’t without limitations.  Since the single CloudFormation stack contained one set of global parameters, creating a custom schedule for an instance was problematic.  Following the default settings required adding the custom tag (that you set in the initial deployment) to an instance and setting the value to true.  If you wanted a different time to take the snapshot or to take it on a different day, you had to enter those parameters manually in the proper format as the tag value.  What if you wanted a single instance to take snapshots multiple times a day and have a retention period for the snapshots different from the default?  It was possible, but required modifications to the tag name and properly formatted values.  While this method allowed some flexibility, it was a “bit messy.”

Beginning in 2018, AWS retired the EBS snapshot scheduler.  Why, oh why, would they get rid of something so awesome?  The short answer—to replace it with something even more awesome!  The EBS Snapshot Scheduler has been replaced by the AWS OpsAutomator.  If you were used to the EBS Snapshot Scheduler like I was, the new OpsAutomator can seem somewhat foreign and complicated.  When you initially launch the CloudFormation template, the only global setting you create is a tag name.  Where are the “jobs” defined and why are they not created in the initial deployment?  The “jobs”, or tasks, as AWS calls them, are provided as additional CloudFormation templates located in an S3 bucket that is automatically created during the initial deployment.  Each task is broken up into separate templates so CreateSnapshot, DeleteSnapshot and CopySnapshot are all different tasks.  To create a task schedule, such as a schedule to create a snapshot, you must launch one of these templates and enter the settings you want.  Each task template can be run more than once, thus allowing you to create multiple CreateSnapshot tasks, each with a different name and unique settings.  For each resource on which you want to run a job, you must add the global tag that you created in the initial stack with the value set as the task name you want to run.  You can even run multiple tasks by separating task names with a comma.  You will discover that the separation of tasks into different templates, and the ability to create multiple tasks (each with a unique name and settings) will make tagging resources simpler and cleaner.

While OpsAutomator is great, the setup can be tedious and having to reproduce all of the settings over and over again for multiple AWS accounts is not something any admin wants to do.  This is where OpsAutomator truly shines.   In addition to the task templates located in S3 bucket, you will also find Role templates.  The Role templates are used in secondary AWS accounts to create a job trust between accounts and allow any task created in the primary AWS account to be run on resources in a secondary AWS account.  The snapshots taken in the secondary account are stored in the secondary account only.  The only trust between the accounts is the role to allow the job to run.  This puts all setup and task configuration in one central location for simpler management.

Wile EBS Snapshot Scheduler was great utility, the OpsAutomator is definitely a big improvement.  The ability to separate tasks into different stacks definitely makes tagging resources much simpler and will make much more sense to anyone looking at the tag for the first time.  The ability to have one OpsAutomator deployment in a primary account and run tasks across multiple secondary accounts is what makes OpsAutomator a huge leap forward.