AWS Elastic Disaster Recovery: replication internals, drills and failback

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

AWS Elastic Disaster Recovery (DRS) copies every block written to a source server into low-cost staging storage in your AWS account, then builds full-size EC2 instances from point-in-time snapshots when you launch a drill or a recovery. The result is crash consistent, not application consistent. DRS launches the instances, but it does not move your users: redirecting traffic happens outside the service, and a failback is only safe once everything written during the failover has replicated back.

Commands below come from AWS documentation or were written for this article from the CLI reference. None was run in a lab. Replace the example IDs with your own.

Why it matters

DRS looks simple until the day it is needed. Three misunderstandings cause most of the trouble:

• Treating a healthy replication state as proof of recovery. It proves blocks are arriving. It says nothing about boot, drivers, DNS, licensing or application start order.
• Running a drill on a network that can reach production. A drill uses the same launch settings and point-in-time data as a real recovery, so the copy can behave like the original.
• Deleting the wrong object during failback. Some actions remove the recovery points you are depending on.

AWS uses precise words, and this article follows them. A recovery launches instances. A drill is a non-disruptive test of that launch. A failover redirects traffic. A failback returns to the source, with DRS replicating data back.

How replication works

An AWS Replication Agent on each source server watches block writes and immediately attempts to copy them to a staging area subnet in your account. There, EC2 replication servers receive the data and write it to EBS staging volumes. Snapshots of those volumes become the recovery points.

Network requirements reduce to two ports:

TCP 1500 traffic is compressed and encrypted, using TLS 1.2 from end to end. Each replication server has its own TLS certificate, which the agent validates. Data is decrypted on arrival before being written to the volumes.

If the staging subnet uses an S3 gateway endpoint with a restrictive policy, the policy must allow the DRS buckets. AWS lists them on the network page. One of them is al2023-repos-<REGION>-de612dc2, because replication servers run Amazon Linux 2023.

The replication FAQ fills in the mechanics:

• Replication servers are provisioned automatically and recycled about every 14 days with the latest image, which can cause temporary lag.
• The default type is t3.small, and a typical ratio is 15 volumes to one replication server.
• Staging volumes match the provisioned size of the source disks, one to one.
• Compression is LZ4, with AWS quoting 60 to 70 percent depending on the data.
• Replication and conversion servers have no static IP addresses.

By default the data travels over the public internet to an automatically assigned public IPv4 address. The "Use private IP" option changes the route only. It does not create a VPN or Direct Connect link, and that link must already exist. Selecting IPv6 gives no automatic IPv4 fallback, and the Failback Client works over IPv4 only.

What crash consistent means here

AWS states that data still held in memory is not replicated until it is written to a volume. A recovered database therefore goes through the same start-up recovery it would after a power failure. Test that path for each application, rather than assuming it.

AWS describes a typical recovery point of seconds and a recovery time of 5 to 20 minutes. Those figures depend on conditions. The recovery point holds only while network and staging resources keep pace with writes. The recovery time depends on boot time, instance type and volume performance, and AWS gives averages of about 5 minutes for Linux and 20 minutes for Windows. Application start-up is yours to measure.

Sizing the replication path

The bandwidth rule is that available bandwidth must be at least the sum of average write rates for all servers sharing the path. AWS recommends at least 20 percent headroom and at least 24 hours of measurement.

# Linux: read the wkB/s column for each replicated device
iostat -x 3

# Windows
Get-Counter '\PhysicalDisk(*)\Disk Write Bytes/sec' -SampleInterval 3 -MaxSamples 10

A hypothetical example: three servers averaging 4, 6 and 10 MBps total 20 MBps. With 20 percent headroom that is 24 MBps, or 192 Mbps. As an editorial suggestion, leave compression out of the calculation, because the saving depends on your data.

Averages hide bursts, and initial synchronisation needs far more than the steady-state figure. By default DRS uses all available bandwidth over five concurrent connections, so set a per-server limit in Mbps if the link is shared with production traffic.

Disk choices matter too. The automatic volume type setting is the AWS default and switches type by write throughput. The option applies only to disks over 125 GiB, as smaller disks use magnetic HDD by default. A write-heavy database that cannot converge may need a faster staging disk, at extra cost.

Warning: Changing the staging disk encryption option after replication has started restarts replication from the beginning. Choose the KMS key before you install agents at scale.

Other settings are gentler. AWS's impact table lists a small pause for changing the staging subnet or replication server type, and no impact for changing private IP routing.

Reading replication health

Query the state directly. The --query expression below was written for this article from the CLI output fields:

aws drs describe-source-servers \
  --filters sourceServerIDs=s-123456789abcdefgh \
  --query 'items[].{id:sourceServerID,state:dataReplicationInfo.dataReplicationState,lag:dataReplicationInfo.lagDuration,error:dataReplicationInfo.dataReplicationError.error}'

The mapping of CONTINUOUS to Healthy and the one-line readings of BACKLOG and DISCONNECTED are inferred from the console descriptions, as the CLI page lists the values without defining them.

