AWS Builder Center

Builder Center

How to Use AWS Elastic Disaster Recovery Service (AWS DRS)

How to Use AWS Elastic Disaster Recovery Service (AWS DRS)

This step-by-step guide walks through implementing end-to-end disaster recovery using AWS Elastic Disaster Recovery (DRS). Learn how to protect an EC2 workload with cross-region replication, monitor replication health, perform recovery drills, execute failover and failback, and clean up safely—covering the complete DR lifecycle for real-world AWS workloads.

Piyush Chaudhari

Customers often have diverse backup and recovery requirements, driven by the varying levels of criticality across workloads—and even individual components within a single workload. Key questions naturally arise: How quickly must this service be restored? Does this component require high availability? Is this data or resource even necessary to back up? Addressing these questions is essential to defining an effective, fit-for-purpose backup and recovery strategy. In this post, we’ll explore how AWS Elastic Disaster Recovery can be used to protect your applications and ensure rapid recovery in the event of a disaster.
Before diving in, it’s worth noting that many organizations choose to implement disaster avoidance rather than traditional disaster recovery. Disaster avoidance focuses on preventing outages altogether by designing highly resilient architectures across multiple locations, minimizing the impact of hardware failures or regional disruptions. This approach relies on fault-tolerant, highly available, and self-healing applications. For example, a simple single-tier web application running on EC2 can often achieve this through AWS’s native Auto Scaling capabilities. However, such designs are not always feasible—particularly for legacy systems or tightly coupled platforms. In these cases, a well-defined disaster recovery strategy becomes essential. That’s exactly what we’ll walk through next, covering the end-to-end configuration process in detail.

Prerequisites

Creating our Production Webserver

Setting up Elastic Disaster Recovery Service

Install the Agent on our WebServer and setup replication

Monitoring Replication

Testing recovery using recovery drills

Configuring reverse replication/failback

Testing failback

Cleaning up

Prerequisites

To keep this guide focused on the core AWS Elastic Disaster Recovery (DRS) configuration, several foundational components are assumed to already be in place. As such, the creation and baseline configuration of the following resources are intentionally out of scope:
AWS Account & Permissions
An active AWS account with the required service permissions enabled, including access to AWS Elastic Disaster Recovery (DRS), Amazon EC2, and AWS Systems Manager (SSM). These permissions are necessary to support replication, recovery instance provisioning, and agent-based management.
Networking Architecture (Multi-Region)
Two Virtual Private Clouds (VPCs), each deployed in a separate AWS region to enable cross-region disaster recovery. In this walkthrough, the London region is designated as the production environment, while Ireland serves as the disaster recovery region. For simplicity, default VPCs are used; however, the same principles apply to custom VPC designs. Each VPC must include:
  • At least one public subnet with routing configured to an Internet Gateway for outbound internet connectivity
  • A Security Group permitting inbound HTTP (TCP/80) traffic from the internet and unrestricted outbound traffic to support system updates, replication, and recovery operations
IAM Role for EC2 Instances
An IAM role (referred to here as WebServerIAMRole) attached to all source and recovery EC2 instances. This role provides the minimum required permissions for DRS and SSM operations and includes the following managed policies:
  • AmazonSSMManagedInstanceCore – Enables secure, agent-based management and automation via AWS Systems Manager
  • AWSElasticDisasterRecoveryEc2InstancePolicy – Grants permissions required for source instance replication and lifecycle management
  • AWSElasticDisasterRecoveryRecoveryInstancePolicy – Allows recovery instances to be launched, orchestrated, and validated during failover and testing scenarios
IAM-Role
IAM-Role
With these prerequisites in place, we can focus entirely on the end-to-end configuration and operational workflow of AWS Elastic Disaster Recovery, from replication setup to recovery validation.

Creating our Production Webserver

For the purpose of this walkthrough, I’ll be provisioning a minimal Linux-based web server that we can onboard to AWS Elastic Disaster Recovery (DRS). If you already have an existing EC2 instance that you plan to protect with DRS, you can safely skip this provisioning step. That said, be aware that several configuration elements defined during instance creation are referenced and reused later in the guide.

Launching the EC2 Instance

