As opposed to traditional infrastructure deployment on-premises, the cloud lets you take a much more dynamic approach to DR. It frees you from the capital investment that you need to make on-premises to provision DR infrastructure. It also makes DR infrastructure readily available for you to speed up recovery; thus, you can focus on designing a solution to meet your RTO and RPO requirements.
Your options to deal with a disaster in AWS can be mapped onto four major DR strategies: backup and restore, pilot light, warm standby, and active-active. The idea in each case is to be able to restore or continue operating your workload in a second Region. The cost and complexity of the various strategies range from lower (backup and restore) to higher (active-active), as shown in the following diagram:
Figure 7.1: DR strategies cost and complexity
The following sections will take you through each strategy in detail.
This is the easiest mechanism you can use. It is also the least expensive of the four. The idea is to simply take a backup of your workload where it operates in Region A. Then, you somehow transfer that backup at regular intervals to the location where you intend to restore your workload in case of a disaster. Thus, if you are planning to handle a disaster that would impair your workload in Region A, you should look at restoring it from the most recent backup available in Region B and start operating in Region B. This approach is illustrated in the following diagram:
Figure 7.2: Backup and restore approach
Now, the preceding description is overly simplified on purpose. There are many details that will need to be addressed along the way, but if it satisfies your RTO and RPO requirements, this is a good solution and likely your best option.
The following sections describe a few considerations to be noted before defining your backup strategy.
Re-Building or Backing Up Everything
The first consideration to make is about what exactly you should back up. AWS lets you fully automate your workload deployment using a combination of infrastructure as code (IaC) and automated deployment. This is considered best practice. First, it allows you to gain agility and speed in your development life cycle. Secondly, it reduces your deployment risks and, at the same time, paves the way for deploying your workload anywhere. There are a few caveats before you can really deploy in any Region, but nothing too complex to handle. You will particularly need to pay attention to the resources you refer to in your automation templates and scripts.
For instance, when referring to an Amazon Machine Image (AMI) for deploying EC2 instances, you need to make sure to use the correct AMI ID for the Region where the automation runs (an AMI copied in multiple Regions will have a separate AMI ID in each).
Once you have automated the creation of your AWS infrastructure and deployment of your workload, then all you have to back up is your data.