AWS Lambda - Automated SnapshotsTweet Tue 10 January 2017
This is my version based on the code from the blog post from Ryan S. Brown, I recommend reading his blog before mine, you can find it here. I'm also including a recipe of how to deploy, my opinion fo why you should use the funtion the way it is and how to use the function to backup and restore your EC2 Volumes. Enjoy!
What's the difference?
I added the functionality to include the ec2 tags to the snapshot, downside is that now it makes a call to the API for each snapshot, it doesn't update them all at the same time (with just one call).
What it does?
The purpose of this tool is to automate the process of backing up important servers in AWS, the idea is to have a way that we can control what servers will need daily backups and what retention period will need. For this we're going to be using some AWS services: Lambda and EC2 Tags.
By having daily snapshots we will have the opportunity to restore an instance easily, reasons can vary but common ones are: corrupted volumes, AZ failure, etc. So, how this process works? Here's how:
- There are two lambda functions, one for taking snapshots and other one to act as janitor
- Both functions are configured to run on daily basis
- The backup lambda look for instances that have the 'Backup' tag (it doesn't matter the value), then it takes snapshots of all volumes attached to the instance and looks for the value in the tag 'Retention' to set an expiration date for the snapshot, if there's no tag it will use a default value (30 days). When creating the snapshot it adds the expiration date, so for example the function runs on November 1st and it has a renetion period of 7 days, it will add an expiration date of November 8th.
- The janitor lambda will look for snapshots that has to delete, meaning that it will take the date when it's running and will search for snapshots that have the tag 'DeleteOn' with the date.
Why snapshots and not AMIs?
There are a couple of reasons for this decision:
AMIs - AMIs are cool because in order to restore we just launch a new instance with few clicks - Downside of this is that there are times that we will need to keep the IP, IAM Role assigned, Tags and SG ... and when an emergency comes taking care of all of those aspects is too risky and complex - There's no guarantee at 100% that when we take an AMI from a running instance that when restoring the AMI will keep working, because it was still running there might be some files corrupted (that's why the recommendation is to stop the instance first)
Snapshots - Are incremental, only the first time will take time to create it - It's easy to restore (read below for details)
For more details about them, please check the official docs: AMIs and Snapshots.
How to upload/configure the code to AWS Lambda?
For both functions, we'll need to do the following:
- Create Lambda IAM Role with the permissions described in the policy from this repo (iam/policy.json)
- Go to AWS Lambda and click on "Create a lambda function" button
- Select "Blank Function" blueprint
- Configure the trigger, click on the left button and choose: "CloudWatch Events - Schedule"
- Put a rule name if it's new or choose from an existing one
- Choose a schedule expression, in this case should be one day
- Check the "Enable trigger" checkbox
- Click "Next"
- Configure the lambda function:
- Put the name of the function
- Choose "Python 2.7" as the Runtime
- In the box below, paste the code of the lambda function in the src folder of this repo
- For Role, select the option "Choose an existing role"
- Choose an existing role (the one created in step 0)
- Leave evyrthing else as default
- Click Next
How to restore an instance from a snapshot?
Follow this instructions to restore an instance with previous snapshot:
- Go to EC2
- Identify the instance and the volume(s) with problems, take note of the volume id and the AZ of the instance
- Go to Snapshots and search for snapshots from volume id with problems
- Choose the most recent snapshot and create a volume in the same AZ from the instance
- While the volume(s) is/are being created, stop the instance with problems
- Detach the volume(s) from the instance, take note of the "Block Device" name (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-detaching-volume.html)
- When the volume(s) is/are ready, attach the volume to the instance with the same "Block Device" name (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-attaching-volume.html)
- Start the instance
Questions or suggestions?
Easy, just send me an email or open an issue here