Navigate to the Amazon EC2 Console and select Launch instance.
Configure the instance with the following parameters:
  • Name: Assign a descriptive name such as MyWebServer
  • AMI:
    Amazon Linux 2023 AMI
    al2023-ami-2023.9.20251208.0-kernel-6.12-x86_64
AL2023
  • Instance type:
    t3.medium> A minimum of a medium instance is recommended to ensure adequate /tmp disk space for successful installation and operation of the Elastic Disaster Recovery agent.
  • Key pair:
    Proceed without a key pair> Access to the instance will be handled exclusively via AWS Systems Manager (SSM).
  • Security group:
    Select an existing WebServer security group, or create a new one as outlined in the Prerequisites section.
  • Advanced details:
    • IAM instance profile: WebServerIAMRole (refer to prerequisites)
    • User data: Paste the initialization script provided below
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
#!/bin/bash
set -euxo pipefail

# Update system packages
dnf update -y

# Install Apache HTTP Server
dnf install -y httpd

# Enable and start Apache
systemctl enable --now httpd

# Create initial index page (fallback)
cat <<'EOF' > /var/www/html/index.html
<html>
<body>
<h2>Hello! This is my WebServer</h2>
<p>Region information will be populated after boot.</p>
</body>
</html>
EOF

# Create metadata-based update script
cat <<'EOF' > /usr/local/bin/update-index-with-region.sh
#!/bin/bash
set -euo pipefail

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