Two console fields are often confused. Lag is how far behind a recovery instance would be if you launched now. Backlog is the data written at source and not yet copied. Lag can resolve by itself, but Stalled needs intervention.

A rescan follows a hard reboot or crash, a disk being added, removed or resized, or writes made while the driver was unhooked. On Windows, a graceful reboot does not trigger one. Expect a rescan after maintenance on storage, and schedule accordingly.

The common performance errors map to specific checks:

The port tests and service checks appear in AWS's failback troubleshooting, where they apply to the recovery instance. Using them for forward replication is an adaptation for this article.

Point-in-time retention

A point-in-time policy has exactly three rules. Ten-minute points for one hour and hourly points for 24 hours are fixed. Only the daily rule can change, between 1 and 365 days, with a default of 7. Longer retention costs more EBS snapshot storage. Changing this policy is not one of the gentler changes: AWS's impact table says the replication server is disconnected as a safety measure.

aws drs update-replication-configuration \
  --source-server-id s-123456789abcdefgh \
  --pit-policy \
    enabled=true,interval=10,retentionDuration=60,ruleID=1,units="MINUTE" \
    enabled=true,interval=1,retentionDuration=24,ruleID=2,units="HOUR" \
    enabled=true,interval=1,retentionDuration=14,ruleID=3,units="DAY"

For ransomware or silent corruption, the newest point is the wrong one. Practise choosing an older point during a drill.

Note also that these snapshots live in your account, and someone with access to that account can delete them. DRS is not an immutable backup. Keep a separate backup control for that requirement.

Launch settings that catch people out

Launch settings apply only to newly launched instances. Review them well before they are needed.

• Right-sizing. With right-sizing active, DRS overrides the instance type in your launch template. If you need a specific type, set right-sizing to inactive.
• Recovery encryption. The KMS field in the launch template is not used. Recovery volume encryption comes from the replication settings.
• Copy Private IP. The address must fall within the target subnet's CIDR, and AWS warns against the option when source and instance share a subnet through a VPN.
• Public IP. DRS launch templates disable public IP assignment by default. A failback over the public internet needs the recovery instance to have one.
• Fast recovery mode. Fast mode skips conversion and suits AWS-to-AWS recovery. It needs agent 6.42.20 or later. Optimal is the default and runs full conversion.
• Template name and device settings. AWS says not to alter the launch template name or custom device name. DRS generates the first and uses the source's device names to map disks.

Running a drill

AWS suggests drilling at least quarterly, and including failback in the initial drill and in some regular ones. A safe order, as an editorial sequence built on those pages:

1. Launch into an isolated subnet with no route to production. AWS calls this out specifically for Active Directory, since a drill copy could otherwise talk to the real domain controller.
2. If you replicate domain controllers, launch them first and wait until they are running.
3. Pick the recovery point deliberately:

aws drs describe-recovery-snapshots --source-server-id s-123456789abcdefgh

aws drs start-recovery --is-drill \
  --source-servers recoverySnapshotID=pit-123456789abcdefgh,sourceServerID=s-123456789abcdefgh

4. Without recoverySnapshotID, DRS uses "Use most recent data". It tries to create a fresh snapshot, which needs a live connection to the source, and waits up to 10 minutes before using the last consistent state. If the source is already gone, choosing an existing point can shorten recovery.
5. Follow the job with aws drs describe-jobs, then read the detail with aws drs describe-job-log-items --job-id drsjob-123456789abcdefgh.
6. Test the application, including a real login and a data check, and record the time from start to first successful transaction.
7. Inventory the drill resources for a separately reviewed cleanup:

aws drs describe-recovery-instances \
  --query 'items[].{Id:recoveryInstanceID,Drill:isDrill,Source:sourceServerID}'

The listing returns drill and real recovery instances together, so record Drill, the source and the exact instance identity before a qualified owner follows the approved cleanup procedure. The query was written for this article from the documented output fields.

A drill can run once initial synchronisation is complete, even during Lag or Stall. Running another drill for the same source also cleans up earlier drill resources.

Large groups have hard limits. The service quotas are 100 servers in one job, 500 across all jobs, 20 concurrent jobs, and one concurrent job per source server. None of those is adjustable. A real recovery of many hundreds of servers must be sequenced in advance.

Failing back to on-premises

Starting point: your workload runs on recovery instances in AWS and the site is repaired.

Warning: The Failback Client replicates the recovery instance's data onto the volumes of the server it boots. As an editorial precaution, treat anything on those volumes as replaced. Confirm the target server and the volume mapping first, and never run it against a server holding data you still need.

Requirements to confirm first:

• x86_64 hardware. For arm64, fail back within AWS.
• Volumes of the same size or larger, and the same number or more.
• At least 4 GB of dedicated RAM, secure boot off and the hardware clock on UTC.
• TCP 1500 inbound and TCP 443 outbound on the recovery instance.
• Traffic to S3 from the server you are failing back to, which downloads replication software from a public bucket.
• An instance profile with AWSElasticDisasterRecoveryRecoveryInstancePolicy.
• For credentials, a role with AWSElasticDisasterRecoveryFailbackInstallationPolicy, assumed with aws sts assume-role. The default session lasts one hour.

