Technical Solution The partner must demonstrate comprehensive technical expertise in their chosen specialization domain through detailed solution documentation that contains an in-depth analysis of service selection decisions, including rationale for choosing specific AWS services over available alternatives. Their technical solution description should directly reference the architecture diagram and explain each component's role in the overall system, establishing clear connections between customer requirements and technical decisions. Describe the technical solution implemented. Reference the architecture diagram in the explanation. Please include the following in your response: 1. Justify each service relevant to the designation domain, outlining the analysis of the alternatives considered and rejected. 2. Describe the integration points between different system components

## 기술 솔루션 (Technical Solution) 파트너는 선택한 전문화 도메인에서 포괄적인 기술 전문성을 입증해야 합니다. 이는 서비스 선택 결정에 대한 심층 분석이 포함된 상세한 솔루션 문서화를 통해 이루어져야 하며, 여기에는 사용 가능한 대안들 중에서 특정 AWS 서비스를 선택한 근거가 포함되어야 합니다. 기술 솔루션 설명서는 아키텍처 다이어그램을 직접 참조하고 전체 시스템에서 각 구성 요소의 역할을 설명하여, 고객 요구사항과 기술적 결정 사이의 명확한 연결고리를 구축해야 합니다. **구현된 기술 솔루션을 설명하십시오. 설명 시 아키텍처 다이어그램을 참조해 주시기 바랍니다.** **다음 내용을 응답에 포함해 주세요:** 1. **지정 도메인과 관련된 각 서비스의 타당성을 입증하고, 검토했으나 채택하지 않은 대안들에 대한 분석 내용을 설명하십시오.** 2. **서로 다른 시스템 구성 요소 간의 통합 지점(Integration Points)들을 설명하십시오.**

