Always-On VMs: The DR Strategy That Fails Less and Costs Less

In Why Disaster Recovery Tests Should Fail, we made the case that a failed DR test is a gift. Every gap it exposes is a gap you fixed before a real disaster found it for you. But there is a follow-up question worth asking: what if you could design your recovery environment so that entire categories of failure never show up in the first place?

That is the case for always-on VMs, and it is as much a financial argument as a technical one.

Where DR Tests Actually Fail

Run enough recovery tests and the same culprits appear again and again. It is rarely the data. Replication technology is mature, and the bits almost always arrive intact. What breaks is everything around the data:

• Domain controllers that boot out of sequence, leaving applications unable to authenticate
• DNS that resolves to addresses that no longer exist
• Boot storms, where dozens of VMs power on at once and dependency ordering falls apart
• Configuration drift, where the recovery environment no longer matches the production environment it is supposed to mirror

These are cold-start problems. They exist because most DR environments spend their lives powered off, waiting for a declaration. Every hour those systems sit dark, the odds grow that something has drifted, expired, or fallen out of order.

What “Always-On” Means in Practice

An always-on approach does not mean running a full duplicate of production around the clock. It means building what we at US Signal call a pilot light environment to run a small, deliberate set of always-on VMs. A pilot light is more than a handful of running VMs. It is a recovery environment with networking, routing, firewall policies, VLANs, and connectivity already configured to assume production traffic. Like the flame in a furnace, it stays lit so the rest of the environment can come online immediately. The always-on VMs running inside it typically include:

• Active Directory domain controllers
• SQL servers, running as a secondary replica in an availability group so the database tier is already synchronized and ready to take over
• Virtual networking devices such as firewalls, routers, and load balancers, so the recovery site’s network fabric is live and validated at all times
• DNS and DHCP services
• Monitoring and management tooling

Everything else continues to replicate and stands ready to power on. The difference is that when those workloads come up, they land in an environment that is already authenticated, already resolving names, and already observable. The pilot light turns a cold start into a warm one.

The Cost Math

The instinct is that always-on VMs cost more. You are, after all, paying for compute that runs continuously instead of sitting idle. Look at the full picture and the math flips.

Downtime is the biggest DR cost, and always-on VMs attack it directly. Industry research consistently puts the cost of an hour of downtime for mid-size and large enterprises at six figures. The slowest, most failure-prone part of any recovery is standing up core services and untangling dependency order. When that foundation is already running, recovery time objectives shrink from hours to minutes. A modest monthly compute charge is cheap insurance against a six-figure outage hour.

Failed tests have a price tag too. Every DR test consumes staff time, and every failure triggers a remediation cycle: root-cause the issue, fix it, schedule a retest, pull the team back in. When the usual suspects (authentication, DNS, boot order) are already live and continuously validated, tests get shorter, pass more often, and cost less to run. You still want tests that probe hard enough to fail. You just want them failing on new problems, not the same cold-start issues every quarter.

Always-on beats building a second site. The traditional answer to fast recovery was a duplicate data center: hardware, power, cooling, maintenance contracts, and refresh cycles for infrastructure you hope to never use. Running a pilot light environment in the cloud delivers the recovery-speed benefit of a hot site at a fraction of the cost, with no capital outlay and no idle hardware depreciating in a rack.

Always-on VMs can earn their keep. A live domain controller at the recovery site is not just DR insurance. It is a legitimate secondary AD site improving authentication resilience every day. Live monitoring at the recovery site gives you an out-of-band view of production. The line between “DR expense” and “operational asset” starts to blur, in your favor.

Ask Your Application Vendors About High Availability

Here is a step many organizations skip: talk to your application vendors about what a highly available install of their product looks like, then spread that architecture across two data center locations.

Times have changed. A few years ago, running an application active-active across two sites meant custom engineering, third-party clustering tools, and a licensing bill that made the whole idea a non-starter. Today, a growing number of applications support multi-site high availability natively, with replication, failover, and quorum logic built into the product. Just as important, many vendors no longer charge extra for those always-on features. Capabilities that used to sit behind an enterprise license tier are now included in the standard product.

The practical move is simple: for each critical application, ask the vendor two questions. What does your recommended HA deployment look like across two sites? And what does it cost today? You may find the answer has changed since you last asked.

Modern DR Is a Blend, Not a Single Strategy

Even with that shift, not everything belongs in an active-active design. Some applications still do not support it. For others, the licensing cost of a second active node is more than the application’s RPO and RTO requirements justify. If a workload can tolerate four hours of downtime, paying a premium to make it continuously available is spending money the business case does not ask for.

That is why real-world disaster recovery ends up as a blend of three approaches, each matched to what the workload actually requires:

• Active-active for the applications that natively support it and whose availability requirements justify it. These workloads run in both data centers and never get “recovered” at all. They simply keep running.
• Recovery from replication for workloads that need fast recovery but not continuous availability. These VMs replicate to the second site on RPOs measured in minutes and power on into the pilot light environment when needed.
• Recovery from backups for everything else. Workloads with relaxed RPO and RTO requirements restore from backup, at the lowest protection cost in the portfolio.

The RPO and RTO requirements decide the tier, and the tier decides the cost. Protecting a workload one tier higher than it needs wastes budget. Protecting it one tier lower risks the business. Getting each workload in the right tier is where a DR strategy earns its money.

Right-Sizing Is the Whole Game

The blended approach works because it is selective. Run the foundation continuously (identity, database replicas, networking), stretch the applications that support and justify active-active across both sites, replicate what needs fast recovery, and back up the rest. That balance gives you:

• Near-instant availability for the services everything else depends on
• Applications that fail over on their own, with no recovery step at all
• Pay-for-what-you-replicate economics on the fast-recovery tier
• Low-cost backup protection for workloads that can wait
• A recovery environment that is continuously proven, not periodically discovered

This is the model we commonly help customers build on US Signal’s OpenCloud and ReliaCloud platforms. Your pilot light environment and active-active workloads run live across our data centers on the platform that fits your environment, your fast-recovery workloads replicate through DRaaS on RPOs matched to their criticality, and BaaS covers the backup tier. Because both platforms run in multiple US Signal data centers, you can spread active-active applications across two sites and place your pilot light environment opposite production. Our team helps you decide which systems belong where. And because we build testing into every DR engagement, you will still get the failures that matter, the ones that teach you something new.

The Bottom Line

Disaster recovery is no longer a choice between an expensive hot site and hoping backups are enough. Modern platforms let you mix active-active applications, pilot-light infrastructure, replication, and backups into a design that matches the needs of each workload. The result is faster recovery, lower cost, and fewer unpleasant surprises during testing.

Want to see what a blended recovery design looks like for your environment? Talk to a US Signal solution architect and we will map your workloads to the right tiers together.