On-premises DR to AWS - AWS Prescriptive Guidance

On-premises DR to AWS

Using AWS as an offsite DR environment for on-premises workloads is a common hybrid scenario. Define your DR objectives, including the required recovery time and recovery point objectives, before selecting technologies to use. To help with this definition, you can use the DR plan checklist.

There are a number of options available to help you quickly set up and provision a DR environment on AWS. Be sure that you account for all your workload dependencies, and test your DR plan and solution thoroughly and regularly to verify its integrity.

AWS provides CloudEndure Disaster Recovery for creating a full replica of your on-premises servers, including the root volume and operating system, on AWS. CloudEndure Disaster Recovery continuously replicates your machines into a low-cost staging area in your target AWS account and preferred Region. The replication includes operating system, system state configuration, databases, applications, and files. If there is a disaster, you can instruct CloudEndure Disaster Recovery to automatically launch thousands of your machines in their fully provisioned state in minutes.

CloudEndure Disaster Recovery uses an agent installed on each of your on-premises servers. The agents synchronize the state of your on-premises servers with lower-powered Amazon EC2 equivalents running on AWS. CloudEndure Disaster Recovery automates your DR failover process. It also automates and coordinates the failback process, enabling you to achieve lower recovery times.

                Diagram of a corporate data center and an environment on AWS, using CloudEndure Disaster Recovery.

It is important to test the DR process and to verify that the live staging environment does not create conflicts with the on-premises environment. For example, confirm that the appropriate licenses are available and functioning in your on-premises, staging, and initiated DR environment. Also confirm that any worker type processes that may poll and pull work from a central database are configured appropriately to avoid overlaps or conflicts.

You can use a AWS Storage Gateway volume gateway to provide your on-premises servers with cloud-based volumes. These volumes can also be quickly provisioned for use with Amazon EC2 using Amazon EBS snapshots. In particular, stored volume gateways provide your on-premises applications with low-latency access to their entire datasets. The volume gateways also provide durable snapshot-based backups that can be restored for on premises use or for use with Amazon EC2. You can schedule point-in-time snapshots based on the RPO for your workload. It is important to note that volume gateway volumes are intended to be used as data volumes and not as boot volumes.

                Diagram of a corporate data center using a gateway virtual machine, with snapshots stored on AWS.

You can use an Amazon EC2 AMI with a configuration that matches your on-premises servers and specifies your data volumes separately. After you configure and test the AMI, provision the EC2 instances from the AMI along with the data volumes based on the volume gateway snapshots. This approach requires you to test your environment thoroughly to verify that your EC2 instance is operating properly, especially for Windows workloads.

You can also use the AWS Server Migration Service to create AMIs from your existing on-premises VMs. You can then customize and configure them with appropriate data backup and restore process with your on-premises servers.

                Diagram of the restore process.