DRaaS Targets: How to Decide Where to Send Your Data

Author: Jeff Ton
Compliance
hexpattern-2
hexpattern-2

You’ve made the decision to modernize your disaster recovery solution with Disaster Recovery as a Service (DRaaS); now what? The next question you face is where to send your data. You could send it to one of your other datacenters, but then you aren’t really taking advantage of the “as a Service” part of DRaaS. To gain the full benefit of these technologies, your target should be a cloud, but which one?

Deciding Between Public Cloud vs. Hosted Cloud

The choice between targeting DRaaS to a public cloud, like Amazon Web Services (AWS) or Microsoft Azure, and a hosted cloud in a third party’s datacenter often depends upon a number of factors, such as cloud strategy, recovery time, environment size, and cost. Each environment has its own advantages and disadvantages. InterVision’s DRaaS offering allows clients to select between using AWS as a target or our own hosted cloud environment. The answer to which one is right for you depends upon these unique areas:

Cloud Strategy

The first question to ask yourself is “What is our cloud strategy?” In other words, do you have plans to migrate workloads into AWS in the next three to five years? If the answer is yes, leveraging DRaaS to AWS provides an excellent first step.

One of the challenges organizations face on their cloud journey is the skills of their teams. Operating your environment in the cloud is vastly different than operating it in your own datacenter. Moving from the world of physical infrastructure, even if you are heavily virtualized, to the cloud world of software-defined infrastructure will be a significant skill set and mindset shift.

Using your disaster recovery instances as a way to get acclimated to this new way of thinking will help to prepare your organization for the journey ahead. If some of the disadvantages discussed below, such as recovery time, have you leaning away from this option, consider that the replication tools (the tools that move the data between your datacenter and the cloud or hosted environment) enable you to send your data to both at once. Giving you the shortened recovery time you need and a recovery instance in the cloud to study and learn.

Recovery Times

The next question to ask is “How quickly do I need to recover”? Your recovery time objective (RTO) will certainly help drive the architecture of your DRaaS solution. Of course, RTO can be impacted by a number of factors (e.g., number and size of VMs being recovered), and recovery into a hosted cloud environment can be accomplished as much as eight times faster.

For example, recovering 100 average-size virtual machines (VMs) into an AWS environment could take 2-3 times longer due to the conversion that must take place to enable those VMs in your datacenter to run in the AWS-proprietary VM format. In contrast, failing over into a hosted environment that’s been matched to the source side often means a faster uptime.

This difference in recovery times can be reduced by adding additional appliances into the environment, which enables more VMs to be recovered simultaneously. The tradeoff of this approach is cost. The more appliances, the faster the recovery—but the higher the cost.

Cost

When considering DRaaS solutions, it is difficult to beat the cost of AWS. This is especially true in the replication stage, due to the low cost of storage within AWS. In a hosted solution, the cost of storage will be higher, and for larger environments this difference can be significant.

Many hosting providers, including InterVision, charge a reservation fee for the resources you will need at the time of recovery. These fees cover the CPU, memory, and storage required to run your environment in production mode. AWS’s size and breadth provide them with enough scale that they do not charge reservation fees.

On the flip side, during a recovery test, the CPU, memory, and storage required to test the recovery in a production-like mode are typically waived by a hosting provider for some specified period of time. Those costs can add up quickly on AWS if they are not managed appropriately.

Complexity

Another factor to consider is the complexity of the environment. Complexity can be related to the size of the environment as well as the types of workloads being recovered. Does your environment include hardware outside the x86-family, such as mid-range or mainframe compute platforms? Are there integrations between applications that will require some equipment to be in a colocation adjacent to the recovery target? Are there unique databases or applications that require custom recovery solutions? Are you under certain compliance or governance constraints that limit your target options? These are all questions that will help determine which cloud target is best suited for your business.

Other factors

All of the factors above may tilt the decision in one direction or the other. There may be other factors that drive the decision. For example, if you have virtualized using VMware as your platform, targeting AWS may mean that, in a disaster declaration scenario, you may not have the skills you need to operate and manage your recovered production environment. Targeting a hosted cloud will mean your team could likely use tools they are familiar with while you are in a recovery state.

Another significant factor in the decision may be the geodiversity of the workloads and the associated data sovereignty requirements that may be in place. Targeting AWS provides a global reach. Most data can stay “in-country,” but it may drive the need for a hybrid solution, using AWS for some of the geo-diverse workloads, and the hosted cloud for the remainder.

Deciding which target or targets are right for you can be complex. As you have seen, some of the factors end up being tradeoffs, speed vs. cost for example. To learn more, visit some of the resources below, or reach out to your account executive at InterVision here.

Additional Resources:

BaaS vs. DRaaS: 3 Key Differences to Know

The Ultimate Guide to DRaaS

Resolving Ransowmare Incidents with DRaaS

DRaaS to AWS
Learn more