Service Selection and Architecture Justification The solution leverages Amazon S3 and CloudFront as the foundation for static content delivery, chosen over maintaining EC2-based Nginx servers due to superior scalability, built-in redundancy, and elimination of server management overhead. CloudFront with Origin Access Control (OAC) was selected over alternative CDN solutions for its native AWS integration, granular caching controls enabling content-type-specific TTL policies (30 days for images, 1 hour for HTML/CSS/JS), and 90% cache hit rate achievement. AWS DataSync facilitated the terabyte-scale migration over alternatives like custom rsync scripts, providing automated synchronization, bandwidth throttling, and data integrity verification without custom development effort. The image processing pipeline utilizes Lambda for serverless compute, avoiding the cost and management complexity of maintaining dedicated EC2 instances or ECS containers for sporadic image processing workloads. SNS was chosen as the event routing mechanism over direct S3-to-Lambda triggers to enable fan-out capabilities for both SQS queuing and Slack notifications via Chatbot, while SQS provides message durability and retry logic that direct Lambda invocations cannot guarantee. This event-driven architecture automatically scales with upload volume and achieves 50-90% file size reduction through intelligent GIF-to-MP4 conversion. Integration Architecture and Data Flow The system integrates through multiple touchpoints: S3 bucket events trigger SNS topics that fan out to both SQS queues (feeding Lambda processors) and Chatbot (providing Slack notifications), creating a resilient processing chain with visibility. Route 53 weighted routing enabled gradual traffic migration between Nginx and CloudFront during the three-phase cutover, with real-time log comparison validating the transition. CloudFront logs stored in S3 feed into AWS Glue for ETL processing and Amazon Athena for SQL-based analysis, enabling data-driven optimization of cache policies, content popularity tracking, and traffic pattern analysis that informs continuous architectural improvements. --- Service Selection and Justification For the technology transfer platform's microservices architecture, we chose Amazon ECS over Amazon EKS because the application teams lacked Kubernetes expertise and required faster time-to-market. ECS provided native AWS integration with simpler operational overhead, while EKS would have demanded additional investment in Kubernetes training and cluster management. We selected AWS Cloud Map for service discovery instead of third-party solutions like Consul because it integrates seamlessly with ECS and eliminates the need to manage additional infrastructure, though we considered Consul for its multi-cloud capabilities before prioritizing AWS-native simplicity. Amazon SQS was chosen for asynchronous document processing over Amazon Kinesis because the workload didn't require real-time stream processing or complex event ordering—simple message queuing with retry logic satisfied the use case while minimizing cost. For data analytics, we built a data lake on Amazon S3 with AWS Glue for ETL rather than using Amazon Redshift because the analytics workload was exploratory and batch-oriented, not requiring sub-second query performance that would justify Redshift's higher cost. Amazon RDS provided the right balance for transactional data over DynamoDB because the existing application relied heavily on relational queries and complex joins that would require significant refactoring for NoSQL. Integration Architecture The architecture centers on API Gateway as the unified entry point, routing requests to appropriate ECS services while implementing throttling, authentication, and request validation. ECS services communicate internally through AWS Cloud Map for service discovery, with the matching engine dynamically locating the technology search service without hardcoded endpoints, while SQS queues decouple synchronous operations from time-intensive document processing. AWS CodeBuild orchestrates the CI/CD pipeline, automatically building container images on code commits, storing them in Amazon ECR, and triggering blue-green deployments to ECS through AWS CodeDeploy, with AWS KMS providing encryption keys across services and CloudWatch collecting centralized logs and metrics for monitoring. --- Serverless OCR Pipeline Architecture We selected Amazon Textract as our primary OCR engine over alternatives like Google Cloud Vision and Azure Computer Vision due to its superior integration with AWS services and cost-effectiveness for high-volume processing. The preprocessing Lambda function was chosen over EC2-based solutions because it eliminates idle compute costs and automatically scales to handle concurrent image uploads through S3 event triggers. We rejected container-based solutions (ECS/EKS) as they would introduce unnecessary complexity and management overhead for stateless image processing tasks. The pipeline integrates through event-driven triggers where S3 PUT events invoke the preprocessing Lambda, which outputs optimized images to a dedicated S3 bucket that triggers parallel OCR processing. The result integration Lambda subscribes to both Textract SNS notifications and the math-specialized engine's SQS queue, correlating results by image ID before persisting to DynamoDB. This asynchronous architecture enables zero-wait user experience while maintaining loose coupling between components. AI Inference Optimization For lightweight models, we chose Lambda with Provisioned Concurrency over always-on EC2 instances because the predictable sub-2-second response times justified the slightly higher per-invocation cost compared to managing instance fleets. Heavy models run on GPU-backed EC2 Auto Scaling Groups behind SQS queues rather than SageMaker endpoints, as ASGs provide more granular control over instance types and scaling policies for our variable workload patterns. ElastiCache was selected over DynamoDB for inference caching due to its microsecond latency requirements and support for semantic similarity searches through Redis modules. Real-time Video Processing and MLOps The video pipeline uses SNS fanout to SQS queues for each processing stage (answer generation, editing, streaming prep) rather than Step Functions, as SQS provides better cost optimization for long-running tasks and built-in retry mechanisms. WebSocket connections are managed through API Gateway WebSocket APIs integrated with Lambda, chosen over self-managed WebSocket servers on EC2 for automatic scaling and reduced operational burden. CloudWatch custom metrics track model accuracy across all stages, triggering Lambda functions via EventBridge rules when thresholds are breached, with SNS notifications alerting the ML team and automatically initiating retraining workflows stored in S3. --- Service Selection and Architecture We selected Amazon Lightsail as the core infrastructure service over alternatives like EC2 with manual WordPress installation or Elastic Beanstalk. Lightsail was chosen because it provides a pre-configured WordPress environment with integrated components (virtual servers, managed databases, load balancers, and CDN) in a unified package, significantly reducing configuration complexity while maintaining enterprise-grade capabilities. This approach was preferred over EC2's granular control, which would have required extensive manual configuration of security groups, load balancers, and database clusters, and over Elastic Beanstalk, which lacks WordPress-specific optimizations. Amazon Route 53 was implemented for DNS management instead of maintaining third-party DNS providers or using CloudFront's native domain features alone. Route 53's latency-based routing and health check capabilities provided intelligent traffic distribution to the nearest edge location, achieving 60% reduction in page load times globally. The service integrates with CloudFront and Lightsail through DNS routing policies, automatically directing users to optimal endpoints based on geographic location and service health status. CloudFront CDN complements Lightsail's content delivery by caching static assets (images, CSS, JavaScript) at global edge locations, chosen over Lightsail's built-in CDN alone due to superior global coverage and advanced optimization features. CloudFront integrates with Lightsail as the origin server, automatically pulling and caching content while performing image optimization and WebP conversion for mobile devices. The integration points include Route 53 directing traffic to CloudFront distributions, which then fetch uncached content from Lightsail WordPress instances, with automatic cache invalidation triggered by content updates.

