So one of the first annoyances one runs into with AWS EC2 is making sure one has proper and current backups. Prior to the announcement of Data Life Cycle Management, this involved a utility server to run croned scripts to snapshot volumes, remove old backups, copy to different accounts for disaster recovery and in general add a level of annoyance and frustration to the admins life.
According to AWS:
You can use Amazon Data Lifecycle Manager to automate the creation, retention, and deletion of EBS snapshots and EBS-backed AMIs. When you automate snapshot and AMI management, it helps you to:
- Protect valuable data by enforcing a regular backup schedule.
- Create standardized AMIs that can be refreshed at regular intervals.
- Retain backups as required by auditors or internal compliance.
- Reduce storage costs by deleting outdated backups.
- Create disaster recovery backup policies that back up data to isolated accounts.
That seems to be the ticket, now how to do this.
I suggest a close review of the AWS Documentation on Data Lifecycle Manager
First of all make sure your instances and volumes are tagged properly. I suggest a minimum of the following:
|Name||A descriptive name for asset|
|Owner||Who is responsible for this|
|Expires||When can this be deleted|
|Environment||Dev, Stage, Prod|
Step 1: Login to the aws management console and search for ec2
Step 2: From the ec2 dashboard select the instance you wish to backup and select the tags tab.
Step 3: Confirm or set an appropriate tag for backups.
In this case I have set the tag Backup with the value Daily.
Step 4: Select Lifecycle Manager from the left panel of the ec2 dashboard and select create Lifecycle Policy.
Step 5a: Create the Lifecycle Policy:
I have set a basic instance based policy, for instances tagged as described prior. I have also indicated that the DLCM wizard should create a default role for creation of snapshots.
Step 5b: Create the Lifecycle Policy (Continued):
In the Schedule Section, Define a descriptive name, set the Frequency and frequency period, and execution time, and a retention period.
I have selected retention by age, and a interval of 31 days.
Note: Multiple Schedules can be applied to a policy to create a Grandfather, Father and Son rotation. (Monthly, Weekly, and Daily). This will be covered in a future missive.
Step 5c: Create the Lifecycle Policy (Continued):
One has the option to copy the tags from the source instance, and to allow DLCM to append custom tags to the snapshot. Plus one can add additional tags for operational or accounting purposes.
Step 5d: Create the Lifecycle Policy (Continued):
For purposes of disaster recovery one can copy the snapshots across regions, and for the purposes of data bunkering one can copy said snapshots into another account.
Step 5e: Create the Lifecycle Policy (Continued):
As spoken prior, one can additional policy schedules, thence review the Policy Summary, enable the policy, and create to apply.
Step 6: Notifications:
One can and should create a cloudwatch event rule and SNS topic to advise whence snapshots are created or deleted. This will be covered in a different missive.