1. 개요 (Introduction)왜 이 문제에 주목했는가?기업이 성장하면서 AWS 계정이 여러 개로 분리되는 것은 자연스러운 현상입니다. 보안, 비용 관리, 팀별 독립성을 위해 개발, 스테이징, 프로덕션 환경을 각각 다른 AWS 계정으로 분리하게 되었습니다. 하지만 이로 인해 새로운 문제가 발생했습니다.각 계정의 CloudWatch 메트릭과 로그를 확인하기 위해 계정을 일일이 전환해야 했고, 전체적인 시스템 상태를 파악하기 어려웠습니다. 특히 장애 상황에서 여러 계정을 오가며 원인을 찾는 것은 매우 비효율적이었습니다.프로젝트 개요 및 배경환경: 개발(Dev), 스테이징(Staging), 프로덕션(Prod) 3개의 AWS 계정문제점:계정별로 분산된 모니터링 데이터통합 대시보드 부재장애 대응 시 계정 전..

1. 왜 이 문제에 주목했는가? (Introduction)회사의 서비스가 성장하면서 AWS CloudWatch 로그 데이터가 급격히 증가하게 되었습니다. 처음에는 특별한 문제 없이 사용했으나 시간이 지나면서 로그 보관 비용이 점점 부담으로 다가왔습니다. 장기 보관이 필수적인 상황에서 CloudWatch Logs의 보관 비용은 예상보다 훨씬 비싸고 효율적이지 않았습니다. 이를 해결하기 위해 비용 효율적인 대안을 찾기 시작 그 결과 S3를 활용한 로그 보관 방식을 선택하게 되었습니다.2. 기술 스택 결정 과정기존에 사용하던 CloudWatch Logs는 관리가 쉽고 접근성이 우수했으나 데이터 양이 증가할수록 비용 부담이 급격히 늘어났습니다. 반면 S3는 저렴한 비용으로 장기 데이터 보관이 가능하고 Athen..