Boot mode has a trap. For Linux, boot the client in the same mode as the recovery instance. For Windows, use the same mode as the Windows source server.

Evidence required before failback

This is a planning checklist, not an executable failback runbook. The Failback Client can replace target-volume contents, so the exact procedure needs an isolated rehearsal and qualified owner review. Record the target hardware, disk mappings, boot mode, protected copies and an independent management path before scheduling the outage. Verify the vendor-provided client image and its published SHA-512 hash as part of that plan.

The readiness gate comes before the cutover. AWS requires the recovery instance to show Ready for failback and Healthy for data replication. An original source server undergoes a rescan before reaching Ready; a replacement server needs a full copy. Allow for that work before the outage window.

The application owner must define how writes will be quiesced and how the team will prove that all failover data has reached the destination. Record the last accepted application transaction, replication state and acceptable data-loss boundary. A green replication indicator alone does not prove application consistency.

The reviewed runbook must cover conversion and reboot, the correct post-recovery boot device, application and data validation, and the decision to redirect traffic. Define stop conditions and the authoritative writable copy at every stage so both sites cannot accept conflicting writes.

Only after service acceptance should the owner decide whether to terminate, delete or disconnect the recovery resources. Preserve required recovery evidence and confirm ongoing protection before cleanup. This article provides no overwrite, failback-launch or termination commands.

Failback problems usually show as a specific message. AWS's replication error list includes botocore.exceptions.CredentialRetrievalError from clock skew, resolved by setting the hardware clock to UTC. The client runs in the foreground, so closing the shell ends it. Use screen or tmux.

For a server inside AWS, the cross-Region flow uses Start reversed replication (a separately reviewed reprotection operation). All data crosses the network and cross-Region transfer charges apply. Initialise DRS in both Regions before any incident, because reversed replication depends on it. After a cross-Region failback the new instances are not protected until you choose Start reversed replication on the recovery instance in the source Region. AWS warns not to perform that step during a drill, because it replaces the instances DRS replicates.

What to choose and why

These are editorial recommendations.

• Use a dedicated DR account for staging and recovery, so that a compromise of the production account does not automatically reach the recovery points. Plan this early, because moving servers between accounts requires reinstalling the agent.
• Use private routing if you already have a stable VPN or Direct Connect link with spare capacity. Do not build one for replication until you have measured writes.
• Keep a separate backup. DRS is built for fast recovery of recent states. Long retention, immutability and archive remain a backup problem.
• Treat databases on their own terms. For a database with tight data-loss limits, compare DRS with the engine's own replication and test the crash-recovery path.
• Move traffic with something you have already tested. Route 53 is one example, but the procedure must exist outside DRS.

Risks and limits

Account scale. 300 replicating servers per account is a hard limit, tied by AWS to EBS snapshot rate limits. Beyond that, use multiple accounts or Regions.

Source support. Sources must be x86_64, or arm64 Linux on Graviton for AWS-to-AWS only. BitLocker and similar OS disk encryption are not supported. Linux needs kernel headers matching the running kernel.

Costs. AWS's pricing example for 100 servers and 30 TB totals US$6,389.03 a month at US East rates, of which only US$2,044 is the DRS fee of US$0.028 per server hour. An 8-hour drill in the same example adds US$122.94. The DRS fee is the same in every Region, but EBS and EC2 rates are not, so use Sydney or Melbourne rates for your own estimate. Charges begin when the agent is installed, so control who can install it.

Warning: Do not use Disconnect from AWS on a source server with launched recovery instances. It terminates replication resources, including recovery points.

Warning: A new launch from the same source cleans up all previous recovery instances. Be certain before launching again during a real recovery. AWS separately recommends termination protection after validation and before re-routing, to prevent accidental termination. The pages do not say it stops this clean-up, so do not rely on it for that.

Warning: In a cross-Region setup, stopping replication deletes all previous points in time. Do it only after validating the failover instances. In a drill, stop replication only for the drill's reversed source server, never for the original.

While failed over, recovery instances are not themselves protected and produce no new recovery points. You also keep paying for DRS and replication.

What is not covered here: per-Region agent and operating system support changes often, so confirm the current list. The DRSFA mass failback client for VMware vCenter and recovery plans were outside this article's scope.

Sources

Opened 2026-11-10. Sources behind the corrections reopened 10 November 2026.

• Failback terminology
• Network requirements
• Data routing and throttling
• Replication FAQ
• Concepts: RPO, RTO and point-in-time snapshots
• General FAQ
• Bandwidth planning
• Staging volumes
• Replication settings and their impact
• Recovery dashboard
• Replication performance errors
• Point-in-time policy
• Launching instances
• EC2 launch template considerations
• General launch settings
• Preparing for failover and drills
• Preparing for failback
• Performing a failback
• Failback Client procedure
• Failback Client errors
• Failback replication errors
• Cross-Region failback
• Installation requirements
• Best practices
• Disaster recovery at scale
• Service quotas and endpoints
• Pricing
• AWS CLI v2 drs reference

This article was originally published on 10 November 2026.