CloudWatch 로그 비용이 부담될 때, OpenSearch를 직접 구성하는 선택은 맞을까?

AWS 환경에서 로그를 수집하다 보면 처음에는 대부분 CloudWatch Logs를 사용합니다.
설정이 쉽고, AWS 서비스와 자연스럽게 연동되며, 알람이나 Logs Insights 같은 기능도 바로 사용할 수 있기 때문입니다.

하지만 로그량이 늘어나기 시작하면 이야기가 달라집니다.

특히 애플리케이션 로그, 컨테이너 로그, 웹 서버 access log, VPC Flow Log, WAF 로그처럼 대량으로 쌓이는 로그를 모두 CloudWatch Logs에 넣으면 비용 부담이 빠르게 커질 수 있습니다.

 

현업에서 “CloudWatch 로그 비용 때문에 OpenSearch를 따로 쓴다”는 이야기가 나오는 이유도 바로 이 지점입니다.

 

CloudWatch에서 비싸게 느껴지는 부분

많은 사람이 CloudWatch 비용을 “보관 비용”으로만 생각합니다.

하지만 실제로 부담이 커지는 부분은 보통 로그를 처음 CloudWatch Logs에 넣는 수집 비용입니다.

즉, 로그가 CloudWatch Logs로 들어오는 순간 GB 단위 과금이 발생합니다.

이후 해당 로그를 다시 Lambda, Firehose, OpenSearch, S3 등으로 전달하면 downstream 비용도 추가될 수 있습니다.

 

구조로 보면 다음과 같습니다.

애플리케이션 로그
  → CloudWatch Logs
  → Subscription Filter / Lambda / Firehose
  → OpenSearch 또는 S3

 

이 구조에서는 CloudWatch Logs 수집 비용을 이미 한 번 지불한 뒤, 다시 다른 서비스 비용을 부담하게 됩니다.

그래서 비용 최적화 관점에서는 CloudWatch를 무조건 거치는 방식이 항상 좋은 선택은 아닙니다.

 

그래서 OpenSearch로 직접 보내는 구조가 등장한다

대량 로그 환경에서는 다음과 같은 구조를 많이 고려합니다.

EC2 / ECS / EKS / 온프레미스
  → Fluent Bit / Vector / Logstash
  → OpenSearch

 

또는 장기 보관까지 고려하면 다음처럼 나눌 수 있습니다.

최근 검색용 로그
  → OpenSearch

장기 보관용 로그
  → S3

 

이렇게 하면 모든 로그를 CloudWatch Logs에 넣지 않아도 됩니다.

CloudWatch는 꼭 필요한 운영 지표, 알람, 일부 핵심 로그 중심으로 사용하고, 대량 검색용 로그는 OpenSearch나 S3 중심으로 분리하는 방식입니다.

 

그런데 Amazon OpenSearch Service도 비싸다

문제는 Amazon OpenSearch Service도 저렴한 서비스는 아니라는 점입니다.

OpenSearch는 기본적으로 상시 실행되는 클러스터 구조입니다.
데이터 노드, 마스터 노드, 스토리지, 스냅샷, 멀티 AZ 구성을 고려하면 고정 비용이 꽤 큽니다.

 

로그량이 많지 않은데 관리형 OpenSearch Service를 운영하면 오히려 CloudWatch보다 더 비싸게 느껴질 수 있습니다.

그래서 일부 조직에서는 Amazon OpenSearch Service 대신 EC2에 직접 OpenSearch를 설치해서 운영하기도 합니다.

 

EC2에 직접 OpenSearch를 구성하면 정말 저렴할까?

단순 인프라 비용만 보면 EC2 자가 구성 방식이 더 저렴해 보일 수 있습니다.

예를 들어 관리형 서비스 비용 대신 EC2 인스턴스와 EBS 비용만 부담하면 되기 때문입니다.

하지만 여기에는 숨은 비용이 있습니다.

자가 구성 방식에서는 다음을 직접 관리해야 합니다.

- OpenSearch 버전 관리
- 보안 패치
- JVM 튜닝
- 샤드 설계
- 인덱스 rollover
- 디스크 워터마크 관리
- 장애 복구
- 스냅샷 백업
- TLS / 인증 / 권한 설정
- 노드 증설 및 축소
- 멀티 AZ 구성

 

운영 인력이 충분하고 로그 플랫폼 운영 경험이 있다면 EC2 자가 구성은 비용 절감 효과가 있을 수 있습니다.
하지만 운영 부담까지 고려하면 단순히 “EC2가 싸다”라고 결론 내리기는 어렵습니다.

 

현실적인 로그 아키텍처

실무에서는 보통 하나의 서비스로 모든 로그를 처리하기보다 목적에 따라 나눕니다.

CloudWatch
  → 알람, 주요 운영 로그, AWS 네이티브 모니터링

OpenSearch
  → 최근 로그 검색, 장애 분석, 대시보드

S3
  → 장기 보관, 감사 대응, 저비용 아카이빙

 

이 구조가 비용과 운영 편의성의 균형을 맞추기 좋습니다. 예를 들어 최근 30일 또는 90일 로그는 OpenSearch에 저장해 빠르게 검색하고, 그 이후 로그는 S3로 넘겨 장기 보관하는 방식입니다.

CloudWatch에는 모든 로그를 다 넣기보다 알람과 운영에 필요한 핵심 로그만 남기는 식으로 최적화할 수 있습니다.

 

어떤 선택이 맞을까?

로그량이 적고 AWS 네이티브 운영 편의성이 중요하다면 CloudWatch Logs가 가장 단순합니다.
운영 부담도 적고, 알람이나 대시보드 연동도 쉽습니다.

 

하지만 로그량이 TB 단위로 커지면 CloudWatch Logs에 모든 로그를 넣는 구조는 비용 부담이 커질 수 있습니다.
이때는 OpenSearch나 S3를 함께 사용하는 구조를 검토하는 것이 좋습니다.

 

다만 OpenSearch도 공짜는 아닙니다.
관리형 OpenSearch Service는 운영 편의성이 좋은 대신 비용이 높고, EC2 자가 구성은 인프라 비용은 낮출 수 있지만 운영 책임이 커집니다.

 

결론

“CloudWatch가 비싸서 OpenSearch를 쓴다”는 말은 어느 정도 사실입니다.
다만 정확히는 “대량 로그를 모두 CloudWatch Logs에 넣는 구조가 비싸질 수 있으므로, 검색용 로그와 장기 보관 로그를 분리한다”가 더 맞는 표현입니다.

 

또한 “OpenSearch Service가 비싸서 EC2에 직접 OpenSearch를 구성한다”는 이야기도 현실에서 나올 수 있습니다.
하지만 이 선택은 운영 인력과 장애 대응 역량이 있을 때 가능한 방식입니다.

가장 현실적인 결론은 다음과 같습니다.

CloudWatch는 운영 알람과 핵심 로그 중심으로 사용하고,
OpenSearch는 최근 로그 검색과 분석용으로 사용하며,
S3는 장기 보관과 감사 대응용으로 분리하는 것이 좋다.

 

로그 플랫폼은 단순히 수집만 잘하면 되는 영역이 아닙니다.
비용, 검색 성능, 보관 기간, 장애 대응, 보안, 운영 인력까지 함께 고려해야 합니다.

 

따라서 처음에는 CloudWatch 중심으로 단순하게 시작하되, 로그량이 커지는 시점부터는 CloudWatch, OpenSearch, S3를 목적별로 분리하는 전략이 필요합니다.