Skip to main content

If you’re like most companies that operate in regulated industries, “compliance” is a word that you’re intimately familiar with. And if you’ve migrated (or are migrating) your IT environments to the cloud, you’ve likely brought much of your compliance regime with you.

But you migrated to the cloud to improve your agility and to focus on innovations that strategically differentiate your business. Your pre-existing compliance program is likely not aligned. Luckily, it doesn’t have to be that way.

In this article, we’re going to dig in on compliance requirements for business continuity, and discuss how disaster recovery needs to be rethought in the cloud to achieve the promise that brought you to the cloud in the first place.


We’re fond of acknowledging that there’s a lot of hype around the cloud. The name “cloud” says it all – it’s an ethereal place, existing somewhere in the heavens.

But the cloud consists of a bunch of data centers, located right here on planet earth. That’s probably pretty similar to the situation you had with your on-premises data center. Nothing there has fundamentally changed.

Business continuity hasn’t fundamentally changed either. We still need to apply a business lens to identify risks that could impair our ability to operate. We still need to evaluate our applications and understand what our recovery point objectives and recovery time objectives should be. We still need to implement technologies and processes that enable us to recover from these risks should they materialize.


When you moved to the cloud, you embraced an entirely new technology stack. Your servers now run on a different hypervisor. Your network is now 100% software defined. Your data now lives in a service named “block store” or “object store.”

Your on-prem DR strategy and tools weren’t built for this new world. A different approach is required.


Most compliance regimes are as concerned with business continuity planning as with the solution. You need to show that you’ve assessed your risks, you’ve mitigated the important risks, and you’ve periodically tested your DR solution.

Those risks come in 2 flavors: downtime and data loss. Your compliance regime requires that you assess the business impact of both, and you mitigate as appropriate.

And while downtime and data loss have many forms, it’s typically unnecessary to get into those weeds. We’re looking for general-purpose solutions here.

In the cloud, that boils down to 2 capabilities:

  1. The ability to operate important applications in multiple regions
  2. The ability to restore data from secured (locked-down) backups

So, that’s what you need to accomplish. And that’s what you’ll need to test.


Remember your motivation for moving to the cloud? It’s part of transforming your business. It gives you the agility to execute faster. And you need compliance solutions that are aligned.

For DR, that means automation. Nothing kills agility like maintaining and practicing an 80 page recovery runbook. You need those 80 pages boiled down to a couple of mouse clicks that launch a process that handles the details for you. The cloud was built with automation as a first principle. To maintain agility and streamline compliance, you must leverage it here.


Fundamentally, business continuity as a concept doesn’t change in the cloud. But your on-prem DR solutions don’t apply for your new technology stack. And your updated solutions need to be engineered to achieve the agility you were seeking when you moved to the cloud.


Arpio is an automated disaster recovery solution for applications that run in AWS. If you need comprehensive business continuity for your AWS environment, but you don’t want to build it yourself, Arpio’s got your back.