AWS re:Invent 2025 - Disaster Recovery (DR) with AWS Elastic Disaster Recovery Service (COP356)

AWS Events

8 views • 7 months ago Save 12 min 7 min read

Video Summary

The video discusses the critical importance of disaster recovery (DR) for organizations, highlighting the significant financial and reputational costs of downtime, with examples of companies losing millions due to outages. It introduces AWS Elastic Disaster Recovery (DRS) as a solution that simplifies, makes cost-effective, and enhances resilience. The core functionality of DRS involves agent-based replication of block-level data to a staging area in AWS, enabling low Recovery Point Objectives (RPO) of seconds and Recovery Time Objectives (RTO) of minutes. An interesting fact is that 76% of companies experienced an outage in the past two years, underscoring the widespread need for robust DR strategies.

The presentation details how AWS DRS works, covering its agent installation on source servers (on-premises, other clouds, or AWS EC2), continuous data replication, and the automated failover and failback processes. It contrasts DR with backup and high availability, positioning DRS as a middle ground with moderate cost and significant benefits. Advanced features like post-launch actions and Systems Manager integration are showcased to further automate and simplify the recovery process, reducing complexity and human error.

Short Highlights

The cost of application downtime can range from $500K to $1 million per year for Fortune 1000 companies.
76% of companies experienced an outage in the past two years.
Key DR metrics are Recovery Point Objective (RPO) – how much data can be lost, and Recovery Time Objective (RTO) – how quickly services must be back online.
AWS DRS offers agent-based replication, reducing RPO to seconds and RTO to minutes.
AWS DRS charges include a flat rate of $20 per server per month, plus costs for the staging area and temporary failover instances.

Key Details

The Importance of Disaster Recovery [00:45]

Organizations often underestimate the importance of disaster recovery until it's too late, despite its deep impact on business operations.
Real-life examples illustrate the severe financial consequences of downtime: a global community company lost $8.2 million in revenue, and a US airline lost $150 million in profit.
Beyond direct revenue loss, downtime also incurs significant reputational damage and erodes customer trust.
IDC reports indicate that for Fortune 1000 companies, application downtime can cost $500K to $1 million per year.

"Isn't whether you should have the disaster recovery it's whether you can afford not to."

Choosing the Right DR Strategy: RPO and RTO [03:18]

Two critical metrics, Recovery Point Objective (RPO) and Recovery Time Objective (RTO), are essential for selecting the appropriate DR strategy.
RPO answers "how much data can you afford to lose?" and is measured in time (e.g., hours, minutes, seconds).
RTO answers "how quickly do you want your service or application back up and running?" and considers the business impact of every minute or hour of downtime.
The cost of downtime, exemplified by $500K to $1 million loss for Fortune companies, highlights that every minute counts.

DR Strategies: Backup, Disaster Recovery, High Availability [04:35]

Backup: The most cost-effective foundational strategy, involving data copies with RPO and RTO typically measured in hours.
Disaster Recovery (DR): Focuses on returning to operations, not just restoring data. It offers reduced RPO to seconds and RTO to minutes, with moderate costs.
High Availability (HA): The premium tier, providing resistance to common failures through design and operational mechanisms, with near real-time RPO and RTO, representing a significant investment for the most critical applications.

"The disaster recovery is about return to the operations not just to restore your data."

AWS Elastic Disaster Recovery (DRS) Explained [06:15]

AWS DRS is an agent-based replication service designed for high performance.
It continuously replicates data at the block level from source servers to a lightweight staging area in AWS, reducing RPO to seconds.
A lightweight AWS replication server agent is installed on the source server, which can be an EC2 instance, on-premises server (VMware, HyperV), or other cloud-hosted instances.
The replicated data is stored in a specified AWS region, ensuring it's only seconds behind the primary site when a disaster strikes.

Failover, Failback, and Testing with AWS DRS [07:51]

AWS DRS allows for drills and testing of the DR solution without waiting for a disaster.
In the event of an outage, cyberattack, or hardware failure, a recovery instance can be quickly launched in AWS.
This recovery process, called failover, creates a fully provisioned EC2 instance mapped from the source server, linked to replicated data, allowing applications to serve traffic.
Failback is the process of returning operations to the primary site once it's resolved, with the option to terminate AWS instances to save costs.

"You don't want to wait until the disaster happens and then testify is working so you can easy test on AWS."

Benefits and Features of AWS DRS [09:26]

Lower Cost: Achieved through a low-cost staging area in AWS for replication, avoiding third-party licensing fees.
Automation: Highly automated process, including server conversion to AWS instances, copying configurations, and creating recovery networks.
Point-in-Time Snapshots: Supports point-in-time recovery, crucial for ransomware scenarios where older, clean data sets can be chosen.
Easy Testing: One-click drill functionality is available on the DRS console.
Network Settings: Ability to copy source network infrastructure, including security groups and port/route changes, for seamless recovery.
Data Banking: Utilizes AWS Service Control Policies to ensure a clean, isolated environment against active deletion attempts during attacks.

AWS DRS Architecture and DR Patterns [11:51]

AWS DRS supports four DR patterns, all culminating in the AWS cloud as the destination.
Source servers can be on-premises, from other clouds, or within AWS itself (cross-region or cross-availability zone DR).
For on-premises or other cloud to AWS recovery, the replication agent on source servers continuously replicates data to a lightweight staging area on AWS.
One replication server can support up to 15 source servers, ensuring high-performance, parallel replication.
During recovery, servers are spun up as mapped AWS EC2 instances with EBS attached.

Replication Server Functionality and Cross-Region DR [14:04]

The replication server sends replication status to AWS DRS for easy monitoring.
DRS automatically creates and terminates replication servers, giving users full control via the console.
Health updates and status are available in one place.
For cross-region DR within AWS, replication leverages native AWS services like S3 cross-region replication and EC2-to-EC2 transfer for high performance and minimal latency. The overall workflow remains the same.

"The whole workflow is exactly same. It's just like more performance."

AWS DRS Pricing Model [16:00]

The service is charged in three tiers:
- Service Fee: A flat rate of $20 per month per server for the DRS service itself.
- Staging Area: Charges based on minimum EC2 and EBS usage for the staging area where data is replicated, dependent on data volume and EC2 instance type.
- Temporary Failover Cost: During drills or disaster events, temporary EC2 instances are billed, which are terminated once recovery is complete.

Advanced Feature: Post-Launch Actions [17:18]

Post-launch actions provide a framework to automatically execute predefined or customized actions upon launching recovery instances.
This framework automates validation, configuration, and testing tasks defined in scripts.
It significantly reduces the manual effort previously required after instance launch.
Integration with AWS Systems Manager allows running commands and automating scripts on recovered instances for tasks like connectivity checks and permission validation.
This feature aims to reduce complexity and human error in the DR process.