웹 애플리케이션이 여러 AZ의 Auto Scaling 그룹에 있는 ALB 뒤의 EC2 인스턴스에서 실행되며 Amazon RDS for MySQL 인스턴스를 사용합니다. Route 53은 별칭 레코드를 사용하여 ALB를 가리킵니다. 회사 정책에 따라 이제 RTO 4시간, RPO 15분으로 지리적으로 격리된 DR(재해 복구) 사이트가 필요하며, 애플리케이션 스택에 대한 변경은 최소화해야 합니다. 애플리케이션 변경을 최소화하면서 이러한 요구 사항을 충족하는 DR 접근 방식은 무엇입니까?

정답은 다른 리전에 중복 환경을 생성하고, DR 리전에 RDS 읽기 복제본을 생성하여 환경이 이를 사용하도록 구성한 후, 상태 확인 기반 장애 조치 정책으로 Route 53에 새 스택을 추가하는 것입니다. 중단 발생 시 읽기 복제본을 기본으로 승격합니다. 이는 RTO 4시간, RPO 15분 요구 사항을 충족하는 재해 복구(DR) 전략입니다. 다른 리전에 읽기 복제본을 두면 RPO 15분을 달성할 수 있으며, 필요 시 읽기 복제본을 기본으로 승격하고 Route 53을 업데이트하여 RTO 4시간 내에 복구할 수 있습니다. 애플리케이션 변경을 최소화하면서 지리적으로 격리된 DR 사이트를 제공합니다. 다른 가용 영역에 중복 환경을 생성하는 것은 지리적으로 격리된 DR 요구 사항을 충족하지 못합니다. 다른 리전에 중복 환경을 생성하고 지연 시간 기반 라우팅을 사용하는 것은 DR이 아닌 성능 최적화에 가깝습니다. RDS 스냅샷을 복사하고 복원하는 것은 RPO 15분 요구 사항을 충족하기 어렵고, 복원 시간이 길어 RTO 4시간을 초과할 수 있습니다.