Woongjin PreLife Establishes DR System for 21 On-Premises Servers Using AWS DRS

Woongjin PreLife established a disaster recovery system based on AWS Elastic Disaster Recovery (AWS DRS) for 21 on-premises servers and conducted mock recovery drills. 86% of the protected assets were Windows Server, representing a legacy environment with mixed generations from Windows Server 2012 R2 to 2019. This project was carried out over approximately four months with the goals of pre-validating migration and securing recovery means for 24-hour operational services.

Replication Configuration and Performance Optimization

To process approximately 48TB of data during the initial synchronization phase, the existing 500Mbps line was upgraded to 1Gbps. The t3 series, used as the initial replication server, is a burstable instance type that caused performance degradation due to CPU credit exhaustion and EBS bandwidth limits. To resolve this, the replication server was changed to the compute-optimized c6i series, and EBS volume throughput was increased. Subsequently, in the continuous replication phase, the load decreased, allowing the replication server specification to be downgraded from c6i.xlarge to c6i.large, reducing costs by approximately 50%.

Addressing Boot and Service Recovery Issues

During the drill, cases were identified where the replication status was normal but booting failed or services did not run. For Windows servers, boot failures occurred due to mismatches between UEFI and legacy BIOS boot modes, which were resolved by converting to GPT using the mbr2gpt command. Linux servers experienced boot path errors due to fixed device name assignments, which were corrected by switching to UUIDs. Additionally, servers with Active Directory dependencies were redefined to prioritize data assurance rather than full boot recovery, shortening recovery time by attaching the replicated volumes to other servers.

Monitoring and Operational Framework

CloudWatch alarms were configured to prevent replication lag. Response priorities were set by classifying the LagDuration metric exceeding 30 minutes as an emergency and the Backlog metric exceeding 50GB as a warning. Failover test results showed that it took a minimum of 30 minutes to a maximum of 3 hours to reach service availability, due to the time required to apply accumulated Windows updates. Through this process, a recovery plan defining recovery objectives and priorities for each server was secured, and the recovery environment will be verified through regular drills conducted once every six months.