**서비스 선택 및 아키텍처 타당성** 본 솔루션은 정적 콘텐츠 전송의 기반으로 Amazon S3와 CloudFront를 활용하며, EC2 기반 Nginx 서버 운영 대신 이를 선택한 이유는 뛰어난 확장성, 내장된 중복성, 그리고 서버 관리 오버헤드 제거 때문입니다. CloudFront와 Origin Access Control(OAC)은 다른 CDN 솔루션 대신 선택되었는데, 이는 AWS와의 네이티브 통합, 콘텐츠 유형별 TTL 정책을 가능하게 하는 세밀한 캐싱 제어(이미지는 30일, HTML/CSS/JS는 1시간), 그리고 90% 캐시 적중률 달성이 가능하기 때문입니다. AWS DataSync는 사용자 정의 rsync 스크립트 등의 대안 대신 테라바이트 규모의 마이그레이션을 지원하여, 사용자 정의 개발 노력 없이 자동화된 동기화, 대역폭 제한, 데이터 무결성 검증을 제공합니다. 이미지 처리 파이프라인은 서버리스 컴퓨팅을 위해 Lambda를 활용하며, 간헐적인 이미지 처리 워크로드를 위한 전용 EC2 인스턴스나 ECS 컨테이너 유지 관리의 비용과 복잡성을 피합니다. SNS는 직접적인 S3-Lambda 트리거 대신 이벤트 라우팅 메커니즘으로 선택되었는데, 이는 SQS 큐잉과 Chatbot을 통한 Slack 알림 모두에 대한 팬아웃 기능을 지원하며, SQS는 직접적인 Lambda 호출로는 보장할 수 없는 메시지 내구성과 재시도 로직을 제공합니다. 이러한 이벤트 기반 아키텍처는 업로드 볼륨에 따라 자동으로 확장되며, 지능적인 GIF-to-MP4 변환을 통해 50-90% 파일 크기 감소를 달성합니다. **통합 아키텍처 및 데이터 플로우** 시스템은 다중 접점을 통해 통합됩니다: S3 버킷 이벤트는 SNS 토픽을 트리거하여 SQS 큐(Lambda 프로세서 공급)와 Chatbot(Slack 알림 제공) 모두로 팬아웃되어, 가시성을 가진 복원력 있는 처리 체인을 생성합니다. Route 53 가중 라우팅은 3단계 전환 과정에서 Nginx와 CloudFront 간의 점진적 트래픽 마이그레이션을 가능하게 했으며, 실시간 로그 비교로 전환을 검증했습니다. S3에 저장된 CloudFront 로그는 ETL 처리를 위해 AWS Glue로, SQL 기반 분석을 위해 Amazon Athena로 전달되어, 캐시 정책의 데이터 기반 최적화, 콘텐츠 인기도 추적, 지속적인 아키텍처 개선에 정보를 제공하는 트래픽 패턴 분석을 가능하게 합니다. --- **서비스 선택 및 타당성** 기술 이전 플랫폼의 마이크로서비스 아키텍처를 위해 Amazon EKS 대신 Amazon ECS를 선택한 이유는 애플리케이션 팀이 Kubernetes 전문지식이 부족했고 더 빠른 출시가 필요했기 때문입니다. ECS는 더 간단한 운영 오버헤드로 AWS와의 네이티브 통합을 제공했으며, EKS는 Kubernetes 교육과 클러스터 관리에 추가 투자가 필요했을 것입니다. Consul과 같은 서드파티 솔루션 대신 AWS Cloud Map을 서비스 디스커버리로 선택한 이유는 ECS와 완벽하게 통합되고 추가 인프라 관리 필요성을 제거하기 때문입니다. 다만 멀티클라우드 기능 때문에 Consul을 고려했지만 결국 AWS 네이티브의 단순성을 우선시했습니다. Amazon Kinesis 대신 Amazon SQS를 비동기 문서 처리용으로 선택한 이유는 워크로드가 실시간 스트림 처리나 복잡한 이벤트 순서를 요구하지 않았기 때문입니다. 재시도 로직을 가진 간단한 메시지 큐잉이 사용 사례를 만족시키면서 비용을 최소화했습니다. 데이터 분석을 위해서는 Amazon Redshift 대신 AWS Glue를 ETL로 사용하는 Amazon S3 기반 데이터 레이크를 구축했는데, 분석 워크로드가 탐색적이고 배치 지향적이어서 Redshift의 높은 비용을 정당화할 서브초 쿼리 성능이 필요하지 않았기 때문입니다. Amazon RDS는 DynamoDB 대신 트랜잭션 데이터에 적절한 균형을 제공했는데, 기존 애플리케이션이 관계형 쿼리와 복잡한 조인에 크게 의존했고 이를 NoSQL로 리팩토링하려면 상당한 작업이 필요했기 때문입니다. **통합 아키텍처** 아키텍처는 API Gateway를 통합 진입점으로 중심에 두고, 적절한 ECS 서비스로 요청을 라우팅하면서 스로틀링, 인증, 요청 검증을 구현합니다. ECS 서비스는 서비스 디스커버리를 위해 AWS Cloud Map을 통해 내부적으로 통신하며, 매칭 엔진이 하드코딩된 엔드포인트 없이 기술 검색 서비스를 동적으로 찾고, SQS 큐는 동기식 작업과 시간 집약적인 문서 처리를 분리합니다. AWS CodeBuild는 CI/CD 파이프라인을 오케스트레이션하여 코드 커밋 시 자동으로 컨테이너 이미지를 빌드하고 Amazon ECR에 저장한 후 AWS CodeDeploy를 통해 ECS로의 블루-그린 배포를 트리거하며, AWS KMS는 서비스 전반에 걸쳐 암호화 키를 제공하고 CloudWatch는 모니터링을 위한 중앙집중식 로그와 메트릭을 수집합니다. --- **서버리스 OCR 파이프라인 아키텍처** Google Cloud Vision과 Azure Computer Vision 같은 대안들 대신 Amazon Textract를 기본 OCR 엔진으로 선택한 이유는 AWS 서비스와의 뛰어난 통합성과 대용량 처리에 대한 비용 효율성 때문입니다. 전처리 Lambda 함수는 EC2 기반 솔루션 대신 선택되었는데, 이는 유휴 컴퓨팅 비용을 제거하고 S3 이벤트 트리거를 통해 동시 이미지 업로드를 처리하도록 자동 확장되기 때문입니다. 상태가 없는 이미지 처리 작업에 불필요한 복잡성과 관리 오버헤드를 초래할 컨테이너 기반 솔루션(ECS/EKS)은 거부했습니다. 파이프라인은 이벤트 기반 트리거를 통해 통합되며, S3 PUT 이벤트가 전처리 Lambda를 호출하고, 이는 최적화된 이미지를 전용 S3 버킷에 출력하여 병렬 OCR 처리를 트리거합니다. 결과 통합 Lambda는 Textract SNS 알림과 수학 전문 엔진의 SQS 큐 모두를 구독하여, DynamoDB에 지속화하기 전에 이미지 ID로 결과를 상관관계 분석합니다. 이러한 비동기 아키텍처는 구성 요소 간 느슨한 결합을 유지하면서 사용자 대기 시간 제로 경험을 가능하게 합니다. **AI 추론 최적화** 경량 모델의 경우 상시 가동 EC2 인스턴스 대신 프로비저닝된 동시 실행(Provisioned Concurrency)을 가진 Lambda를 선택했는데, 예측 가능한 2초 미만의 응답 시간이 인스턴스 플릿 관리 대비 약간 높은 호출당 비용을 정당화했기 때문입니다. 중량 모델은 SageMaker 엔드포인트가 아닌 SQS 큐 뒤의 GPU 지원 EC2 Auto Scaling Groups에서 실행되는데, ASG가 가변적인 워크로드 패턴에 대해 인스턴스 유형과 확장 정책에 대한 더 세밀한 제어를 제공하기 때문입니다. ElastiCache는 마이크로초 지연 시간 요구사항과 Redis 모듈을 통한 의미적 유사성 검색 지원 때문에 추론 캐싱용으로 DynamoDB 대신 선택되었습니다. **실시간 비디오 처리 및 MLOps** 비디오 파이프라인은 각 처리 단계(답변 생성, 편집, 스트리밍 준비)에 대해 Step Functions 대신 SQS 큐로의 SNS 팬아웃을 사용하는데, SQS가 장시간 실행 작업에 대한 더 나은 비용 최적화와 내장 재시도 메커니즘을 제공하기 때문입니다. WebSocket 연결은 EC2의 자체 관리 WebSocket 서버 대신 Lambda와 통합된 API Gateway WebSocket API를 통해 관리되는데, 자동 확장과 운영 부담 감소를 위해서입니다. CloudWatch 사용자 정의 메트릭은 모든 단계에서 모델 정확도를 추적하여 임계값이 위반될 때 EventBridge 규칙을 통해 Lambda 함수를 트리거하고, SNS 알림으로 ML 팀에게 경고하며 S3에 저장된 재훈련 워크플로우를 자동으로 시작합니다. --- **서비스 선택 및 아키텍처** 수동 WordPress 설치를 사용하는 EC2나 Elastic Beanstalk과 같은 대안들 대신 Amazon Lightsail을 핵심 인프라 서비스로 선택했습니다. Lightsail을 선택한 이유는 통합 구성 요소(가상 서버, 관리형 데이터베이스, 로드 밸런서, CDN)가 포함된 사전 구성된 WordPress 환경을 통합 패키지로 제공하여, 엔터프라이즈급 기능을 유지하면서 구성 복잡성을 크게 줄이기 때문입니다. 이 접근법은 보안 그룹, 로드 밸런서, 데이터베이스 클러스터의 광범위한 수동 구성이 필요한 EC2의 세밀한 제어보다, 그리고 WordPress 전용 최적화가 부족한 Elastic Beanstalk보다 선호되었습니다. Amazon Route 53은 서드파티 DNS 제공업체 유지나 CloudFront의 네이티브 도메인 기능만 사용하는 것 대신 DNS 관리를 위해 구현되었습니다. Route 53의 지연 시간 기반 라우팅과 헬스 체크 기능은 가장 가까운 엣지 위치로의 지능적 트래픽 분산을 제공하여 전 세계적으로 페이지 로드 시간을 60% 단축했습니다. 이 서비스는 DNS 라우팅 정책을 통해 CloudFront와 Lightsail과 통합되어, 지리적 위치와 서비스 상태에 따라 자동으로 사용자를 최적의 엔드포인트로 안내합니다. CloudFront CDN은 전역 엣지 위치에서 정적 자산(이미지, CSS, JavaScript)을 캐싱하여 Lightsail의 콘텐츠 전송을 보완하는데, 뛰어난 글로벌 커버리지와 고급 최적화 기능 때문에 Lightsail의 내장 CDN만을 사용하는 것보다 선택되