A manufacturer must protect 80 on-premises VMware VMs running Windows and Linux, needing failback after drills and RTO measured in minutes after a site loss. Snapshots copied nightly miss the recovery window and stall cutover testing. Which continuous replication approach enables rapid, orchestrated recovery into AWS?

AWS Elastic Disaster Recovery uses lightweight agents on the Windows and Linux VMs to continuously replicate block-level changes into low-cost staging storage in a staging VPC. Versioned launch templates define instance type, networking, and post-launch actions; orchestrated, non-disruptive drills and real failover can provide recovery in minutes for 80 VMs, with coordinated failback after the site recovers. AWS Application Migration Service also uses agents for continuous replication and test launches, but it is designed for one-time migration rather than an ongoing disaster-recovery posture, and lacks the centralized drill orchestration, multi-VM point-in-time consistency, and automated failback needed here. A pilot-light fleet of stopped EC2 instances synced from nightly AMIs can launch quickly, but it does not continuously capture changes on on-premises VMware VMs; repeated image conversion also makes it a poor fit for these Windows and Linux sources. A Storage Gateway volume gateway can cache on-premises data and support restoration from EBS snapshots, but this is point-in-time backup rather than continuous replication: the RPO follows snapshot intervals, and cutover still requires restores that miss the recovery window. Exam caveat: Migration and disaster-recovery services may both mention agents and test instances; distinguish ongoing isolated drills and failback from one-time migration. Practical check: Validate agent OS support, replication bandwidth, staging subnet mappings in launch templates, and a full isolated drill with application verification.