CloudFormation (CF) is an AWS service that allows you to treat a collection of AWS resources as one logical unit. According to AWS:
AWS CloudFormation gives developers and system administrators an easy way to create and manage a collection of related AWS resources, provisioning and updating them in an orderly and predictable fashion.
Generally, a typical, scalable web application structure would use a wide variety of AWS services. It may use EC2 instances for application and database hosting, ELB for load balancing, Auto Scaling for scale management, AWS RDS and DynamoDB as databases, as well as S3 and Glacier for storage. In this world of rapid development, users may need to set up their AWS environments again and again for development and testing purposes, which can be tiresome and inaccurate if done manually. However, there is an alternative. CloudFormation provides an easy and structured option that allows you to create and delete these AWS resources and provision them in an orderly fashion. In this article, we will show you how CloudFormation can support your backup and recovery needs when incorporated with structured and automated backup policies.
Using CloudFormation
The collection of resources that is provisioned using CloudFormation is called a CloudFormation stack. You can create a stack using the CloudFormation template, which allows you to configure everything from a specific load balancer policy to autoscale properties, security groups, instance types, image IDs, and so on. The CloudFormation template is written in JSON format and when executed, it creates AWS resources and installs the applications/services as part of the stack. The pre-existing template allows you to launch the same setup very easily. The biggest advantage of the CloudFormation template is that you can create it once and run it as many times as needed. It allows you to launch instances as well as other AWS resources as part of the stack. Once a stack is created, it may need to be updated, say if you apply new security patches, version upgrades, bug fixes, change instance sizes, and so on. Therefore, AWS CloudFormation allows you to change or modify a stack based on specific changes made in the template via the “update-stack” function.
Updating Your CloudFormation Stack
When updating a stack, it is possible to interrupt an application that is currently running in production. The three production scenarios below exemplify what could happen during a CloudFormation stack update:
- In the case of a minor update, such as a CloudWatch alarm update or AutoScaling policy changes, it is possible that no interruption will occur.
- A slight interruption may occur if users update instance properties, such as changing instances to EBS-Optimized, or modifying instance types. These cases may interrupt application performance due to rebooting or relaunching the instance.
- In some cases, updating the stack replaces existing resources, such as changing DNS names or new physical IDs. For example, updating an AMI or self-hosted database on an EC2 instance or managed database, like RDS, will most likely result in downtime, causing an interruption in the application. These types of updates should be planned during off hours.
Now, in some cases you can avoid slight interruptions or replacement conditions with proper planning. For example, in order to update EC2 instances or AMIs, you should create a stack with Auto Scaling, then update the Auto Scaling launch configuration in the CloudFormation template. When you call “update-stack”, Auto Scaling will launch an EC2 instance from a new AMI, but will not bring down instances that are already running. You will be able to gradually remove the old instances to ensure your production environment does not experience interruptions. There are specific cases in which the situation above may not work. For example, when modifying a complete application stack, changing RDS DNS, some components require persistent data (e.g. database instances). To prevent components from failing, such as EC2 database instances and RDS, a reliable and consistent backup is needed before performing any updates or modifications in the CloudFormation template.
Recover and Restore Data with CloudFormation
When creating an EC2 instance, you can configure block device mapping with a CloudFormation template. This way, you can describe the EBS volumes that are attached to the instance, find the specific snapshot of those volumes and then update the stack. This will terminate the original ones and launch new instances from the snapshots. If you create an instance with CloudFormation, all you have to do is merely update the template and the rest will be taken care of for you. While using CloudFormation, N2WS can configure your backup operations based on updates and changes to the CloudFormation stacks. This may be required, for example, if a template runs in ten different places or there are ten different stacks or stack types. You can enable this automation using N2WS Tag-Based Backup feature. This feature allows you to create a special tag as part of your CloudFormation stack, that is automatically detected by N2WS and triggers the necessary updates to N2WS backup policies. In the event of data loss, be it with an AWS-managed or EC2-hosted database, it is only natural to revert back to a previous version. With an RDS database, for example, if an attacker or bug wipes half of the database clean, it is imperative to be able to go back to a former stable state of the database. Database snapshots that were taken before the crash allow a former version of the database to be recovered.
Example Scenario
Let’s demonstrate the power of a N2WS backup with CloudFormation using a step-by-step scenario. Let’s say that there is an EC2 instance that is running MongoDB or a MySQL database as part of a CloudFormation stack. With the CloudFormation template, you can add a tag for EC2 backup, using the template language to describe a new instance. The new instance will be created once the stack is launched. N2WS can then detect the new instance based on its tag, add it to the policy and back up automatically. If you want to recover data in a way that is not fully automated in CloudFormation, you can easily revert to the backup you want to recover in N2WS and grab the snapshot IDs from the snapshot list window (a detailed and visible list of the snapshots as shown below). Once you update your CloudFormation template with the snapshot IDs, call on update-stack to finish the recovery process for you. N2WS Snapshot List – If an old instance is terminated, a new instance ID will be created with the new data. Since the two instances have the same tag, N2WS will detect that the old instance no longer exists and will stop trying to back it up, moving its efforts to the new instance, instead. Therefore, your database will continue to be backed up. The backup will not be harmed, regardless of the circumstances, creating a reliable, continuous process. Launching another stack from the same template, provided the tags are available, will result in a similar automated N2WS reaction, and will be backed up in this manner as well. In every possible way, CloudFormation, together with N2WS, provides an easy and reliable way to continuously backup and restore your application’s data, as needed, in the AWS cloud.
Now that we’ve delved into AWS Cloudformation and the result of updating your stacks, in our Part 2 of this series, we’ll show you how tag based backup using N2WS Backup & Recovery will help you plan your AWS Cloudformation template updates.
N2WS Backup & Recovery is an enterprise-class backup solution built from the ground up for Amazon EC2 as it leverages EBS & RDS snapshots. It supports consistent application backups on Linux as well as Windows servers. N2WS is sold in the AWS Marketplace and can be trialed for 30 days. After the trial period, automatically upgrade to our Forever Free Edition.
