Securing Your Data: Amazon Data Lifecycle Manager

What is Amazon Data Lifecycle Manager?

Amazon Data Lifecycle Manager is known for an automated process that creates backups of data stored in the Amazon EBS volume.

• It secures our important data by scheduling regular backups.
• It helps to reduce the cost of service by deleting the backups which are outdated.
• It creates disaster recovery backing-up policies, which backup the data to isolated accounts.
• It creates the AMI’s in a standardized manner which can refreshed at regular intervals.

Why we need Amazon DLM

Data security and confidentiality

The economic value of data given in both regulated markets and in black markets must be safe against cybercriminals. This is very important in terms of regulations like the European GDPR or personal data.

Availability at all times

It is also necessary for the data to be available whenever it is needed. They are protecting points on disconnected networks if they are not available when they need to be used. Due to this reason cloud solutions are becoming more and more popular.

Long-term structural integrity

Simultaneous access by various users to a database, or different data backups in secure environments, will affect the long-term integrity of data with data duplication errors. These need to remain stable regardless of how they are used.

Considerations

• Unless you set the activation status to “enable”, the policy cannot create snapshots or AMIs. We can configure the policy to be enabled during creation.
• After specifying a start time, the operation of the first snapshot or AMI creation starts within one hour.
• If you modify a policy by deleting or changing its target tags, the EBS volumes or instances with those tags are no longer managed by the policy.
• The snapshots or AMIs that are created under the old schedule name are no longer affected by the policy if you change a schedule name for a policy.
• When you modify the time-based retention schedule to use the new time interval, the new interval is used only for new snapshots or AMIs created after the change. Before the change, the new schedule doesn’t affect the retention schedule of snapshots or AMIs which are created.
• You can’t change the retention schedule of a policy from count-based to time-based after creation. To make this change, you will have to create a new policy.
• If you delete the resource to which a policy with count-based retention applies, the policy no longer manages the previously created snapshots or AMIs. You will have to delete the snapshots manually or deregister the AMIs if they are no longer needed.
• If you delete the resource to which a policy with age-based retention applies, the policy continues to delete snapshots or deregister AMIs on the defined schedule, up to, but not including, the last snapshot or AMI. You should delete the last snapshot manually or deregister the last AMI if it is no longer needed.
• We can create multiple policies to back up an EBS volume or an EC2 instance. For example, if an EBS volume has two tags, i.e., tag A and tag B, where tag A is the target for policy B to create a snapshot at every 12 hours, and tag B is the target for policy B to create a snapshot at every 24 hours, Amazon DLM creates the snapshots as per the schedules for both policies. Additionally, you can achieve the same result by creating a single policy that has multiple schedules. For example, you can create a single policy that targets only tag A, and specify two schedules, i.e. one for every 12 hours and another one for every 24 hours.
• When we create the policy that targets instances, and new volumes are attached to the instance after the policy has been created, the newly added volumes are included in the backup at the next policy run. All volumes attached to the instance are included at the time of the policy run.
• IF the AMI retention threshold is reached, the oldest AMI is deregistered, and its backing snapshots are deleted for the AMI lifecycle policies.
• If a policy with a custom job-based schedule and age-based or count-based retention rule is configured to create only a single snapshot or AMI, the policy will not dynamically delete that snapshot or AMI when the retention threshold is reached its limit. You must manually delete the snapshot or deregister the AMI if it is no longer needed.

Structure of EBS Snapshot Replication

Prerequisites:

• Have an AWS account.
• An instance should be created and launched.
• Disks and volumes to be attached to that instance.

How to automate Amazon EBS Snapshots using DLM

Avoid Contact Center Outages: Plan Your Upgrade to Amazon Connect

Learn the six most common pitfalls when upgrading your contact center, and how Amazon Connect can help you avoid them.

Get the Guide

1. Initially, we have to go to the EC2 console and in the navigation pane choose Elastic Block Store, Lifecycle Manager, and then choose to Create lifecycle policy. On the Select policy type screen, you will need to select the EBS snapshot policy and then click Next.

2. After that, we have to denote the Target Resources as Volume or Instance. In Volume, we have to select the particular or specified volume or disk name. Whereas if we select Instance, then it will select the multiple disks or volumes attached to the selected instance.
   • In our scenario, we are selecting the volume name “test.”

• • Then select the IAM role on the same page and click next.

3. As shown above, you will have to schedule the selected volume as per our requirements. Here we are selecting 1 hour and the retention snapshots we are keeping are 2 numbers. i.e., it will show the latest 2 snapshots of that volume. Then click review policy.

4. In step 4, we can see and review the lifecycle policy we configured and then click create policy.

Output

This is the final output of the Lifecycle and the two snapshots are created for the disk we have selected.

Finalizing your DLM setup:

Here we have created the two EBS snapshots with the Data Lifecycle Manager for the backup. We have automated the snapshot of the EBS volume of an instance, where we can also select the instance having multiple disks for creating snapshots/backups. Additionally, we can schedule the DLM of the volume for keeping the data in latency and set our retention period for the previous backup as well. As a result, we got two snapshot backups of the volume with the previous one getting overwritten automatically.  If you have followed these steps and workflows you should now have been able to successfully configure the Data Lifecycle Manager.

How can Perficient help you?

Perficient is a certified Amazon Web Services partner with more than 10 years of experience delivering enterprise-level applications and expertise in cloud platform solutions, contact center, application modernization, migrations, data analytics, mobile, developer and management tools, IoT, serverless, security, and more. Paired with our industry-leading strategy and team, Perficient is equipped to help enterprises tackle the toughest challenges and get the most out of their implementations and integrations.

Learn more about our AWS practice and get in touch with our team here!