Amazon has shaken up the traditional concept of costs involved in backup. In the world of traditional IT, you would have to buy additional hardware capacity and get the help of an expert in order to set up a DR strategy. However, the need to invest in these measures has since been eliminated by AWS, which has directly impacted the costs involved in building robust backup operations. Instead of purchasing hardware, you can simply provision an instance and keep it in a “stopped state”, or use an AMI to provision a new instance when a disaster occurs. Your offshore backup/secondary site will be virtually cost-free, leaving you to solely consider the costs of storing and syncing your backup data.
In addition, if you need an active/active backup site, you can create a replica of the applicable production’s baseline resources and autoscale it according to demand.
In order to implement your backup policy and secondary DR site, you need to automate specific AWS building blocks. This article examines the five most important building blocks you should use to create your automated AWS EC2 backup solution.
1. EBS Volume Snapshots
Amazon EBS volume snapshots can be taken using the AWS console or CLI. As snapshots are incremental, only changes that have been made since the last backup are saved and stored in Amazon S3. Snapshot consistency is based on a method called “Copy-on-Write”, which means that write operations can be conducted at the same time a snapshot is being taken. If your system holds a write operation for a short period of time, the operation and copying process will only resume after the data has been copied.
2. Instance AMIs
An AMI is an image of your EC2 instance which allows you to provision an instance at any point in time. There is an ongoing discussion within the AWS community regarding the differences between provisioning an instance from its AMI and recovering an instance from its root device snapshot. Generally, taking an AMI without rebooting can harm consistency due to the indeterminable point in time that the AMI was taken. Recovering from an EBS instance, on the other hand, allows for better consistency, although it is not so simple with Windows instances.
3. Availability Zones, Regions, and Accounts
The familiar and most common best practice is having an offshore backup site in either a different data center or another global region. Amazon has made this a modern-day commodity by providing you with the ability to leverage its global presence. You could therefore build your secondary site in a different Availability Zone (AZ), or between regions (e.g. having your U.S. East production environment replicated in the U.S. West region). Note that When you use snapshots or AMIs the backup is stored in S3, which means it is replicated across AZs automatically. Automating backup across AWS AZs and regions are best practices, however, there is another important consideration here – the need to cross AWS accounts. It would be in your best interest to familiarize yourself with the Code Spaces breach and learn about how to protect your backup site on AWS via cross account configuration.
4. Amazon CloudFormation
CloudFormation helps you describe resources using a friendly domain specific language (DSL). Running a CloudFormation script (template) can build your whole application stack, simply, from the ground up. You can also leverage Troposphere to create scripts and easily adjust the template attributes. From a backup perspective the CloudFormation template can help with site replicas and maintenance using the update-stack command. For example, you can configure an EC2 instance’s block device mapping within the CloudFormation template. That way, you can describe the EBS volumes that are attached to the instance, find the volumes’ specific snapshot and update the stack. Check out this guide that explains how to use CloudFormation to automate your AWS backup operations.
5. Resource Tagging
AWS provides the ability to tag resources such as EC2 instances, EBS volumes, and snapshots. Tags help to streamline your backup in a dynamic cloud environment. They can be used to apply different backup policies on different tagged resource segments as well as to automatically apply policies on newly created or replaced resources. In order to accomplish this, you need to make sure that tagging is maintained and consistent across your environment.
Learn more: Tag-Based Continuous AWS Cloud Backup and DR
Final Note: The Solution
Over the last few years, we have talked with hundreds of IT professionals who run their own internal scripts and face the challenges that are associated with maintaining and continuously improving their environment by using new AWS features. We believe that backup and DR in the cloud need to be supported by a generic and purpose-built solution, which is why we built Cloud Protection Manager (CPM). Today, CPM protects hundreds of AWS-based applications, helping to streamline backups while simultaneously monitoring and validating processes behind the scenes. Ultimately, you want to be confident that your DR processes work. We welcome you to check out our backup solution in the AWS Marketplace and invite you to learn more about CPM.
Learn more: 5 Top Considerations in EBS Snapshot Automation