Exam relevance: Domain 3. AWS Elastic Disaster Recovery (AWS DRS) continuously replicates supported source servers to a low-cost staging area in AWS and supports recovery launches into EC2. It is a disaster-recovery service, distinct from AWS Transform MGN, which is primarily used to migrate servers to AWS.

1. When to Use DRS

Use DRS when the recovery objective requires a tested server-level recovery environment in AWS for on-premises or supported cloud source servers. It can support recovery from source-site outages, ransomware events, and other disruptions when the replication and recovery plan are configured appropriately.

DRS does not by itself make the application multi-Region active-active, guarantee a specific RTO/RPO, migrate every database logically, or replace application-level backup and recovery controls.

2. Architecture and Recovery Flow

Source server
    | block-level replication over network
    v
AWS staging subnet / replication servers / replicated disks
    |
    +--> non-disruptive recovery drill (test launch)
    |
    +--> recovery launch after incident
              |
              v
       EC2 recovery instances in recovery VPC
              |
     validate -> route traffic -> operate / fail back
  1. Assess source inventory, OS/application compatibility, dependency maps, network bandwidth, account/Region, and recovery objectives.
  2. Configure replication settings and source connectivity; install agents where required.
  3. Replicate changed blocks to the AWS staging area and monitor lag, health, and capacity.
  4. Run recovery drills into an isolated test network; validate boot, application dependencies, security, licensing, and performance.
  5. During an incident, launch recovery instances from a selected point in time, validate business functions, and shift traffic through the planned DNS/network path.
  6. For failback, re-protect or reverse-replicate according to the supported workflow, reconcile writes, and return traffic only after acceptance.

3. Design Considerations

  • RTO/RPO: derive them from measured replication lag, recovery launch time, application startup, dependency restoration, validation, and traffic cutover. DRS features do not replace a timed recovery test.
  • Recovery points: understand the available point-in-time retention and consistency model; crash-consistent block replication is not automatically application-consistent for every database.
  • Network: size sustained bandwidth for source change rate and plan routes, DNS, firewall rules, TLS, private connectivity, and recovery subnet capacity.
  • Recovery account/Region: separate recovery administration from source operations where appropriate; prebuild IAM roles, VPCs, security groups, quotas, and routing.
  • Application groups: recover dependency-ordered tiers together. A recovered server without identity, DNS, licensing, secrets, or data dependencies is not a recovered service.
  • Drills: run non-disruptive drills at a defined cadence; isolate test launches to prevent accidental production writes or duplicate scheduled jobs.

4. Security, Reliability, and Cost

  • Use least-privilege replication and recovery roles, encryption and key policies, centralized audit, and protected credentials.
  • Protect recovery access against source-account compromise; use independent backups and immutable copies for ransomware resilience.
  • Monitor source-agent health, replication lag, staging capacity, recovery launch failures, and drill results. Page owners when the measured RPO is at risk.
  • Costs include replication/staging resources, retained recovery points, drills, recovery compute/storage, network transfer, and parallel operation. Recovery instances may incur normal compute costs when launched.
  • Verify supported OS/Region configurations, quotas, pricing, ports, and recovery-point behavior in current DRS documentation.

5. DRS vs Similar Services

ServicePrimary decision
AWS Elastic Disaster RecoveryMaintain a server-level DR replication and recovery path into AWS
AWS Transform MGNRehost servers as part of a migration and cutover program
AWS BackupProtect supported resources with managed backup policies and restore workflows
AWS DMSMigrate/replicate supported database data logically with full load/CDC
AWS DataSyncMove files/objects between supported storage locations

These services can be combined. For example, server recovery may use DRS while databases also have native backup, replication, and application-consistency procedures.

6. Exam Scenarios

Scenario: A company must recover 80 on-premises Windows/Linux application servers to AWS within two hours after a site outage. It needs a quarterly recovery exercise and cannot afford full duplicate EC2 fleets running continuously.

Recommended approach: Assess supported servers and dependencies, configure AWS DRS to replicate to a staging area, and keep the recovery VPC, IAM, DNS, and quotas ready. Run isolated recovery drills and measure end-to-end restoration against the two-hour objective. Maintain independent application/database backups and test write consistency and failback.

Trap: A successful block-replication dashboard is not proof that the full application meets its RTO/RPO.

7. Exam Tips

  • DRS is a DR/recovery pattern; MGN is a server migration/cutover pattern.
  • Replication is not backup, and server recovery is not application acceptance.
  • State the recovery point, launch procedure, dependencies, traffic switch, validation, and failback plan.
  • Use measured drill results rather than memorized universal RTO/RPO figures.

8. Official References