# Elastic Disaster Recovery FAQ
## What source infrastructure does AWS Elastic Disaster Recovery support?
With AWS Elastic Disaster Recovery, you can recover your applications on AWS from any source infrastructure on which you can install the AWS Replication Agent, and on which you can run the DRS Failback Client. This includes physical infrastructure, virtual machines on hypervisors by VMware, Microsoft, and others, and cloud infrastructure from other cloud providers.
## How do I upgrade from CloudEndure Disaster Recovery to AWS Elastic Disaster Recovery?
You can use the CEDR to DRS Upgrade Assessment Tool and the Server Upgrade Tool to move your source servers from CloudEndure Disaster Recovery (CEDR) to AWS Elastic Disaster Recovery (DRS). [Learn more in the CloudEndure documentation](https://docs.cloudendure.com/#Configuring_and_Running_Disaster_Recovery/Upgrade_CEDR_to_DRS/Upgrade_CEDR_to_DRS.htm#Upgrading_from_CEDR_to_AWS%C2%A0DRS%3FTocPath%3DNavigation%7CConfiguring%2520and%2520Running%2520Disaster%2520Recovery%7CUpgrading%2520from%2520CEDR%2520to%2520AWS%25C2%25A0DRS%7C_____0).
AWS Elastic Disaster Recovery (Elastic Disaster Recovery) is the next generation of CloudEndure Disaster Recovery (CEDR) and is the recommended service to use for Disaster Recovery to AWS. All customers are encouraged to transition from CEDR to Elastic Disaster Recovery, as soon as this is feasible for them.
Prior to upgrading, [learn more about the differences between the two services](https://aws.amazon.com/disaster-recovery/faqs/?nc=sn&loc=4), and make sure that [DRS is right for you](https://aws.amazon.com/disaster-recovery/when-to-choose-aws-drs/?cloud-endure-blogs.sort-by=item.additionalFields.createdDate&cloud-endure-blogs.sort-order=desc).
For manual upgrading instructions, refer to [this section](#cedr-to-drs-instructions).
## Can AWS Elastic Disaster Recovery protect physical servers?
Because AWS Elastic Disaster Recovery works at the OS layer it can protect not only virtual servers but physical ones as well.
## What data is stored on and transmitted through AWS Elastic Disaster Recovery servers?
AWS Elastic Disaster Recovery stores only configuration and log data on the AWS Elastic Disaster Recovery Console's encrypted database. Replicated data is always stored on the customer’s own cloud VPC. The replicated data is encrypted in transit.
## What is the Recovery Time Objective (RTO) of AWS Elastic Disaster Recovery?
The Recovery Time Objective (RTO) of Elastic Disaster Recovery is typically measured in minutes. The RTO is highly dependent on the OS boot time.
## What is the Recovery Point Objective (RPO) of AWS Elastic Disaster Recovery?
The Recovery Point Objective (RPO) of AWS Elastic Disaster Recovery is typically in the sub-second range.
## What to consider when replicating Active Directory
There are two main approaches when it comes to migrating Active Directory or domain controllers from a disaster:
1. Replicating the entire environment, including the AD server(s) - in this approach it is recommended to launch the drill or recovery AD servers first, wait until it's up and running and then launch the other drill or recovery instances, to make sure the AD servers are ready to authenticate them.
1. Leaving the AD server(s) in the Source environment - in this approach, the drill or recovery instances will communicate back to the AD server in the source environment and will take the source server's place in the AD automatically.
In this case, it is important to conduct any drills using an isolated subnet in the AWS cloud, so to avoid having the drill or recovery instances communicate into the source AD server outside of a recovery.
## Does AWS Elastic Disaster Recovery work with LVM and RAID configurations?
AWS Elastic Disaster Recovery works with any hardware RAID configuration and LVM configuration.
**Note**
Boot partitions that span or mirror, using software over multiple physical disks, are not supported by AWS Elastic Disaster Recovery and are not recommended for use in EC2. If your source server's configuration contains mirrored boot partition (e.g. [ Windows Mirrored Disks](https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/mirror-system-boot-partition-raid1)), we recommend installing the agent to replicate only one physical disk of the mirrored boot partition using the `--devices` parameter.
[Windows EC2 RAID Documentation.](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/raid-config.html)
[Linux EC2 RAID Documentation.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html)
## Do Replication Servers have the SSM agent installed on them?
The SSM agent is intentionally not installed on these servers as part of our security architecture to maintain isolation and prevent any potential unauthorized access paths.
## What is there to note regarding SAN/NAS Support?
If the disks are represented as block devices on the machine, as most SAN are, Elastic Disaster Recovery will replicate them transparently, just like actual local disks.
If the disks are mounted over the network, such as an NFS share, as most NAS implementations are, the AWS Replication Agent would need to be installed on the actual NFS server in order to replicate the disk.
## Does AWS Elastic Disaster Recovery support Windows License Migration?
AWS Elastic Disaster Recovery conforms to the [Microsoft Licensing on AWS](https://aws.amazon.com/windows/resources/licensing/) guidelines.
## Can you perform an OS (Operating System) upgrade with AWS Elastic Disaster Recovery?
No. AWS Elastic Disaster Recovery copies the entire machine as-is. However, you can copy the data disks exclusively and attach them to a new machine with an upgraded OS.
## What are the private APIs used by AWS DRS to define actions in the IAM Policy?
AWS Elastic Disaster Recovery (AWS DRS) utilizes the following private API resources as actions in the IAM Policy. Learn more about actions, resources, and condition keys for Elastic Disaster Recovery.
+ BatchCreateVolumeSnapshotGroupForDRS – Grants permission to create volume snapshot group.
+ BatchDeleteSnapshotRequestForDRS – Grants permission to batch delete snapshot request.
+ DescribeReplicationServerAssociationsForDRS – Grants permission to describe replication server associations.
+ DescribeSnapshotRequestsForDRS – Grants permission to describe snapshots requests.
+ GetAgentCommandForDRS – Grants permission to get agent command.
+ GetAgentConfirmedResumeInfoForDRS – Grants permission to get agent confirmed resume info.
+ GetAgentInstallationAssetsForDRS – Grants permission to get agent installation assets.
+ GetAgentReplicationInfoForDRS – Grants permission to get agent replication info.
+ GetAgentRuntimeConfigurationForDRS – Grants permission to get agent runtime configuration.
+ GetAgentSnapshotCreditsForDRS – Grants permission to get agent snapshots credits.
+ GetChannelCommandsForDRS – Grants permission to get channel commands.
+ NotifyAgentAuthenticationForDRS – Grants permission to notify agent authentication.
+ NotifyAgentConnectedForDRS – Grants permission to notify agent is connected.
+ NotifyAgentDisconnectedForDRS – Grants permission to notify agent is disconnected
+ NotifyAgentReplicationProgressForDRS – Grants permission to notify agent replication progress.
+ RegisterAgentForDRS – Grants permission to register agent.
+ SendAgentLogsForDRS – Grants permission to send agent logs.
+ SendAgentMetricsForDRS – Grants permission to send agent metrics.
+ SendChannelCommandResultForDRS – Grants permission to send channel command result.
+ SendClientLogsForDRS – Grants permission to send client logs.
+ SendClientMetricsForDRS – Grants permission to send client metrics.
+ UpdateAgentBacklogForDRS – Grants permission to update agent backlog.
+ UpdateAgentConversionInfoForDRS – Grants permission to update agent conversion info.
+ UpdateAgentReplicationInfoForDRS – Grants permission to update agent replication info.
+ UpdateAgentSourcePropertiesForDRS – Grants permission to update agent source properties.
+ IssueAgentCertificateForDrs – Grants permission to issue an agent certificate.
+ CreateConvertedSnapshotForDrs – Grants permission to create converted snapshot.
## What post-launch scripts does AWS Elastic Disaster Recovery support?
DRS can run scripts on a launched drill or recovery instance. This is done by creating the following folder on the source server and placing the scripts within that folder.
**Linux**: /boot/post\$1launch (any files that are marked as executable)
**Windows**: C:\$1Program Files (x86)\$1AWS Replication Agent\$1post\$1launch\$1 (any .exe, .cmd, or .bat files)
Once you put these scripts in the above folders on the source server, the folder will be replicated to the drill or recovery instance and be executed once after the instance boots for the first time.
**Note**
Post-launch scripts on Windows run under the Local System context. Post-launch scripts on Linux run under the 'root' user.
## Is BitLocker encryption supported?
DRS does not support OS-based disk encryption features such as BitLocker. These should be deactivated before using AWS Elastic Disaster Recovery.
## Can I set instance metadata on my launched instance to support IMDSv2 only?
You can easily set Instance Metadata Service Version 2 (IMDSv2) on your recovery instances using the EC2 launch template associated with your DRS source server.
Follow the instructions on the [EC2 launch template page](ec2-launch.md).
When you are redirected to the EC2 console to modify your template, take the following steps
+ Click **Advanced details > Metadata version**.
+ Select **V2 only (token required)**.
You can then set this launch template as your default version.
## Upgrading from CEDR to AWS DRS - Manual instructions
**Important**
You can now use the CEDR to DRS Upgrade Assessment Tool and the Server Upgrade Tool to move your source servers from CloudEndure Disaster Recovery (CEDR) to AWS Elastic Disaster Recovery (AWS DRS). [Learn more in the CloudEndure documentation](https://docs.cloudendure.com/#Configuring_and_Running_Disaster_Recovery/Upgrade_CEDR_to_DRS/Upgrade_CEDR_to_DRS.htm#Upgrading_from_CEDR_to_AWS%C2%A0DRS%3FTocPath%3DNavigation%7CConfiguring%2520and%2520Running%2520Disaster%2520Recovery%7CUpgrading%2520from%2520CEDR%2520to%2520AWS%25C2%25A0DRS%7C_____0).
AWS Elastic Disaster Recovery (AWS DRS) is the next generation of CloudEndure Disaster Recovery (CEDR) and is the recommended service to use for Disaster Recovery to AWS. All customers are encouraged to transition from CEDR to AWS DRS, as soon as this is feasible for them.
Prior to upgrading, [learn more about the differences between the two services](https://aws.amazon.com/disaster-recovery/faqs/?nc=sn&loc=4), and make sure that [DRS is right for you](https://aws.amazon.com/disaster-recovery/when-to-choose-aws-drs/?cloud-endure-blogs.sort-by=item.additionalFields.createdDate&cloud-endure-blogs.sort-order=desc).
The following are the manual instructions for upgrading:
1. Follow the DRS [getting started procedure to initialize AWS DRS](https://docs.aws.amazon.com/drs/latest/userguide/getting-started-initializing.html) in the AWS Region you want to replicate to.
1. [Launch a recovery instance (target machine)](https://docs.cloudendure.com/#Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm#Performing_a_Failover_with_CloudEndure_..20%3FTocPath%3DNavigation%7CConfiguring%2520and%2520Running%2520Disaster%2520Recovery%7CPerforming%2520a%2520Disaster%2520Recovery%2520Failover%2520and%2520Failback%7CFailover%2520and%2520Failback%2520with%2520CloudEndure%2520-%2520Detailed%2520Instructions%7CPerforming%2520a%2520Failover%2520with%2520CloudEndure%7C_____0) using CloudEndure, and make sure that it works as expected. Once you have verified that everything works as expected, terminate the launched instance using the CloudEndure Console by choosing the ["Delete Target Machines" option](https://docs.cloudendure.com/#Getting_Started_with_CloudEndure/Exploring_the_CloudEndure_Console/Machines/Machines.htm#MACHINE_ACTIONS_Menu%3FTocPath%3DNavigation%7CGetting%2520Started%2520with%2520CloudEndure%7CExploring%2520the%2520CloudEndure%2520User%2520Console%7CMachines%2520Page%7C_____3). If you want to keep the instance, [activate EC2 termination protection](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/terminating-instances.html#Using_ChangingDisableAPITermination) before removing the source machine from the CloudEndure service.
Until the server is ready on DRS, CloudEndure will still be your way to launch Recovery instances should you need them. That is why you must make sure that recovery using CloudEndure is working as expected for the server/s you are about to transition to DRS.
1. [Pause data replication](https://docs.cloudendure.com/#Getting_Started_with_CloudEndure/Exploring_the_CloudEndure_Console/Machines/Machines.htm#MACHINE_ACTIONS_Menu%3FTocPath%3DNavigation%7CGetting%2520Started%2520with%2520CloudEndure%7CExploring%2520the%2520CloudEndure%2520User%2520Console%7CMachines%2520Page%7C_____3) for this server in CloudEndure.
1. [Manually uninstall the CloudEndure agent from your source servers](https://docs.cloudendure.com/#FAQ/FAQ/Agent_Related.htm#How_do_I_manually_uninstall_the_CloudEndure_Agent_from_a_Source_or_Target_mac...%3FTocPath%3DNavigation%7CFAQ%25C2%25A0and%25C2%25A0Troubleshooting%7CFAQ%7CAgent%2520Related%7C_____14).
**Important**
Do ** *not* ** use the **Remove from console** option available from the CloudEndure user console. By keeping this server’s records in CloudEndure, you also maintain its Point In Time recovery points, allowing you to launch a recovery instance using CloudEndure, should you need such a recovery instance before this server is ready on Elastic Disaster Recovery.
1. [Install the AWS Replication Agent on your source server.](https://docs.aws.amazon.com/drs/latest/userguide/adding-servers.html)
1. Configure [Replication settings](https://docs.aws.amazon.com/drs/latest/userguide/replication-settings-template.html) and [Launch settings](https://docs.aws.amazon.com/drs/latest/userguide/launching-target-servers.html) for this server in AWS Elastic Disaster Recovery (AWS DRS).
1. Wait for initial sync to be complete until your source server's [data replication status](https://docs.aws.amazon.com/drs/latest/userguide/recovery-dashboard.html#data-replication-stat) has reached the **Healthy** state in the AWS DRS console.
1. Use DRS to[launch a drill instance](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html#recovery-drill-overview) for your source server and make sure it works as desired.
1. Wait for the number of recovery days you want to have [Points In Time](https://docs.aws.amazon.com/drs/latest/userguide/failback-overview.html#point-in-time-faq) for to pass. For example, if you have CloudEndure and AWS DRS configured to retain 10 daily recovery Points In Time, then wait for 10 full days after the server has achieved the **Healthy** state in AWS DRS before removing it from CloudEndure.
**Important**
[Remove your source servers from the CloudEndure console](https://docs.cloudendure.com/#Installing_the_CloudEndure_Agents/Uninstalling_the_Agents/Uninstalling_the_Agents.htm#Uninstalling_Agents_from_Source_Machines%3FTocPath%3DNavigation%7CInstalling%2520the%2520CloudEndure%2520Agents%7CUninstalling%2520the%2520Agents%7CUninstalling%2520Agents%2520from%2520Source%2520Machines%7C_____0).
This action will cause all replication resources created for this server in AWS to be terminated. Until you do this, these resources continue to cost you money.
If you have a launched a target instance in AWS using CEDR, consider whether you want to keep it or not.
If you experience a disaster recovery event before the server reaches the **Healthy ** state in AWS DRS, navigate to the CloudEndure console and [launch a Target instance from there](https://docs.cloudendure.com/#Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm#Performing_a_Failover_with_CloudEndure_..20%3FTocPath%3DNavigation%7CConfiguring%2520and%2520Running%2520Disaster%2520Recovery%7CPerforming%2520a%2520Disaster%2520Recovery%2520Failover%2520and%2520Failback%7CFailover%2520and%2520Failback%2520with%2520CloudEndure%2520-%2520Detailed%2520Instructions%7CPerforming%2520a%2520Failover%2520with%2520CloudEndure%7C_____0). This will launch the Target instance from the last PIT the system created before you removed the CloudEndure agent from the source servers. The CloudEndure console UI will show you the PIT from when this will launch.
**Note**
During some of the time it takes to transition from CloudEndure to DRS you will not have the same level of protection: While replication in CloudEndure is paused and the server has not yet completed the initial scan, you will not be able to launch instances in DRS, and only be able to launch instances in CloudEndure with data prior to the pause action. This applies both to launching from latest snapshot and to launching from point-in-time.
**Note**
Once you install the AWS Replication Agent on the source server, and until you remove that source server from the CloudEndure user console, you will be paying for the two services in parallel, and nearly twice for replication resources such as EBS, snapshots, and more.
# Elastic Disaster Recovery Concepts
## What is the Recovery Time Objective (RTO) of Elastic Disaster Recovery?
The Recovery Time Objective (RTO) of Elastic Disaster Recovery is typically measured in minutes. The RTO is highly dependent on the OS boot time.
A: When launching a recovery job, the AWS DRS orchestration process creates cloned volumes by using the replicated volumes in the replication staging area. During this process, AWS DRS also initiates a process that converts all volumes that originated outside of AWS into AWS-compatible volumes, which are attached to EC2 instances that can boot natively on AWS. The job and boot time depend on the following environment conditions:
1. OS type: The average recovered Linux server normally boots within 5 minutes, while the average recovered Windows server normally boots within 20 minutes because it is tied to the more resource-intensive Windows boot process.
1. OS configuration: The OS configuration and application components it runs can impact the boot time. For example, some servers run heavier workloads and start additional services when booted, which may increase their total boot time.
1. Target instance performance: AWS DRS sets a default instance type based on the CPU and RAM provisioned on the source server. Changing to a lower performance instance type will result in a slower boot time than that of a higher performance instance type.
1. Target volume performance: Using a lower performance volume type will result in a slower boot time than that of a higher performance volume type with more provisioned IOPS.
## What is the Recovery Point Objective (RPO) of Elastic Disaster Recovery?
The Recovery Point Objective (RPO) of Elastic Disaster Recovery is typically in the sub-second range.
AWS Elastic Disaster Recovery (AWS DRS) provides continuous block-level replication, recovery orchestration, and automated server conversion capabilities. These allow customers to achieve a crash-consistent recovery point objective (RPO) of seconds, and a recovery time objective (RTO) typically ranging between 5–20 minutes. Below is an explanation of how RPO and RTO are measured, how AWS DRS supports these RPOs and RTOs, and what common environment conditions can impact RPO and RTO.
### Recovery Point Objective (RPO)
#### How is RPO measured?
RPO is measured based on the latest point in time in which block data was written to the source server volume(s) and successfully copied in a crash-consistent state into the replication staging area located in the customer’s target AWS account.
#### How does AWS DRS allow an RPO of seconds?
The AWS Replication Agent continuously monitors the blocks written to the source server volume(s), and immediately attempts to copy the blocks across the network and into the replication staging area subnet located in the customer’s target AWS account. This continuous replication approach allows an RPO of seconds as long as the written data can be immediately copied across the network and into the replication Staging Area volumes.
**Important**
A crash-consistent recovery point allows the successful recovery of crash-consistent applications, such as databases. The recovery point will include any data that has been successfully written to the source server volume(s). Application data that is kept in memory is not replicated to the target replication Staging Area until it is written to the source server volume(s). Therefore, if a disruption occurs before in-memory application data is written to the volume(s), this data will not be available on the target server when launched for test or recovery purposes.
#### What environment conditions can impact the ability to achieve a typical RPO of seconds?
To achieve an RPO of seconds, AWS Elastic Disaster Recovery primarily requires that the outbound network, inbound network, and staging area resources must allow data to be copied across the network and written to the target environment faster than the rate at which it is written to the source volume(s). In the case that block writes burst at faster rates than these components can support, the RPO will temporarily increase until the data replication can catch up, at which point the RPO will return to seconds. Examples:
1. Outbound network: If a source server writes block data at a rate of 10 MB/second, the outbound network bandwidth must also support a rate of at least 10 MB/second in order to maintain a seconds RPO. If the source network contains 10 servers that each write at an average rate of 10 MB/second, the total bandwidth will need to support a rate of at least 100 MB/second in order to allow a seconds RPO.
1. Inbound network: Once the replicated data is sent from the source network, it must enter the target network at a rate greater to that at which the data is written to the source servers and sent from the source network in order to maintain a seconds RPO.
1. Staging area resources: When the data arrives to the target network, it is received by the AWS DRS replication server instance(s), which in turn writes the replicated data to attached EBS volumes. Both the replication server instance(s) and attached Amazon EBS volumes must allow the data to be written at a rate faster than that at which it is written to the source servers and sent by the source network in order to maintain an RPO of seconds.
#### What happens if the block data written to the source volume(s) cannot be sent immediately to the target replication Staging Area Subnet?
If the block data written on the source volume(s) cannot be sent immediately to the target replication Staging Area, the RPO will increase until the data can be flushed across the network. During this time, you will still be able to recover your server(s), but to a recovery point older than seconds, in accordance with the increase in RPO. The RPO represents the latest crash-consistent point in time during which data was replicated.
## What are Point in Time Snapshots?
Point in Time (PIT) Snapshots are an AWS Elastic Disaster Recovery feature which allows launching a Recovery Instance of a Source Server from a set of EBS Snapshots captured at a specific moment in time. The PIT Snapshot is a crash-consistent recovery point of your Source Server, and represent your [Recovery Point Objective](#What-is-RPO) (RPO). After Source Servers complete **Initial Sync** and maintain **Healthy** replication status, Point in Time states are automatically created and stored in accordance to your snapshot retention policy.
Each PIT Snapshot for a Source Server consists of one or more EBS Snapshots; one EBS snapshot for each volume being replicated. See below for where the EBS snapshots are stored:
| Replication Strategy | Replication Target | EBS Snapshot S3 Region | EBS Snapshot Account |
| --- | --- | --- | --- |
| Single Account | Any Region | Same Region as Replication Target | Same AWS Account |
| Extended Account | Any Region | Same Region as Replication Target | Staging Account |
| Multi-Account | Any Region | Same Region as Replication Target | Target Account |
| Reverse Replication | Any Region | Same Region as Source | Source Account |
| Any | Outpost | Stored locally on Outpost | Outpost Account |
### What is the PIT Snapshot Retention Rate?
Elastic Disaster Recovery has the following default PIT Snapshot frequency and retention schedule:
+ **Minute** - 1 PIT Snapshot per 10 minutes for the prior 1 hour.
+ **Hour** - 1 PIT Snapshot per 1 hour for the prior 24 hours.
+ **Day** - 1 PIT Snapshot per 1 day for the prior 7 days.
### Can I adjust the PIT Snapshot Retention Rate?
You can only adjust the **Day** PIT Snapshot retention limit from 1 day through 365 days in the replication settings. As each PIT Snapshot consists of one or more EBS snapshots, increasing the PIT Snapshot retention rate can result in additional EBS costs. The frequency (i.e. how often) that AWS Elastic Disaster Recovery creates snapshots are not configurable. [Learn more about managing Point in Time retention.](point-in-time.md)
### What is "Use most recent data"?
"**Use most recent data**" is a feature available when selecting a PIT Snapshot from the AWS Elastic Disaster Recovery console during a **Recovery Drill** or **Recovery**. It is implicitly used when a **Recovery Drill** or **Recovery** is started programmatically (e.g. AWS CLI) without specifying a PIT Snapshot. When used, AWS Elastic Disaster Recovery will attempt to create an on-demand PIT Snapshot of all Source Servers within the Recovery Job, representing a sub-second [RPO](#What-is-RPO) of the Source Server. This PIT Snapshot will be consistent to the time the Recovery Job was submitted.
DRS requires an active network connection to the Source Server to successfully create this new PIT Snapshot. AWS Elastic Disaster Recovery may be unable to create this PIT Snapshot for various reasons, and will wait for up to 10 minutes for this new PIT Snapshot to be created. If DRS is unable to create this PIT Snapshot, it will use a snapshot based on the last consistent state from data on the Replication Server. Reasons why "**Use most recent data**" may fail to successfully create a PIT Snapshot include:
+ Unable to communicate with the Source Server.
+ Unable to transfer all changes present on the Source Server within the timeout window.
As "**Use most recent data**" requires an active network connection to the Source Server to create a new PIT Snapshot, there may be circumstances (e.g Source Server is offline) where your RTO will be shortened by selecting an existing PIT Snapshot rather than waiting for "**Use most recent data**" to timeout.
### What is "Any" and "All" in Point in Time Snapshot selection?
The **Any** and **All** selection criteria are available in the AWS Elastic Disaster Recovery Console when selecting a Point in Time Snapshot for a job that contains multiple Source Servers.
+ **Any** - Displays all of the PIT Snapshots available for all of the selected source servers. AWS Elastic Disaster Recovery will launch a drill instance for each source server that has a PIT snapshot taken at the chosen time. For any Source Server that does not have a corresponding PIT snapshot taken at the chosen time, a previous PIT Snapshot will be used.
+ **All** - Displays only PIT Snapshots that all selected Source Servers share. If there are no points in time that include all Source Servers, the list will be empty.
# Agent related
## What does the AWS Replication Agent do?
The AWS Replication Agent performs an initial block-level read of the content of any volume attached to the server and replicates it to the replication server. The Agent then acts as an OS-level read filter to capture writes and synchronizes any block level modifications to the Elastic Disaster Recovery replication server, ensuring near-zero RPO.
## What kind of data is transferred between the Agent and the AWS Elastic Disaster Recovery Service Manager?
The AWS Replication Agent sends the following types of information to the AWS Elastic Disaster Recovery Service Manager:
+ Monitoring metrics of the Agent itself
+ Replication status (started, stalled, resumed)
+ Backlog information
+ OS and hardware information.
When an Agent is installed on a source server, it collects the following information on the machine:
+ Host name and ID.
+ List of CPUs including models and number of cores
+ Amount of RAM
+ Hardware and OS information.
+ Number of disks and their size – in Windows, disk letters; in Linux, block device names.
+ Installed applications (Windows)
+ Installed Packages (Linux)
+ Running services.
+ Machine's Private IP address.
## Can a proxy server be used between the source server and the Elastic Disaster Recovery Console?
Yes. You can configure the proxy either by using an environment variable prior to the installation (Linux and Windows), or by using the `--proxy-address` flag in the Linux installer.
Using the installer: `./aws-replication-installer-init --proxy-address https://PROXY:PORT/`
Using environment variable: `export https_proxy=https://PROXY:PORT/; ./aws-replication-installer-init `
Make sure the proxy has a trailing forward slash (`/`).
## What are the pre-requisites needed to install the AWS Replication Agent?
The installation requirements for source server depend on the type of OS that the server runs – either Linux or Windows.
[View the prerequisites.](installation-requirements.md)
## What ports does the AWS Replication Agent utilize?
The Agent utilizes TCP Port 443 to communicate to the Elastic Disaster Recovery Service Manager and TCP Port 1500 for replication to AWS.
## What kind of resources does the AWS Replication Agent utilize?
The AWS Replication Agent is lightweight and nondisruptive. The agent utilizes approximately 5% CPU and 300 MB of RAM.
## Can Elastic Disaster Recovery migrate containers?
Elastic Disaster Recovery only supports the replication of full servers. Nevertheless, Elastic Disaster Recovery replicates on a server level and therefore any containers within the selected servers will be replicated.
## Does the AWS Replication Agent cache any data to disk?
Elastic Disaster Recovery does not write any cache or do any sort of journalling to disk. The Agent holds a buffer which is large enough to map all volume's blocks \$1250 MB in memory.
The Agent then acts as a sort of write filter and will replicate changed blocks directly from memory to the replication server. In cases where the data is no longer in memory, the Agent will read the block from the volume directly. This is the case where you may see backlog in the Elastic Disaster Recovery Console. The cause of this is the volume of change is greater than the bandwidth available.
## How is communication between the AWS Replication Agent and the Elastic Disaster Recovery Service Manager secured?
All communication is encrypted using SSL. In addition, each Agent is assigned a key during installation which is used to encrypt all traffic. All keys are unique and are not shared across multiple Agents.
## Is it possible to change the port the AWS Replication Agent utilizes from TCP Port 1500 to a different port?
No. The Elastic Disaster Recovery Agent can only utilize TCP Port 1500 for replication.
## How do I manually uninstall the Elastic Disaster Recovery Agent from a server?
Please refer to:[Uninstalling the agent](uninstalling-agent.md).
## When do I need to reinstall the Agent?
Agent re-installations are required in these cases:
+ After adding new volumes if the [Automatic replication of new disks](volumes-drs.md#auto-replicate) option is not activated for the source server where the volume is added.
+ Windows OS upgrades (ex. Windows Server 2012 to Windows Server 2016)
+ Some new features require a re-installation to apply. In this case, the feature documentation will specifically state that this is a requirement for the feature to be activated.
## How much bandwidth does the AWS Replication Agent consume?
The AWS Replication Agent opens up to five connections and will attempt to maximize available bandwidth.
Throttling can be activated by selecting the specific server and selecting the **Settings ** page in the Elastic Disaster Recovery Console.
## How many disks can the AWS Replication Agent replicate?
The Agent can replicate up to 50 disks from a single server. Ensure that the replication server instance type supports at least the number of disks being replicated.
## Is it possible to add a disk to replication without a complete resync of any disks that have already been replicated?
When you add a disk to a source server, AWS Elastic Disaster Recovery will automatically identify it and add it to the **Disk settings** tab in the console.
This feature is activated automatically for newly added servers. [Learn how to deactivate or reactivate this feature.](volumes-drs.md#auto-replicate)
## Which Windows and Linux OSs support no-rescan upon reboot?
A shutdown (from the OS menu or CLI) of any supported Linux or Windows source server no longer causes a rescan in DRS once the source server is restarted. A rescan means that the agent on the source server rereads all blocks on all replicated disks and transmits blocks that are different from the previously replicated data. A rescan is similar to the initial sync but is faster because only blocks that are different need to be transmitted.
Rescans can still happen following a hard reboot, crashes, or when you add or remove disks to or from the source server. In addition, a rescan will occur if the underlying Storage types do not use static [DUIDs ](https://learn.microsoft.com/en-us/windows-hardware/drivers/storage/device-unique-identifiers--duids--for-storage-devices) (such as 3PARdata). Supported OSs include:
**Windows Server**
+ 2012 and newer
**Linux**
+ CentOS 6–8
+ Oracle 6–8
+ RHEL 6–9
+ Rocky 8 and 9
+ SLES 12 and 15
+ Debian 9–11
+ Ubuntu 16, 18, 20, and 22
+ Amazon Linux 2
## No-Rescan Upon Reboot Limitations
A rescan may still occur in certain circumstances, including:
Hard Reboot or Power Loss.
**Important**
**A rescan duration may impact your RPO**
While a rescan is conducted, a point of time recovery cannot be made.
If a disaster occurs during the rescan you will only be able to restore point of time from before the rescan began. This could affect your ability to meet your RPO.
## How do temporary credentials work?
The temporary credential mechanism was developed specifically to provide an easy and secure way to install AWS DRS Agents. The main flow of the temporary credentials' creation process relies on generating a x509 certificate per agent and then using this x509 certificate to receive temporary IAM credentials. This process utilizes a similar mechanism to the one used by [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html).
## Where can I find the AWS DRS Replication Agent logs
The AWS DRS agent logs are stored in agent.log.0:
+ **Linux:** /var/lib/aws-replication-agent/agent.log.0
+ **Windows 64 bit:** C:\$1Program Files (x86)\$1AWS Replication Agent\$1agent.log.0
In addition, you can review the installation log located in: \$1aws\$1replication\$1agent\$1installer.log
# Replication related
## Can we set specific IP addresses for the replication server or conversion server in the AWS DRS staging area?
You cannot specify or assign static IP addresses for the replication server or conversion server in AWS DRS. These servers are managed and maintained by the DRS service.
## What do Lag and Backlog mean during replication?
During replication you may see a server fall out of Continuous Data Protection (CDP) mode. This may occur for various reasons, typically related to the network throughput or interruption.
+ **Lag** – The amount of time since the server was last in CDP mode.
+ **Backlog** – The amount of data that was written to the disk and still needs to be replicated in order to reach CDP mode.
+ **ETA** – The estimated time remaining to return to CDP.
## Is the replicated data encrypted?
Elastic Disaster Recovery encrypts all the data in transit.
## How is the replication server provisioned and managed in the Staging Area?
AWS Elastic Disaster Recovery automatically provisions replication servers in your staging area subnet when source servers are added. The service manages the full lifecycle of replication servers, including launching new servers when additional replication capacity is needed, removing servers that are no longer in use, and recycling servers every 14 days to ensure they run the latest AMI with up-to-date security patches. Each replication server can handle replication of volumes from multiple source servers. You can configure the replication server instance type and subnet in the [replication settings](individual-replication-settings.md#replication-server-settings).
## What type of replication server is utilized in the Elastic Disaster Recovery Staging Area?
AWS Elastic Disaster Recovery provisions a t3.small server by default. The typical ratio of volumes to replication servers is 15:1.
## Does AWS Elastic Disaster Recovery compress data during replication?
Yes, AWS Elastic Disaster Recovery utilizes LZ4 compression during transit resulting in 60-70% compression depending on the type of data.
## Are events that are generated by the AWS Elastic Disaster Recovery servers logged in Cloudtrail in AWS?
Yes, AWS Elastic Disaster Recovery is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in AWS Elastic Disaster Recovery (AWS DRS). CloudTrail captures all API calls for AWS DRS as events. The calls captured include calls from the AWS DRS console and code calls to the AWS DRS API operations. [Learn more about AWS DRS and Cloudtrail.](logging-using-cloudtrail.md#logging-using-cloudtrail-)
## How many snapshots does Elastic Disaster Recovery create?
Point in Time (PIT) is a disaster recovery feature which allows launching an instance from a snapshot captured at a specific Point In Time. As source servers are replicated, Point in Time states are chronicled over time, while a retention policy will determine which Points in Time are not required after a defined duration.
Elastic Disaster Recovery has the following PIT state schedule:
+ Every 10 minutes for the last hour
+ Once an hour for the last 24 hours
+ Once a day for the last 7 days (or a different retention period, as configured)
You can increase or decrease the default 7 day snapshot retention rate from anywhere between 1 day and 365 days in the replication settings. [Learn more about managing Point in Time retention. ](point-in-time.md)
## Does Elastic Disaster Recovery delete snapshots?
AWS Elastic Disaster Recovery automatically deletes snapshots that are no longer used (such as those left over after source servers have been removed from the Elastic Disaster Recovery Console) or those that are past the designated retention setting.
## How much capacity is allocated to the staging area?
A volume is created for each volume in the source infrastructure of the same size. The EBS volumes will be a 1:1 match for the source machines provisioned size.
## Why is 0.0.0.0:1500 added to inbound rules in the Staging Area?
AWS Elastic Disaster Recovery uses TCP Port 1500 for replication between the source agents and the replication server. The connection is open for all IPs and can be managed by ACLs or network controls to limit inbound IPs.
## What should I know about rescans?
During a rescan, the agent on the source server rereads the data on all replicated disks and transmits any differences from the previously replicated data. A rescan is similar to the initial sync but is faster because only changes are replicated. The rescan speed depends on factors such as the size of the source disks and disk performance. A rescan is functioning normally as long as it’s progressing.
Causes of rescans include:
+ Hard reboots/crashes.
+ Adding or removing disks or modifying the size of disks on the source server.
+ The OS is not supported for the no-rescan feature. Learn more in [Supported Windows operating systems](Supported-Operating-Systems-Windows.md) and [Supported Linux operating systems](Supported-Operating-Systems-Linux.md).
+ Writing data to disks while the Replication Agent driver is unhooked.
## How does AWS Elastic Disaster Recovery ensure that replication servers are patched and follow security best practices?
AWS Elastic Disaster Recovery automatically recycles replication servers every 14 days. When a replication server reaches the end of its lifecycle, the service terminates it and launches a new replication server using the latest AMI, which includes the most recent security patches and updates. During the recycling process, you may observe temporary replication lag while the new replication server is launched and the AWS Replication Agent reconnects. Replication resumes automatically once the new server is ready.
## Is the Elastic Disaster Recovery replication crash consistent?
Yes, AWS Elastic Disaster Recovery's replication is crash consistent.
## How can I perform an SSL connectivity and bandwidth test?
**Note**
This tool is designed for AWS only.
You can use our SSL bandwidth tool to check for replication bandwidth availability.
1. In your target region, launch a c5.large test server using the public AMI named CE-ssl-speedtest.
1. Select the same subnet as the subnet used in the replication settings of your source machine.
1. Make sure that the security group allows TCP Port 1500 inbound access.
1. On the source machine, browse to: https://\$1test\$1server\$1ip\$1:1500/speedtest
1. Click **Start**.
**Note**
Browse to the web page using the test server **public** or **private** IP according to what you defined in your replication settings.
The following are the AMI details per region.
ami-00b38c08ab3506ea7 – US East (N. Virginia)
ami-0bd8423a4d80563fc – US East (Ohio)
ami-00b7159e9c985a8da – US West (N. California)
ami-033a4924b13126a7b – US West (Oregon)
ami-0bf60b09675c8d9b6 – Africa (Cape Town)
ami-0f01375b50763621b – Asia Pacific (Hong Kong)
ami-0b1aeb50834102c18 – Asia Pacific (Mumbai)
ami-0b1aeb50834102c18 – Asia Pacific (Hyderabad)
ami-044fa8034a31d7578 – Asia Pacific (Tokyo)
ami-08b042df0d4c458ea – Asia Pacific (Seoul)
ami-0971e46306691cd68 – Asia Pacific (Osaka)
ami-0afd42552b236f9dd – Asia Pacific (Singapore)
ami-04e7cc6b5d9e8ffa1 – Asia Pacific (Sydney)
ami-02f31943dfd88549d – Asia Pacific (Jakarta)
ami-033db317ada5abd55 – Asia Pacific (Melbourne)
ami-01c24408802db503d – Canada (Central)
ami-0b8643189a66159c9 – Europe (Stockholm)
ami-0dd5a09d2ae8f46b3 – Europe (Ireland)
ami-097fb47f3a1c2bf7e – Europe (London)
ami-0a3f9008725d0b4d1 – Europe (Paris)
ami-0c65965703bb0e541 – Europe (Milan)
ami-01b6fcc2337f6420d – Europe (Spain)
ami-07b7defb87a46bb48 – Europe (Frankfurt)
ami-01b3e93b3ac0e1340 – Europe (Zurich)
ami-016edc078b48f370b – Israel (Tel Aviv)
ami-0c90e298af7a2e563 – Middle East (Bahrain)
ami-0f7c14e62ef760768 – Middle East (UAE)
ami-0edd5ecfc56804583 – South America (São Paulo)
Ensure that the security groups are configured to permit connectivity on inbound port 1500.
# AWS related
## What does the Elastic Disaster Recovery machine conversion server do?
The machine conversion server converts the disks to boot and run on AWS.
Specifically, it makes bootloader changes, injects hypervisor drivers, and installs cloud tools.
## How do I change the server AMI on AWS after recovery?
After the machine has been launched by AWS Elastic Disaster Recovery, switching the AMI can be done by launching a vanilla machine from the required AMI, stopping that machine, detaching all the disks (including the root) and then attaching the disks from the drill or recovery instance created by Elastic Disaster Recovery.
## Which AWS services are automatically installed when launching a drill or recovery instance?
AWS Elastic Disaster Recovery (AWS DRS) automatically installs EC2Config. After installation, EC2Config automatically installs the SSM EC2 Configuration Service.
CloudWatch, AWS Powershell or CLI are not automatically installed. This can be done by combining the AWS DRS APIs and the AWS APIs - you can use the AWS DRS APIs to determine the EC2 instance IDs of the machines and then use AWS API/CLI to turn on the detailed monitoring. An alternative approach would be to do it via AWS API only based on the tags you associate with the machine. A third approach would be to do so from the post-launch script.
AWS DRS installs EC2Launch (Windows 2016 only). Customers need to configure EC2Launch based on the specific requirements explained [here](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2launch.html#ec2launch-config). This configuration step needs to be performed post Recovery using the wizard in C:\$1ProgramData\$1Amazon\$1EC2-Windows\$1Launch\$1Settings\$1Ec2LaunchSettings.exe on the drill or recovery instance.
## How long does it take to copy a disk from the AWS Elastic Disaster Recovery staging area to production?
AWS Elastic Disaster Recovery uses internal cloud provider snapshots. This process typically takes less than a minute and the size of the volume does not impact the time.
## What are the differences between conversion servers and replication servers?
Replication servers run on Linux and conversion servers (for Windows machines) run on Windows.
The conversion is done by AWS Elastic Disaster Recovery automatically bringing up a vanilla Windows conversion server machine in the same subnet with the replication servers as part of the launch job.
Both conversion and replication servers have Public IPs
The conversion servers will use the same security groups as the replication server.
The conversion servers must be able to access the AWS Elastic Disaster Recovery Service Manager.
The conversion server machines, just like the Replication servers are managed automatically by Elastic Disaster Recovery. Any attempt to disrupt their automated functionality will result in failed conversions.
## Can I prevent Elastic Disaster Recovery from cleaning up drill instance resources in AWS?
AWS Elastic Disaster Recovery will, by default, remove any resources created during the drill process either when requested by the user or when a new drill instance is launched.
To prevent this in AWS, you can [Activate Termination Protection ](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination) for the drill or recovery instance, and the resources will not be removed upon a new instance launch.
## Why are my Windows Server disks read-only after launching the drill or recovery instance?
When launching drill or recovery instances Windows Server may boot with all the disks as read-only.
This is a common issue that occurs when detaching and attaching data disks. It can be resolved by following the steps in [this Microsoft TechNet article](https://blogs.technet.microsoft.com/askcore/2011/06/02/my-disk-is-read-only-help/).
## What impacts the conversion and boot time of drill and recovery instances?
Prior to launching the drill or recovery instance, AWS Elastic Disaster Recovery goes through a machine conversion server process on the boot volume. The conversion process is fairly quick.
While the actual conversion process itself is quick, the time to boot the drill or recovery instance varies depending on many factors unrelated to any Elastic Disaster Recovery processes. Some of these are controllable and should be taken into account when drill or recovery times are of importance.
+ Operating system - The amount of time required to boot the operating system is dependent on the OS itself. While Linux servers typically boot quickly, Windows servers may take additional time, due to the nature of the Windows OS. If opportunity permits, drill the boot time of the source server. If Linux OS takes a long time to boot, ensure to check that dhclient (Dynamic Host Configuration Protocol Client) is installed on the system so it can pull an IP.
+ Scheduled Windows Updates - If the Windows server has pending patches, ensure those are installed prior to launching the drill or recovery instance. If pending patches remain, the boot time in the cloud may be severely impacted as the patch process may commence upon the initial boot.
+ Boot volume type - Depending on services/applications, boot time may be impacted by disk performance. It is recommended that boot volumes be drilled with a higher performance SSD and even by provisioning IOPs to ensure throughput. This may be more critical during the first initial boot of the server in the cloud, as all initial settings are applied. In many cases, the boot volume type may be scaled back after the initial boot and should be drilled.
**Note**
The first boot of Windows machines on AWS may take up to 45 minutes due to Windows adjusting to the AWS virtual hardware.
## How is the AWS Licensing Model Tenancy chosen for Elastic Disaster Recovery?
Elastic Disaster Recovery conforms to the [Microsoft Licensing on AWS](https://aws.amazon.com/windows/resources/licensing/) guidelines.
## How does Elastic Disaster Recovery interact with interface VPC endpoints?
If you use Amazon Virtual Private Cloud (Amazon VPC) to host your AWS resources, you can establish a private connection between your Amazon VPC and AWS Elastic Disaster Recovery. You can use this connection to allow AWS Elastic Disaster Recovery to communicate with your resources on your VPC without going through the public internet.
Amazon VPC is an AWS service that you can use to launch AWS resources in a virtual network that you define. With a VPC, you have control over your network settings, such as the IP address range, subnets, route tables, and network gateways. With VPC endpoints, the routing between the Amazon VPC and AWS services is handled by the AWS network, and you can use IAM policies to control access to service resources.
To connect your VPC to Elastic Disaster Recovery, you define an *interface VPC endpoint * for Elastic Disaster Recovery. An interface endpoint is an elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported AWS service. The endpoint provides reliable, scalable connectivity to Elastic Disaster Recovery without requiring an internet gateway, network address translation (NAT) instance, or VPN connection. For more information, see [What is Amazon VPC ](https://docs.aws.amazon.com/vpc/latest/userguide/) in the *Amazon VPC User Guide*.
Interface VPC endpoints are powered by AWS PrivateLink, an AWS technology that facilitates private communication between AWS services using an elastic network interface with private IP addresses. For more information, see [AWS PrivateLink](https://aws.amazon.com/privatelink/).
For more information, see [Getting Started](https://docs.aws.amazon.com/vpc/latest/userguide/GetStarted.html) in the *Amazon VPC User Guide*.
If the AWS replication agents are installed with a principal using [ AWSElasticDisasterRecoveryAgentInstallationPolicy ](security-iam-awsmanpol-AWSElasticDisasterRecoveryAgentInstallationPolicy.md) and a VPCE policy is used (to scope down access), add the following statement to your policy:
```
{
"Effect": "Allow",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api::*.*/POST/CreateSessionForDrs"
}
```
## Will AWS Elastic Disaster Recovery reserve EC2 capacity for recovery?
AWS Elastic Disaster Recovery relies on Amazon EC2 On-Demand pools by default. If a specific Amazon EC2 instance type is unavailable to support your recovery, DRS will automatically attempt to scale up the instance repeatedly until an available instance type is found, but in extreme circumstances, instances may not always be available. To ensure the availability of the required instance types you need for your most critical applications, you may purchase [EC2 Capacity Reservations](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html). You can specifically designate which applications you want to use the EC2 Capacity Reservations for by using launch templates.
# Advanced FAQ
## Does AWS DRS support Nutanix?
Nutanix hypervisor is supported along with other hypervisor vendors. The AWS Replication Agent is installed on the virtual machine (VM) and performs block level replication. In addition, the client ISO is booted for failback on the same VM itself.
## Does AWS DRS support VMware vSphere?
VMware vSphere is supported (both on-premises as well as VMware on AWS). Examples of detailed walkthroughs: [Disaster recovery for VMware Cloud on AWS using AWS Elastic Disaster Recovery.](https://aws.amazon.com/blogs/storage/disaster-recovery-for-vmware-cloud-on-aws-using-aws-elastic-disaster-recovery/) [Performing a failback with the DRS Mass Failback Automation client.](https://docs.aws.amazon.com/drs/latest/userguide/failback-failover-drsfa.html)
## Does AWS DRS support Microsoft Hyper-V?
Both Hyper-V and Microsoft Azure are supported. The AWS Replication Agent installation and replication follows the same process described in [Adding source servers.](https://docs.aws.amazon.com/drs/latest/userguide/adding-servers.html) For failback to Azure, review the [Building a disaster recovery site on AWS for workloads on Microsoft Azure](https://aws.amazon.com/blogs/storage/building-a-disaster-recovery-site-on-aws-for-workloads-on-microsoft-azure/) blog post.