AWS Elastic Disaster Recovery FAQs

Unlike traditional on-premises disaster recovery, which can involve high costs to maintain a duplicate recovery site that sits idle most of the time, Elastic Disaster Recovery uses cost-effective AWS resources to maintain an up-to-date copy of your source servers on AWS. When you use AWS DRS, you save costs by removing idle disaster recovery site resources and maintenance, and pay for your full recovery site only when you need it for drills or recovery.

With AWS DRS, you can use a unified process to test, recover, and fail back a wide range of applications, without requiring specialized skills. During normal operation, use the AWS DRS Console to monitor your replicating servers and view events and metrics. You can verify your disaster recovery readiness at any time by performing non-disruptive drills.

If you experience a disruption in your primary IT environment, use AWS DRS to quickly recover your applications on AWS, at their most up-to-date state or from an earlier point in time that you select. AWS DRS automatically converts your source servers when you launch them on AWS, so that your recovered applications run natively on AWS.

After you resolve the issue in your primary site, use AWS DRS to fail back your up-to-date recovered applications to your source environment whenever you are ready. You can also choose to keep your recovered applications on AWS – essentially migrating these applications to AWS. In this case, you can increase resilience by using AWS DRS to replicate these migrated applications across AWS Regions or Availability Zones.

The elasticity of AWS infrastructure helps you more quickly scale your disaster recovery site and pay as you go. You can add or remove source servers to replicate from your primary environment to AWS. Using AWS as your disaster recovery site also offers access to the benefits of the cloud, such as agility, cost savings, global infrastructure, and a deep set of security and compliance tools.

To start using AWS DRS, go here or sign into the console and navigate to AWS Elastic Disaster Recovery in the Storage category. You can follow the steps provided in the console to set up AWS DRS and refer to the Quick start guide.

With AWS DRS, you can recover your applications on AWS from physical infrastructure, VMware vSphere, Microsoft Hyper-V, and cloud infrastructure from other cloud providers. You can also use AWS DRS to recover Amazon Elastic Compute Cloud (EC2) instances in a different Availability Zone or a different AWS Region.

Please refer to the AWS Regional Services List for the most up-to-date information.

You can use AWS DRS to recover all of your applications and databases that run on supported Windows and Linux operating system versions. This includes critical databases such as Oracle, MySQL, and SQL Server, and enterprise applications such as SAP.

Yes, you can use AWS DRS to prepare your environment for ransomware and other malicious activities. In the event of a disruption, use point-in-time recovery to launch a copy of your applications in an operational state prior to a security incident. Learn more about ransomware recovery using AWS DRS.

Contact AWS Premium Support to receive product support for AWS DRS according to your support plan. If you are using AWS DRS for production workloads, AWS Business or Enterprise Support is recommended.

Please refer to the AWS DRS Service Level Agreement for details on the terms and conditions of the service SLA, including information on how to submit a claim for a Service Credit.

The shortened service name for AWS Elastic Disaster Recovery is AWS DRS. “DRS” describes that it is a Disaster Recovery Service. This name was selected since EDR has a different established meaning (EDR stands for Endpoint Detection and Response).

A disaster recovery plan describes the detailed procedures your organization will follow and the tools you will use to get your IT systems back online in the case of a disaster. In the context of an organization’s IT environment, a disaster is an event that is disruptive to application functioning, which cannot be resolved automatically. A disaster recovery plan provides clear instructions and documentation for how to recover in the event of a disaster and how to return to normal operation after the disaster is over. It defines the RPOs and RTOs for your applications, and contains the roles and responsibilities of the people who operate the disaster recovery tools, perform disaster recovery procedures, and need to be informed and consulted.

A disaster recovery drill is performed to test the section of your disaster recovery plan that details your response to a disaster. By following the exact steps in the disaster recovery plan and verifying that your disaster recovery site is functioning and is able to provide the required business continuity within the required RPOs and RTOs, you can confirm that this would also be the case if a real disaster occurs. Organizations determine the frequency of disaster recovery drills based on multiple factors, such as requirements by compliance certifications and the cost of each drill for the organization.

Recovery point objective (RPO) is the maximum acceptable gap between the data in the disaster recovery site and the latest data stored in the application when the disaster occurs. This recovery objective determines what is considered an acceptable loss of data (measured in time units) that can be caused by a disaster. AWS DRS facilitates RPOs of seconds.

Recovery time objective (RTO) is the maximum acceptable delay between the interruption of an application and the restoration of its service. This recovery objective determines what is considered an acceptable time window when an application is unavailable. AWS DRS facilitates RTOs of minutes.

Backup is the process of making an extra copy of your data. Backup solutions keep historical data locally or in a remote location so that if any data is lost, it can be recovered from the backup. Backups work best when you need to gain access to a lost or damaged file or object. Backups are also used for long-term data archival or for data retention.

Disaster recovery is the process to quickly reestablish access to your applications, data, and IT resources after an outage. This might involve switching over to a redundant set of servers and storage systems until your source data center is functional again. You use disaster recovery to perform a failover to transfer applications to your disaster recovery site, so that your business can continue to function as normal even if the production site is unavailable.

Backup and disaster recovery are complementary approaches to maintaining business continuity.

You can find more information about the core concepts summarized in this section in the Disaster Recovery of On-Premises Applications to AWS whitepaper, Reliability Pillar – AWS Well-Architected Framework, and Disaster Recovery of Workloads on AWS: Recovery in the Cloud white paper.

