DRaaS: When the Subscription Beats Building Your Own

Disaster Recovery as a Service is one of those product categories where the marketing has gotten so far ahead of the engineering that a lot of buyers don't actually know what they're purchasing. Some DRaaS is genuinely a managed failover capability — replication, orchestration, runbooks, tested failover, real RTOs. Some DRaaS is a backup product with "DR" stenciled on the box. These are different animals with different price tags and different outcomes during an actual incident.

We've deployed both types of service, built DR sites from scratch, and cleaned up a handful of environments where somebody bought the wrong thing. Here's the honest calculus on when DRaaS beats build-your-own, and what to look for when you evaluate.

What DRaaS Actually Is (When It's Real)

A real DRaaS offering gives you four things:

1. Continuous replication of workloads from your primary environment to a provider-managed target. Block-level for VMs, log-shipping for databases, object replication for file data.
2. Orchestrated failover — a runbook, usually partially automated, that brings systems up in the right order, handles networking and IP remapping, and surfaces progress.
3. A target environment that is either pre-provisioned (warm) or spins up on demand (cold/cloud-native).
4. Regular testing, usually quarterly, that exercises the failover without disrupting production.

A provider that gives you all four is selling DRaaS. A provider that gives you only #1 is selling cloud backup and calling it DRaaS. Read the contract carefully.

Build vs. Buy: The Actual Cost Comparison

When a customer asks me "should we build our own DR site or buy DRaaS?" the honest answer is "it depends on how much you value your engineering team's time and how well you can forecast your capacity needs." But here's the math that actually matters.

The hidden costs of build-your-own

When you build your own DR site — whether that's a colo cage, a secondary office, or a self-managed cloud region — the obvious costs are hardware, software licensing, and facility fees. The hidden costs are what sink most projects:

• Engineering time for setup — 200 to 600 hours for a greenfield DR site, depending on complexity. At loaded rates, that's $30K to $90K before you've replicated a single byte.
• Ongoing operational load — patching, monitoring, certificate rotation, failover testing, runbook maintenance. Budget 10 to 20 percent of one FTE indefinitely.
• The test you don't run — the single biggest source of DR failure is not running the quarterly failover drill because your team is underwater on BAU work. A DR site that has never been failed over in production is a theoretical DR site.
• Lifecycle costs — hardware refresh every 4-5 years, software upgrade projects, OS end-of-life migrations, and the "while we're in there" work that always accompanies them.

For an SMB or lower mid-market shop, these hidden costs routinely dwarf the visible ones.

What DRaaS actually costs

A reasonable DRaaS subscription runs somewhere between 15 and 40 percent of the protected infrastructure's monthly production cost, depending on tier and RTO target. Real numbers for a 50-VM Tier 2 environment look like:

• $1,500 to $3,500 per month for backup-grade DRaaS with 12-24 hour RTO
• $3,000 to $7,000 per month for pilot-light DRaaS with 2-6 hour RTO
• $7,000 to $15,000 per month for warm-standby DRaaS with sub-hour RTO

Those numbers include replication, target infrastructure, orchestration, and testing. They don't include your WAN bandwidth to the target, which for a busy environment can add another $500 to $2,000 per month.

The break-even

For most mid-market customers, DRaaS wins on TCO up to roughly 200 VMs. Past 200 VMs, the per-VM subscription economics start to tilt toward build-your-own, particularly if you already operate a secondary site for other reasons. Below 50 VMs, DRaaS wins on TCO by a wide margin — you cannot efficiently staff a DR capability for a small environment.

When to Buy

DRaaS is the right answer when you have:

• A small IT team that cannot absorb the operational load of DR without dropping something else
• Unpredictable or growing workloads where capacity planning on dedicated DR hardware is a guessing game
• Compliance requirements that force documented, tested DR capability — DRaaS providers include testing artifacts in their deliverables, which satisfies auditors with less internal work
• A single primary site with no natural secondary — retail, professional services, healthcare, small manufacturers
• Recent ransomware fear and an executive who wants the problem off their desk in 60 days, not 6 months

When to Build

Build your own DR when you have:

• Existing secondary infrastructure you can repurpose — a regional office, a research facility, a second colo
• Specialized workloads that DRaaS providers won't touch cleanly — mainframe, custom appliances, HPC clusters, anything with hardware dependencies
• Extreme data gravity — petabyte-scale environments where replication bandwidth costs make DRaaS economically painful
• Strict data sovereignty requirements that limit which providers can host your replicas
• A mature IT ops team with the headcount and discipline to run failover testing on a real cadence

What to Look For in a DRaaS Contract

When you do evaluate DRaaS, here's the short list of things that separate a real offering from a skinned-up backup product.

RTO and RPO commitments — with teeth

Ask the provider to commit to specific RTO and RPO numbers, in the contract, with a meaningful penalty for missing them. Vague "best effort" language means you are paying for hope. Good providers will commit. Great providers will offer credits or refunds when they miss — because they have confidence in their architecture.

Testing cadence and documentation

At least quarterly testing, included in the base subscription, with written test reports you can hand to auditors. If testing is an extra-cost add-on, the provider is effectively telling you they don't want you to test. Walk away.

Failback procedure

Getting back from the DR target to your primary is the half of the operation most customers don't think about until they're in it. Ask what failback looks like, how long it takes, what the bandwidth requirements are, and what the process costs. "We'll figure it out when the time comes" is not an acceptable answer.

Shared-responsibility clarity

Who is responsible for runbook maintenance as applications change? Who updates the order-of-operations when you add a new database? Who owns certificate renewals on the replica infrastructure? Get the answers in writing. The gray zone is where incidents go sideways.

Exit strategy

Can you get your data back if you leave? In what format? On what timeline? At what cost? Every DRaaS contract should have a reasonable exit clause. The ones that don't are traps.

The Honest Take

DRaaS is the right answer for most mid-market organizations most of the time. The math works, the operational burden is lower, and the testing discipline is better than what you'll achieve in-house.

It is the wrong answer when you already have the secondary infrastructure, the specialized workloads, or the team to do it well. It is also the wrong answer if you buy a backup-grade product and expect warm-standby outcomes.

Read the contract. Test the failover. Know your exit. If all three of those hold up, buy the subscription and put your engineers on something else.