AWS Disaster Recovery: Tips for Proper Planning

What Is AWS Disaster Recovery?

Disaster recovery is the process of restoring applications, data and hardware to ensure business continuity. An attack or disaster is always close, therefore, it is critical for every organization to have a Disaster Recovery Plan (DRP) in place. DRP is a documented, structured layout of instructions with the goal to recover disrupted systems and networks in the event of a disaster.

While this may sound fairly straightforward, you shouldn’t think of this as a static process in which you can design the plan and rest assured nothing bad will happen. Amazon Web Services defines disaster recovery as “a continual process of analysis and improvement, as business and systems evolve”.

Amazon Web Services provides its users with a set of cloud-based disaster recovery services. Organizations migrating to AWS cloud find the ability to cross-region disaster recovery very attractive, increasing the popularity of the platform.

How do you start planning a disaster recovery plan for AWS?

You should start by conducting a Business Impact Analysis to define two key metrics:

• Recovery Time Objective(RTO)—the maximum acceptable time your application or system can be offline before the data loss presents a danger for the business continuity.

• Recovery Point Objective (RPO)—the time it takes to recover your business operations after the disruption started. This metric varies according to the type of data the application uses. For example, modified user data can have an RPO of a few minutes, while infrequently modified data can have an RPO of hours.

Timeline of RTO and RPO

After defining what RTO and RPO work for your organization, the next step is to choose the disaster recovery method. AWS offers four different methods for backup and disaster recovery, which can be used in combination with each other or with third-party solutions depending on the RPO and RTO metrics.

The Cold Method

This involves periodically backing up the systems on tape and sending them off-site. Depending on what RPO you determined, you can use services such as S3, Direct Connect, or Import/Export to define backup solutions. 

Pilot Light

Using this method involves scripting the environment as a template and a minimal version of the system is running in a different region. Usually, the database is activated for data replication, such as if needed, there is a core element always ready for recovery. This core, or Pilot Light, can be scaled up in case of a disaster. Although this method reduces the RTO and RPO, it can be costly to implement. This method requires defining retention time and regularly testing the backups. 

 

Warm Standby

This method ensures a minimal recovery time by running a scaled down version of a fully functional environment. During recovery, this standby infrastructure is scaled up, updating DNS records to re-route the traffic to the new AWS. This approach reduces RTO and RPO. However, since it runs 24/7, it incurs higher costs. 

Multi-Site

This approach duplicates the environment in its totality, meaning there is always another active environment running in a different region. Usually, it involves configuring automated failover to re-route the traffic from the affected site in case of disaster. 

5 Tips for Planning Disaster Recovery for AWS

Although AWS doesn’t have a proprietary Disaster Recovery solution, it provides the users with tools they can use to create a customized recovery solution. When implementing an AWS disaster recovery plan, the following tips can come in handy: 

 
#1. Backup and Recovery are Not the Same Thing

Having recent backups of your organization’s data is essential for a successful recovery. After all, you will only recover what is safely backed up. As important as is to schedule regular backups, it is not enough. 

Automating the backups, for example by using the snapshots LifeCycle Manager, is a good practice to ensure the data is up to date. Your disaster recovery plan should include processes to access the data quickly in case of an outage or security event.

#2. Identify the Critical Data

You should conduct an audit of your assets to identify your mission-critical data and applications as part of your DR plan. At this stage, you should choose how your data will be stored, whether using snapshots or Amazon Machine Images (AMIs) for instance. 

#3. Use Cross-Region Backups

One of the most important considerations is to spread your backups geographically to avoid large-scale disasters to affect business continuity. To protect your data, you should take advantage of the AZ (Availability Zones) around the world, to keep your backups in multiple locations. A good practice could be to replicate the EBS volumes to another AZ or, better yet, to another region. This can be done simply by creating a snapshot and recreating the volume in the destination AZ from that snapshot. 

#4. Test Your Disaster Recovery Plan

This ensures you can identify any gaps and potential flaws when there is no disaster around. Therefore, you are better prepared with a well-oiled plan, even if using third-party vendors. 

#5. Consider a Disaster Recovery as a Service Solution

Most companies handle disaster recovery planning in-house. However, more organizations are opting to outsource to third-party services the implementation and maintenance of their DR plans. Disaster Recovery as a Service (DRaaS) enables companies to focus on production while their DR plan is being taken care of. 

The Bottom Line

For AWS users, it is very convenient to take advantage of the existing tools provided by AWS to build a customized recovery plan. While AWS doesn’t have a proprietary disaster recovery solution, this is compensated for by the flexibility offered to users to repurpose functions and features to create their own DR solution. In this article, I covered several considerations to keep in mind when planning your DR plan with AWS, which should help your strategy up-to-date and effective.