REGION=$(curl -s \
-H "X-aws-ec2-metadata-token: ${TOKEN}" \
http://169.254.169.254/latest/meta-data/placement/region)

cat <<HTML > /var/www/html/index.html
<html>
<body>
<h2>Hello! This is my WebServer</h2>
<p>Running in <b>${REGION}</b></p>
</body>
</html>
HTML
EOF

# Make script executable
chmod 0755 /usr/local/bin/update-index-with-region.sh

# Run once immediately
/usr/local/bin/update-index-with-region.sh

# Schedule script to run on every reboot
cat <<'EOF' > /etc/cron.d/update-web-region
@reboot root /usr/local/bin/update-index-with-region.sh
EOF

# Set hostname
hostnamectl set-hostname mywebserver.mydomain.com
Once these parameters are set, proceed with launching the instance.
The user data script above performs a minimal bootstrap of the instance by installing and configuring Apache HTTP Server (httpd), effectively turning the EC2 instance into a lightweight web server. It also explicitly sets the system hostname to MyWebServer to make the instance easily identifiable during validation and recovery exercises.
A startup cron job is configured to dynamically update the AWS region displayed on the web page each time the instance boots. This becomes particularly useful later in the guide, as it allows us to immediately verify whether the workload is running in its original region (for example, London) or has been successfully recovered in the target recovery region (such as Ireland).
All remaining configuration options can be left at their default values. Once launched, allow a minute or two for the instance initialization to complete and for the instance to transition to a running and healthy state.
EC2-Ready
At this point, it’s a good idea to check that the server is operating as expected. So copy the Public IP Address, and make sure it opens in a browser window. It should look something like this:
NOTE: You’ll need to use http://<public_ip_address>, as we haven’t setup SSL so https won’t work and will give you a “Site can’t be reached” or “Timed out” error

Setting up Elastic Disaster Recovery Service

With the production web server now fully operational, the next step is to configure AWS Elastic Disaster Recovery (DRS). DRS must be explicitly enabled in every AWS region involved in replication and recovery.
In this scenario, we’ll simulate a disaster recovery lifecycle by performing a failover from eu-west-2 (London) to eu-west-1 (Ireland), followed by a failback to eu-west-2 once the primary environment is restored. To support this workflow, DRS must be enabled in both regions—the source (London) and the recovery (Ireland).
The enablement process itself is identical across regions; however, it’s important to remember that the configuration must be repeated separately in each region you plan to use for replication, testing, or recovery operations. Skipping this step in any target region will prevent DRS from orchestrating recovery actions when they’re needed most.
  • Head to the Elastic Disaster Recovery console, and select the region you want to failover to (eu-west-1 in my case)
  • If this is your first time to the DRS console, you’ll be presented with a welcome screen. Click the Configure and initialize
  • On the Set up replication servers screen, select a subnet that will be used to host the replication server, and click Next
A replication server is simply an EC2 instance that will handle the replication of data between your production resources and your DR resources. Leave the size as default (t3.small) for our scenario, which is the most cost effective instance type and should work well for most common workloads
  • On the Volumes and security groups screen, leave all options as default, and click Next
  • On the Configure additional replication settings, leave all options as default and click Next
  • On the Set default DRS launch settings, change the Instance type right-sizing from Active (basic) to Inactive.
This will avoid DRS attempting to change our instance size in our demo. Ideally, you should be right-sizing your resources regularly, so you shouldn’t need this enabled really, unless you’re perhaps using DRS as part of a migration into AWS from a non-AWS environment.
  • Leave all other options as default, and click Next
On the Set default EC2 launch template, set the following options
  • Subnet = select an appropraite subnet that will provide your DR resources with the relevant network access
  • Security groups = Select our previously created WebServerAccess security group (see pre-reqs section)
  • Instance type = t3.small
  • Advanced settings > IAM instance profile = select our WebServerIAMRole
  • Advanced settings > Auto assign public IP = Yes
    Leave all other options as default and click Next
  • On the Review and initialize screen, review your options and click Configure and initialize
We’ve now configured the basics of our Elastic Disaster Recovery Service in our Production region.
  • Repeat the above steps in your Ireland region (eu-west-1 in my case)

Install the Agent on our WebServer and setup replication

Before any recovery actions can take place within AWS Elastic Disaster Recovery (DRS), a source server must first be onboarded. Registering a source server initiates the core DRS workflow, triggering the automatic provisioning of a replication server in the target (failover) region. Once provisioned, this replication infrastructure begins continuously replicating block-level data from the production environment to the recovery region.
This end-to-end process—including source server onboarding, replication server lifecycle management, and ongoing data synchronization—can be observed logically within the Source servers section of the DRS console, as illustrated below.
  • To install the agent on our WebServer, navigate to the Installation instructions by clicking Learn more from within the DRS Source servers console. The specific page we’ll be using in this scenario is the installation instructions for Linux, as shown below:
  • Copy the command to download the agent from the install instructions and replace the region in the url with the AWS region into which we’re replicating — which in this case will be eu-west-1
1
wget -O ./aws-replication-installer-init https://aws-elastic-disaster-recovery-eu-west-1.s3.eu-west-1.amazonaws.com/latest/linux/aws-replication-installer-init
Keep this stored as we’ll need it next
  • In the EC2 console in your production region (eu-west-2), select your running WebServer instance and click Connect
  • In the resulting Connect to instance screen, select the Session Manager tab and click Connect
This will then open a secure SSH session to our WebServer instance
  • Once connected to the instance, paste the command you copied in the previous step to download the DRS Agent onto the instance. You may need to provide sudo permissions as below
  • With the agent downloaded, proceed to install it using the install command from the install instructions
1
chmod +x aws-replication-installer-init; sudo ./aws-replication-installer-init
  • Once executed, you’ll be asked to provide a region name, and to confirm which disks you require replicating. Type eu-west-1 (our failover region) for the region and simply press Enter to confirm you require all disks replicating
  • The Agent will then proceed to download the relevant data onto your instance and install the Agent. The installation process can take up to 10 minutes or so to complete, after which you should be able to see your WebServer in the DRS Source servers console, as well as the replication instance within the EC2 console that will have been created to handle the replication:
Source server in the DRS Source servers console
Source server in the DRS Source servers console
Replication instance that DRS automatically provisions to handle replication
Replication instance that DRS automatically provisions to handle replication

Monitoring Replication

Once the DRS agent is successfully installed on the source instance and the replication infrastructure is provisioned, the next step is to actively monitor replication health and progress.
Navigate to the AWS Elastic Disaster Recovery (DRS) console and open the Source servers tab. Locate the registered WebServer instance and review the Data replication status column to track its current state.
It’s normal to observe an Initializing status for several minutes after agent installation. During this phase, DRS finalizes replication server setup, establishes secure connectivity, and performs initial block-level synchronization. Typically, replication begins within 5–10 minutes, so a short delay at this stage is expected and does not indicate an issue.
When the status transitions to Ready for recovery, it confirms that the source instance data in eu-west-2 (London) is fully synchronized with the recovery region eu-west-1 (Ireland). At this point, no compute resources are actively running in the recovery region—only continuously replicated storage is maintained until a test or failover is initiated.
In this implementation, the initial synchronization completed in approximately 15–20 minutes from the start of replication, after which the environment was fully prepared to launch a disaster recovery instance on demand.

Testing recovery using recovery drills

Having a system that reports replication healthy and ready for recovery is only part of the equation. Without validating the recovery workflow itself, there’s no guarantee that a real disaster event will unfold as expected. Recovery testing is therefore a critical control—not an optional exercise.
AWS Elastic Disaster Recovery (DRS) addresses this requirement through its Recovery drill capability. A recovery drill allows you to simulate a full recovery in the target region without disrupting production workloads or altering source systems. This enables teams to validate infrastructure provisioning, networking, security controls, and operational runbooks under realistic conditions—before an actual incident occurs.
To initiate a recovery drill:
  1. In the DRS console of the failover region, navigate to the Source servers tab.
  2. Select the WebServer source instance.
  3. Choose Initiate recovery job → Initiate recovery drill.
  4. Retain the default Use most recent data point in time option to test recovery against the latest replicated state, then click Initiate drill.
  5. Select View job details to track job execution, instance launch progress, and validation status.
At this point, you’ll see within the Job log that DRS is starting a conversion job. Here, DRS will provision a “Conversion Server”, which will essentially prepare your synchronised data to be applied to a fresh new instance in your failover region. You can see this conversion server within the EC2 console of your failover region.
The nice thing about the DRS Job log is that it automatically updates without you needing to hit refresh (Cloudtrail, I'm looking at you!), so you can see in near-real-time the progress of the failover instance (or “recovery instance”, as DRS calls it).
Once the Conversion server has done its thing, DRS will terminate it and proceed with spinning up a fresh t3.small instance to host our replicated data. In my scenario, the conversion server took around three minutes.
With the job log on Started launching recovery instance, you may notice in the EC2 console your failover instance enters a stopping state. This is normal as it needs to reboot during the recovery process. It may stay on this state for a few minutes, but don’t be alarmed.
After a few minutes, your recovery instance should be in a running state and ready for testing! If all went well, you should be able to navigate to your failover instance’s public IP address (http, not https, don’t forget!) and see that we have a DR instance in the eu-west-1 region. Excellent!
Completed job log
Completed job log

Configuring reverse replication/failback

If you’ve followed the walkthrough to this point—well done. Let’s recap what has been successfully achieved:
  • A production web server has been deployed in eu-west-2 (London)
  • AWS Elastic Disaster Recovery (DRS) has been configured to continuously replicate this workload to eu-west-1 (Ireland)
  • A simulated disaster scenario was assumed for the London region, and a recovery drill was executed to launch a replacement production instance in Ireland
  • The recovered instance was validated to confirm application functionality and operational readiness
In a real disaster scenario, a recovery drill would not be used—instead, a full recovery operation would be initiated. At that point, production workloads would be actively running in the failover region. This introduces an important consideration: once operating from the recovery region, there is no secondary failover environment available should another incident occur. Clearly, this is not an ideal steady state.
AWS Elastic Disaster Recovery addresses this challenge through reverse replication (failback). Reverse replication allows data to be continuously synchronized from the active recovery environment back to the original production region—in this case, from eu-west-1 (Ireland) back to eu-west-2 (London)—thereby re-establishing resilience and enabling a controlled return to the primary region.
To configure reverse replication:
  1. Open the DRS console in the failover region (Ireland in this example).
  2. Navigate to Recovery instances, select the active recovery instance, and choose Start reversed replication.
⚠️ Important: DRS must have been enabled in the original source region before the recovery instance was launched. Without this prerequisite, failback (reverse replication) cannot be initiated.
With reverse replication in place, you are now positioned to safely stabilize operations in the recovery region while preparing for a seamless transition back to the primary environment.
This then begins the reverse sync process, which looks pretty much identical in the console to the original sync process we performed earlier, except this time the details are shown in the Recovery instances tab of your failover region rather than the source servers tab. You can also view the same state in the source servers tab of your source region.
  • Over in the EC2 console in your source region (London), you should now see that a new replication server has been provisioned by DRS to handle the reverse replication
Reverse replication server in our source region
Reverse replication server in our source region
  • After 10 minutes or so (depending on your storage size and network), you should now have a recovery instance that’s ready for failback testing

Testing failback

So now our recovery instance is ready to test failback, let’s go ahead and give it a try
  • Head to the DRS Console > source servers in your source region (London, for me), select your WebServer, and select Initiate recovery job > Launch for failback
  • You may wish to double check the Launch settings first by selecting Actions > Edit EC2 launch template, to validate the correct IAM profile, instance type, etc.
  • Again, we can see a Conversion server launch in our source region, and after a few minutes this will terminate and our failback instance is created and will begin processing the replicated data. Again, don’t worry about your failback instance staying in a stopping state for a while. This will take at least 5–10 minutes, and the progress can be monitored in the Recovery job history tab of your source region
  • Once complete, let’s give it a test by navigating to the webpage (http, not https!)

Cleaning up

Now as this was a recovery drill, and not a real recovery, we’re going to leave our original instance in place with replication enabled. In a real disaster scenario, you’d terminate/remove the original source server as it would no longer be required.
It’s crucial that you perform the below steps in the correct regions, as you may risk terminating your source servers!
  • In the DRS console of your source region, having selected the Recover instances tab, select your recently created failback instance, and select Actions > Terminate recovery instances
  • In the source servers tab of your source region, select your failover instance and select Actions > Disconnect from AWS
  • Then in the same region/console, select Actions > Delete server
  • In the Recovery instances tab of your failover region, select your recovery instance and select Actions > Terminate recovery instances
And in a real life scenario, that would be us finished. At this point, we’re still replicating our original source webserver to our failover region, and would be ready to initiate failover in the event of an actual disaster. However as this is a demonstration, I’m going to continue removing the DRS config below. If you wish to retain this DR setup, then you should stop here. If not, follow on below:
  • In the Source servers tab of your failover region, select your source instance and select Actions > Disconnect from AWS
  • Then Actions > Delete server
  • Then finally, we can delete our original source instance from the EC2 console in our source region
Finally, it’s worth validating that all relevant resources such as replication servers, failover instances, etc. are gone. It can take five minutes or so for replication servers to be removed, as DRS does this automatically after we remove source server config, so you may have to be patient here and try to avoid manually removing them.

Final Thoughts & Conclusion

Disaster recovery is not just a technical checkbox—it’s a critical business capability that determines how resilient your workloads truly are when things go wrong. As this walkthrough demonstrates, AWS Elastic Disaster Recovery (DRS) provides a practical, cost-effective, and highly automated approach to protecting workloads that cannot easily adopt multi-region, active-active architectures.
By the end of this guide, we’ve designed and validated a complete DR lifecycle: onboarding a production workload, enabling continuous cross-region replication, testing recovery safely through drills, executing failover and failback via reverse replication, and finally cleaning up resources responsibly. Just as importantly, we’ve shown that testing matters—replication status alone does not guarantee recovery success. Regular recovery drills and failback testing are what transform a DR design into a dependable operational capability.
DRS shines particularly in scenarios involving legacy systems, tightly coupled applications, or lift-and-shift workloads, where redesigning for disaster avoidance isn’t always feasible. It allows organizations to meet aggressive RPO and RTO objectives without maintaining always-on standby infrastructure, keeping costs predictable while preserving readiness.
That said, disaster recovery is not a one-time exercise. As applications evolve, so should your DR strategy—networking, IAM roles, launch templates, monitoring, and operational runbooks must all be revisited periodically. Treat DRS as part of your broader resilience and operational excellence practice, not just an emergency tool.
If you take one thing away from this guide, let it be this:
A recovery plan you haven’t tested is a risk, not a safeguard.
With AWS Elastic Disaster Recovery, you now have the tooling to test, validate, and recover with confidence—before a real disaster puts that confidence to the test.

OK, folks that’s it for this post. Have a nice day guys…… Stay tuned…..!!!!!

Don’t forget to like & share this post on social networks!!! I will keep on updating this blog. Please do follow!!!
# disaster-recovery# aws-community-builders# aws-community# amazon-ec2
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article