After evaluating the advantages of the cloud and strategies for your application migration, the next thing to consider is how to leverage cloud technology to implement/improve Disaster Recovery (DR). Resources such as AWS's whitepaper, Using Amazon Web Services for Disaster Recovery, can be helpful, but there are so many options available that it can still be hard to determine which route to take. Developing your AWS disaster recovery plan begins with identifying your goals and analyzing which approach will work best with your application setup.
2 Key Disaster Recovery Performance Metrics
According to Using Amazon Web Services for Disaster Recovery, there are two key performance metrics to consider when developing your DR plan:
- Recovery time objective (RTO): The time it takes after a disruption to restore a business process to its service level, as defined by the operational level agreement (OLA). For example, if a disaster occurs at 12:00 PM (noon) and the RTO is eight hours, the DR process should restore the business process to the acceptable service level by 8:00 PM.
- Recovery point objective (RPO): The acceptable amount of data loss measured in time. For example, if a disaster occurs at 12:00 PM (noon) and the RPO is one hour, the system should recover all data that was in the system before 11:00 AM. Data loss will span only one hour, between 11:00 AM and 12:00 PM (noon).
AWS Disaster Recovery Options
Rehosted Application
Let’s assume you recently used the “rehosting” method to migrate to the cloud, and/or your application currently uses traditional VMs in the form of EC2 instances. In this case, there are several easy ways to begin leveraging AWS features to construct a DR plan.
- EC2 EBS snapshots: A snapshot is an incremental backup of an EBS volume and one of the building blocks of any AWS DR plan. It’s relatively easy to automate snapshot creation using Lambda.
- EC2 AMIs: AMIs are like an EBS snapshot, but also include metadata for the EC2 instance so that the entire EC2 instance can be restored instead of just the EBS volume.
- Lambda: AWS’s serverless product, Lambda is the quickest and easiest way to run code outside of your application environment while still being able to access your AWS resources. Lambda can be used to automate tasks like EBS snapshot, and AMI creation.
- AWS Regions: A huge advantage of moving to the cloud is the ability to take advantage of the massive infrastructure a provider like AWS can offer. Within minutes, it’s possible to spin up servers in countries across the globe. AWS regions can be integrated into a DR plan to provide geographic diversity.
- CloudWatch: CloudWatch is a monitoring service that can be used to keep track of AWS resources and trigger actions when specific events occur. This is a terrific way to kickstart a DR plan if the primary resources become unavailable.
DR for On-Premise vs. Cloud Hosting Environments
In an on-premises hosting environment, the lower the RTO and RPO, the more expensive the DR plan will be because it requires more hardware, more frequent backups, and quicker access to both. Utilizing the cloud, on the other hand, makes it easier to have a low RTO and RPO at a cheaper cost. For example, AWS Regions provide the ability to spin-up a server anywhere within Amazon’s global network of hosting locations at no additional cost beyond the cost of the server itself. Even within a single AWS Region, Amazon guarantees there will be at least 3 Availability Zones that are in different physical locations to add another layer of redundancy. Traditionally, this kind of capability is not found in an on-premises hosting environment, or is so cost-prohibitive that only the largest of applications can afford to pay for it.
Determining which cloud features to take advantage of in your AWS Disaster Recovery plan may take a little up-front analyses, but the rewards are well worth it in the long run. If you need help customizing your cloud-based Disaster Recovery plan, 
.