AWS DRS is the recommended service for disaster recovery to AWS. It is the next generation of CloudEndure Disaster Recovery, as CloudEndure Disaster Recovery technology was used to build AWS DRS. The following questions provide a summary of the similarities and differences between these two services.

Following the successful launch of AWS DRS, we will begin limiting the availability of CloudEndure Disaster Recovery (CEDR) in all AWS Regions.
Note: AWS China Regions and AWS GovCloud (US) Regions will continue to be supported, as well as customers using disaster recovery through Amazon Managed Services (AMS) and customers using CEDR with AWS Outposts.

Please take note that currently, you are no longer be able to register new CEDR accounts or install new CEDR Agents in any AWS Region excluding AWS China Regions, AWS GovCloud (US) Regions, AMS customers, and Outposts. Note: upgrades of existing agents will be supported. Other steps will take place according to the following schedule:

March 31, 2024 - CloudEndure Disaster Recovery was discontinued in all AWS Regions excluding AWS China Regions, AWS GovCloud (US) Regions, AMS customers, and Outposts.

Since AWS DRS is built on CloudEndure Disaster Recovery technology, the core capabilities and benefits of these two AWS services are similar. Both services allow you to:

• Reduce disaster recovery infrastructure and operational costs.
• Simplify setup, operation, and recovery processes for a wide range of applications.
• Perform non-disruptive disaster recovery testing and drills.
• Recover with short recovery objectives (RPOs of seconds and RTOs of minutes).
• Recover from a previous point in time.

AWS DRS offers features and operational benefits that are not available with CloudEndure Disaster Recovery, and we are continuing to develop and add new features. For example, with AWS DRS you can:

• Gain the operational, security, and compliance benefits of Regional service architecture.
• Operate the service from the AWS Management Console.
• Control permissions and access for specific APIs and AWS DRS resources using AWS Identity and Access Management (IAM).
• Replicate your servers without a connection to the public internet.
• Use standard AWS APIs suited for disaster recovery-specific workflows, as well as a CLI and SDK.
• Monitor metrics and events with Amazon CloudWatch and Amazon EventBridge.
• Audit user activity and API usage with AWS CloudTrail.
• Manage EC2 launch templates and other launch settings at scale to control how your Recovery instances are launched.
• Use tags to organize your source servers and control access permissions.
• Perform non-disruptive failback drills, by failing back to a dedicated source server while replication of your source servers continues.
• Reboot without rescan for both Windows and Linux servers.

View technical comparison table

CloudEndure Disaster Recovery provides certain features that are not currently supported by AWS DRS. Consider using CloudEndure Disaster Recovery if you have the following requirements:

• Replication to AWS China Region.
• Recovery to AWS Outposts.
• Use of Recovery Plans (See this blog post for instructions on setting up recovery plans with AWS DRS.)

For detailed information on how to upgrade from CloudEndure Disaster Recovery to AWS DRS, please refer to the documentation.

The AWS Replication Agent does not require a reboot nor impact your applications during installation. When installation is complete, AWS DRS performs initial data replication, which adds unnoticeable disk read I/O until the disk scan is complete. The AWS Replication Agent resides in memory and captures blocks continuously as they are written to disk, and incurs low CPU utilization to compress and encrypt blocks before replication. AWS DRS does not use snapshots for data copy, therefore application performance impact is unnoticeable. You will need sufficient network bandwidth to complete initial data sync in a timely fashion, and accommodate for data change rate.

Your replicated data is encrypted in transit using TLS 1.2, and is transferred directly from your source servers to your VPC. You can leverage private connectivity such as AWS Direct Connect or VPN to configure the replication route. Your data can also be encrypted at rest on AWS using Amazon EBS encryption. Learn more about infrastructure security with AWS DRS.

Yes, with AWS DRS you can control the data replication path using private connectivity options such as a VPN, AWS Direct Connect, VPC peering, or another private connection. Learn more about using a private IP for data replication.

AWS DRS performs block signature comparison before initiating data replication to verify that duplicate or empty blocks aren’t sent across the network. In addition, replicated data is encrypted and compressed before transit.

Performing a recovery or failback drill does not stop replication (no RPO impact) and does not impact your source application. AWS DRS continuously replicates data to a designated staging area, which is independent from the target test environment.

The AWS DRS server conversion technology makes the relevant changes to the boot volume of the recovered server so that it can boot in AWS, including injecting appropriate hypervisor drivers and making bootloader and networking changes. In addition, you can choose to run a custom-created script following the built-in conversion process. This is useful for adding or removing software and making other desired system or application configuration changes.

Yes, you can recover a single source server into multiple target accounts.

Yes, you can recover up to 3,000 servers into a single target account. You can do this by using multiple staging accounts. (AWS DRS supports up to 300 servers replicating into a single staging account.)

Yes, you can more easily migrate your source servers after you have configured AWS DRS. Simply schedule a migration cutover window and initiate a recovery launch, then redirect your users to the launched instances on AWS. After completing your migration, you can continue to use AWS DRS to replicate migrated workloads across AWS Regions or Availability Zones to increase the resilience of your AWS-based applications.

Please refer to the Security in AWS DRS documentation to understand how to apply the shared responsibility model when you use AWS DRS.

You can find additional technical FAQs in the AWS DRS user guide.