Select your cookie preferences

We use essential cookies and similar tools that are necessary to provide our site and services. We use performance cookies to collect anonymous statistics, so we can understand how customers use our site and make improvements. Essential cookies cannot be deactivated, but you can choose “Customize” or “Decline” to decline performance cookies.

If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept” or “Decline.” To make more detailed choices, choose “Customize.”

Replication related - AWS Elastic Disaster Recovery

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 falls 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?

Elastic Disaster Recovery provisions the replication server(s) and automatically manages the addition and removal of the servers as necessary.

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.

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.

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 networks controls to limit inbound IPs.

How long does a rescan take?

A rescan may occur after a reboot of the source server. The rescan time will vary depending on the size of the source disks. The time depends on the performance of the disks (linear read), staging area disk performance, and the rate of write operations on the source server (which are sent in parallel with the rescan). The rescan is functioning normally as long as its moving forward and is not "stuck".

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.

  2. Select the same subnet as the subnet used in the replication settings of your source machine.

  3. Make sure that the security group allows TCP Port 1500 inbound access.

  4. On the source machine, browse to: https://{test_server_ip}:1500/speedtest

  5. 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.

PrivacySite termsCookie preferences
© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved.