Plan for disaster recovery and recommend Recovery Time Objective (RTO) and Recoverty Point Objective (RPO). Incorporate resilience discussion and advise an RTO & PRO target when engaging with customer. Customer acceptance and adoption on RTO/RPO is not required. • Establish a process to establish workload resilience including: • RTO & RPO target • Explanation of the recovery process for the core components of the architecture • Customer awareness and communication on this topic Please provide the following as evidence: • Descriptions or documents on workload resilience guidance met the three criteria defined above • Description of how resilience is implementation in one (1) of the submitted customer examples including reasons for exception when RTO&RPO is not defined

다음은 자연스러운 한국어 번역입니다: **재해 복구 계획을 수립하고 복구 시간 목표(RTO, Recovery Time Objective) 및 복구 지점 목표(RPO, Recovery Point Objective)를 권고하세요.** 고객과의 협의 시 복원력(resilience) 논의를 포함하고 RTO 및 RPO 목표를 제안하세요. 고객의 RTO/RPO 승인 및 채택은 필수 사항이 아닙니다. • 다음을 포함한 워크로드 복원력 구축 프로세스를 수립하세요: • RTO 및 RPO 목표 • 아키텍처 핵심 구성 요소의 복구 프로세스 설명 • 이 주제에 대한 고객 인지 및 소통 **다음을 증빙 자료로 제출해주세요:** • 상기 정의된 3가지 기준을 충족하는 워크로드 복원력 가이드라인에 대한 설명 또는 문서 • 제출된 고객 사례 중 1개에서 복원력이 구현된 방식에 대한 설명 (RTO 및 RPO가 정의되지 않은 경우 예외 사유 포함)

This engagement delivered a serverless static content delivery architecture (S3, CloudFront, Lambda) where disaster recovery is inherently managed by AWS service design. S3 provides 99.999999999% durability with automatic cross-region replication capabilities, CloudFront's global edge network provides automatic failover across edge locations, and Lambda functions execute across multiple availability zones automatically. Given the stateless nature of static content delivery and absence of databases or stateful components, formal RTO/RPO definitions were not applicable. The architecture's inherent resilience through AWS managed services eliminated traditional disaster recovery planning requirements. --- This engagement focused on AI/ML performance optimization and pipeline implementation with emphasis on high availability rather than formal disaster recovery planning. The architecture leveraged AWS managed services (Lambda, ElastiCache with replication, S3 with versioning) providing inherent resilience, but formal RTO/RPO targets were not defined as the customer prioritized rapid deployment and iterative optimization. System availability improved to 99.9% through Multi-AZ deployments and automatic failover mechanisms, but comprehensive disaster recovery procedures with documented recovery processes were not established as part of the engagement scope. Our disaster recovery framework is documented and demonstrated in our Kotech Market implementation. --- Our resilience framework guides customers through RTO/RPO target definition based on business impact analysis and workload criticality. We categorize system components by business criticality, mapping recovery requirements to appropriate AWS architectures including Multi-AZ deployments, automated backups, and failover mechanisms. Recovery strategies balance business continuity needs with cost considerations. Implementation Example - Kotech Market Technology Transfer Platform: Defined tiered recovery objectives based on service criticality. Core matching engine and technology search services classified as business-critical with RTO target of 1 hour and RPO target of 15 minutes, implemented through Multi-AZ ECS deployment with Application Load Balancer automatic failover and RDS Multi-AZ configuration with automated backups every 15 minutes. Document processing pipeline, being asynchronous and non-blocking, accepts longer recovery with RTO of 4 hours and RPO of 1 hour, relying on SQS message retention (14 days) and S3 versioning for data protection. S3 data lake achieves near-zero RTO with cross-region replication enabled for critical technology transfer data. Recovery procedures include automated RDS point-in-time recovery from snapshots, ECS task automatic replacement on failure through health checks, and documented manual procedures for complete service restoration. CloudWatch alarms monitor service health and trigger SNS notifications to operations team when failures are detected. Customer was educated on recovery capabilities and trade-offs, with quarterly DR testing recommended to validate recovery procedures, though formal DR drills were deferred to post-launch operational phase managed by the customer's team. Disaster Recovery Framework: https://wishket-team.notion.site/disaster-recovery --- This engagement used Amazon Lightsail managed services which provide automatic backups and Multi-AZ database configurations, handling disaster recovery at the service level. While backup recovery time improved from 72 hours to 30 minutes and service availability reached 99.9%, formal RTO/RPO target definitions and documented disaster recovery procedures were not established. Lightsail's integrated backup and restore capabilities met the customer's resilience needs without requiring comprehensive DR planning and testing procedures.

