New Whitepaper: Using AWS for Disaster Recovery

Disaster recovery (DR) is one of most important use cases that we hear from our customers. Having your own DR site in the cloud ready and on standby, without having to pay for the hardware, power, bandwidth, cooling, space and system administration and  quickly launch resources in cloud, when you really need it (when disaster strikes in your datacenter) makes the AWS cloud the perfect solution for DR. You can quickly recover from a disaster and ensure business continuity of your applications while keeping your costs down.

Disaster recovery is about preparing for and recovering from a disaster.  Any event that has a negative impact on your business’ continuity or finances could be termed a disaster.  This could be hardware or software failure, a network outage, a power outage, physical damage to a building like fire or flooding, human error, or some other significant disaster. 

In that regard, we are very excited to release Using AWS for Disaster Recovery Whitepaper. The paper highlights various AWS features and services that you can leverage for your DR processes and shows different architectural approaches on how to recover from a disaster. Depending on your Recovery Time Objective (RTO) and Recovery Point Objective (RPO) - two commonly used industry terms when building your DR strategy - you have the flexibility to choose the right approach that fits your budget. The approaches could be as minimum as backup and restore from the cloud or full-scale multi-site solution deployed in onsite and AWS with data replication and mirroring.

The paper further provides recommendations on how you can improve your DR plan and leverage the full potential of AWS for your Disaster Recovery processes. 

Download Whitepaper (PDF) - (more whitepapers available at http://aws.amazon.com/whitepapers)

AWS cloud not only makes it cost-effective to do DR in the cloud but also makes it easy, secure and reliable. With APIs and right automation in place, you can fire up and test whether you DR solution really works (and do that every month, if you like) and be prepared ahead of time. You can reduce your recovery times by quickly provisioning pre-configured resources (AMIs) when you need them or cutover to already provisioned DR site (and then scaling gradually as you need). You can bake the necessary security best practices into an AWS CloudFormation template and provision the resources in an Amazon Virtual Private Cloud (VPC). All at the fraction of the cost of conventional DR. 

How are you using the cloud for Disaster Recovery today? Please do share your general feedback about DR and any feedback regarding the whitepaper that you might have.

- Jinesh

Comments

[T.Pham]

Do you have a warranted recovery time objective on your cloud disaster recovery offerings?

[Brian Adler]

Hi Jinesh,
Thanks very much for the info provided here. After reviewing the white paper, what I don’t see are recommendations on configuring a DR environment in AWS in which the primary environment is also in AWS. The paper discusses the on-premise scenario with the DR environment in the cloud, which is obviously a viable use case, but the majority of customers we talk to about a disaster recovery solution (full disclosure: I am an Architect in the Professional Services group at RightScale) are running in AWS and want to set up a DR environment in another AWS region. Currently there aren’t any easy ways to replicate a database between two AWS regions – if you use a relational database in EC2 (for example, and of those discussed in the link on page 7), you are most likely going to be using EBS volumes for your datastore. The snapshots you take of these EBS volumes are not portable across regions, nor are they discoverable as objects in an S3 bucket so they could be copied to another bucket in a different region. Similar constraints exist with RDS in that EBS volumes are used for storage (so similar issues exist with regard to the snapshots and their portability), and there is currently no way to configure a slave to replicate from an RDS instance, so keeping a database replica current in another region is not really possible if using RDS. We have tips and tricks we have used to enable database replication for both ourselves and our customers, but given some of the AWS region-portability constraints, we find it challenging to provide an optimal solution 100 percent of the time. I think this white paper is a great start, but it would be really useful to see additional details on recommendations and best practices for setting up an AWS region as a DR environment for another AWS region. Thanks again for the post and the white paper, as the information provided is indeed relevant for some use cases.
- Brian Adler, PS Architect, RightScale

[Scott McDonald]

Hi Brian,

FWIW - it can be done easily with traditional lamp stacks running as persistent instances. MySQL master/master replication can be setup between 2 servers in different AWS regions - combined with simple automated recurring rsync's to keep static web content (from user uploads etc...) in sync between the two AWS regions. Combined with DNS failover techniques to provide HA - it works great.

I'm not a proponent of using multiple AWS regions for HA though. I think it is much better to have HA setup between a cloud in a single AWS region and a cloud from a completely different vendor (i.e. Linode or Rackspace). Vendors have vendor wide issues. Best to have redundant vendors in your HA setups as well. That's what I do with DNSHAT.com and what I recommend for DNSHAT.com failover clients that are looking to automate failover between different cloud systems.

Thanks,
Scott McDonald - Founder - DNSHAT.com