이 프로젝트는 서버리스 정적 콘텐츠 전송 아키텍처(S3, CloudFront, Lambda)를 구축했으며, 재해 복구는 AWS 서비스 설계에 의해 본질적으로 관리됩니다. S3는 자동 교차 리전 복제 기능과 함께 99.999999999%의 내구성을 제공하고, CloudFront의 글로벌 엣지 네트워크는 엣지 위치 전반에 걸쳐 자동 장애 조치를 제공하며, Lambda 함수는 여러 가용 영역에서 자동으로 실행됩니다. 정적 콘텐츠 전송의 무상태 특성과 데이터베이스나 상태 유지 구성 요소의 부재로 인해, 공식적인 RTO/RPO 정의는 적용되지 않았습니다. AWS 관리형 서비스를 통한 아키텍처의 고유한 복원력으로 인해 전통적인 재해 복구 계획 수립 요구사항이 제거되었습니다. --- 이 프로젝트는 공식적인 재해 복구 계획보다는 고가용성에 중점을 둔 AI/ML 성능 최적화 및 파이프라인 구현에 집중했습니다. 아키텍처는 AWS 관리형 서비스(Lambda, 복제 기능이 있는 ElastiCache, 버전 관리가 있는 S3)를 활용하여 고유한 복원력을 제공했지만, 고객이 신속한 배포와 반복적 최적화를 우선시함에 따라 공식적인 RTO/RPO 목표는 정의되지 않았습니다. Multi-AZ 배포와 자동 장애 조치 메커니즘을 통해 시스템 가용성이 99.9%로 향상되었지만, 문서화된 복구 프로세스를 포함한 포괄적인 재해 복구 절차는 프로젝트 범위에 포함되지 않았습니다. 재해 복구 프레임워크는 Kotech Market 구현에 문서화되어 시연되었습니다. --- 저희의 복원력 프레임워크는 고객이 비즈니스 영향 분석과 워크로드 중요도를 기반으로 RTO/RPO 목표를 정의할 수 있도록 안내합니다. 비즈니스 중요도에 따라 시스템 구성 요소를 분류하고, Multi-AZ 배포, 자동화된 백업, 장애 조치 메커니즘을 포함한 적절한 AWS 아키텍처에 복구 요구사항을 매핑합니다. 복구 전략은 비즈니스 연속성 요구사항과 비용 고려사항의 균형을 맞춥니다. 구현 예시 - Kotech Market 기술이전 플랫폼: 서비스 중요도에 따른 계층화된 복구 목표를 정의했습니다. 핵심 매칭 엔진과 기술 검색 서비스는 비즈니스 크리티컬로 분류되어 RTO 목표 1시간, RPO 목표 15분으로 설정했으며, Application Load Balancer 자동 장애 조치를 포함한 Multi-AZ ECS 배포와 15분마다 자동 백업되는 RDS Multi-AZ 구성을 통해 구현했습니다. 비동기적이고 비블로킹 특성의 문서 처리 파이프라인은 더 긴 복구 시간을 허용하여 RTO 4시간, RPO 1시간으로 설정했으며, SQS 메시지 보존(14일)과 S3 버전 관리를 통한 데이터 보호에 의존합니다. S3 데이터 레이크는 중요한 기술이전 데이터에 대해 교차 리전 복제를 활성화하여 거의 제로에 가까운 RTO를 달성합니다. 복구 절차에는 스냅샷으로부터의 자동화된 RDS 특정 시점 복구, 상태 점검을 통한 장애 시 ECS 태스크 자동 교체, 전체 서비스 복구를 위한 문서화된 수동 절차가 포함됩니다. CloudWatch 알람은 서비스 상태를 모니터링하고 장애 감지 시 운영팀에 SNS 알림을 전송합니다. 고객에게 복구 능력과 트레이드오프에 대해 교육했으며, 복구 절차 검증을 위한 분기별 재해 복구 테스트를 권장했지만, 공식적인 재해 복구 훈련은 고객팀이 관리하는 출시 후 운영 단계로 연기되었습니다. 재해 복구 프레임워크: https://wishket-team.notion.site/disaster-recovery --- 이 프로젝트는 자동 백업과 Multi-AZ 데이터베이스 구성을 제공하는 Amazon Lightsail 관리형 서비스를 사용하여, 서비스 수준에서 재해 복구를 처리했습니다. 백업 복구 시간이 72시간에서 30분으로 개선되고 서비스 가용성이 99.9%에 도달했지만, 공식적인 RTO/RPO 목표 정의와 문서화된 재해 복구 절차는 수립되지 않았습니다. Lightsail의 통합된 백업 및 복구 기능이 포괄적인 재해 복구 계획 및 테스트 절차 없이도 고객의 복원력 요구사항을 충족했습니다.