AWS 로그 분석 선택: Logs Insights vs Athena vs OpenSearch
로그를 모으는 비용은 CloudWatch Logs 절감 편에서 다뤘습니다. 이 글은 그다음 질문, 모은 로그를 어디서 분석하는가입니다. 결론을 먼저 적으면, 가끔 조사할 때만 찾는 로그는 Logs Insights, S3에 장기 보관하며 SQL로 묻는 로그는 Athena, 상시 대시보드·전문 검색·알림이 필요한 로그만 OpenSearch입니다. 셋은 경쟁 관계가 아니라 조회 빈도에 따른 층이고, 전부 OpenSearch에 넣는 구성이 이 영역에서 가장 흔한 과지출입니다. 요금은 us-east-1 기준입니다.
한눈에 보는 비교 #
| 구분 | Logs Insights | Athena + S3 | OpenSearch |
|---|---|---|---|
| 데이터 위치 | CloudWatch Logs | S3 | 전용 클러스터·컬렉션 |
| 과금 | 스캔 GB당 약 $0.005 | 스캔 TB당 약 $5 | 인스턴스 시간 또는 OCU |
| 유휴 비용 | 0 (조회할 때만) | 0 (조회할 때만) | 상시 (도메인·OCU 바닥) |
| 쿼리 언어 | 전용 문법 (+OpenSearch PPL/SQL 지원) | 표준 SQL | 쿼리 DSL·대시보드 |
| 적합 빈도 | 가끔 (조사·디버깅) | 주기적 (리포트·감사) | 상시 (대시보드·알림) |
| 지연 | 초 단위 | 초〜분 단위 | 밀리초 (색인 완료 후) |
| 준비 작업 | 없음 | 파티셔닝·포맷 설계 | 색인 파이프라인·용량 설계 |
Logs Insights: 이미 있는 로그를 즉시 분석 #
애플리케이션 로그가 이미 CloudWatch에 들어오고 있다면, 조사·디버깅 용도의 첫 번째 답은 Logs Insights입니다. 별도 파이프라인 없이 로그 그룹을 골라 바로 쿼리하고, 요금은 스캔한 GB당 약 $0.005뿐입니다. 장애 조사처럼 하루 몇 번 수 GB를 훑는 사용이라면 월 요금이 몇 달러 선에서 끝납니다.
한계도 명확합니다. 요금이 스캔량에 비례하므로 시간 범위를 넓게 잡은 쿼리를 상시로 돌리는 순간 요금 구조가 무너집니다. 대시보드를 Insights 쿼리로 만들어 5분마다 전 로그를 스캔하는 구성이 전형적인 실수입니다. 상시 조회가 필요해졌다는 것은 이 층의 용도를 벗어났다는 신호이고, 그때가 OpenSearch를 검토할 시점입니다. 조회 습관(시간 범위 좁히기, 로그 그룹 특정)은 수집 절감 편에서 적은 그대로입니다.
Athena + S3: 장기 보관과 SQL의 조합 #
로그의 수명이 길어질수록 저장소는 S3가 맞고(수집 편의 결론), 그 S3 위에서 SQL을 돌리는 것이 Athena입니다. 스캔 TB당 약 $5의 순수 조회 과금이라 유휴 비용이 없고, ALB 액세스 로그·CloudTrail·VPC Flow Logs처럼 애초에 S3로 떨어지는 로그는 이 조합이 사실상 기본값입니다. 월간 리포트, 보안 감사, “지난 분기 특정 IP의 요청 전수” 같은 질문이 이 층의 일입니다.
요금을 가르는 것은 스캔량이고, 스캔량을 가르는 것은 저장 설계입니다. 날짜·서비스로 파티셔닝하고, JSON 원문 대신 Parquet 같은 컬럼 포맷으로 압축해 두면 스캔량이 자릿수로 줄어듭니다. 같은 질문이 파티션 없는 JSON에서 200GB를 스캔하고($1), 파티션된 Parquet에서 2GB를 스캔하는($0.01) 차이입니다. 반대로 말하면 Athena 요금이 아프기 시작했다면 쿼리가 아니라 저장 포맷을 먼저 고칩니다. 보관 계층 자체의 요금은 S3 스토리지 클래스 비교의 영역입니다.
OpenSearch: 상시성에 고정비를 내는 층 #
OpenSearch가 주는 것은 밀리초 검색, 실시간 대시보드, 전문(full-text) 검색, 로그 기반 알림입니다. 대가는 상시 켜져 있는 비용입니다. 관리형 도메인은 인스턴스 시간 과금이라 소형 프로덕션 구성도 월 수백 달러부터 시작하고, 서버리스(OCU 시간당 약 $0.24)도 컬렉션 유형에 따라 최소 OCU 바닥이 있어 월 수백 달러 수준의 하한이 생길 수 있습니다(최신 세대 컬렉션은 유휴 시 0까지 내려가는 구성도 등장했으므로 도입 시점에 확인). 어느 쪽이든 “조회할 때만 내는” 앞의 두 층과 달리 존재 자체에 돈이 나가는 층입니다.
그래서 판단 기준은 기능이 아니라 상시성입니다. 운영팀이 하루 종일 열어 두는 로그 대시보드, 수백 ms 안에 응답해야 하는 로그 검색 화면, 로그 패턴 기반 실시간 알림처럼 상시 조회가 실제 요건일 때만 이 고정비가 정당화됩니다. “있으면 좋을 것 같아서” 전 로그를 색인하는 구성은 수집 요금과 색인 비용을 이중으로 내는 결과가 됩니다.
조합: 셋은 층으로 쌓입니다 #
실무 구성은 하나를 고르는 것이 아니라 로그의 조회 빈도에 따라 나누는 것입니다. 전형은 이렇습니다. 애플리케이션 로그는 CloudWatch로 받아 조사용으로 Insights를 쓰고, 보존 기간이 지나면 S3로 내보내 Athena가 감사·리포트를 맡습니다. 그중 상시 대시보드가 필요한 서비스의 로그만 OpenSearch로 구독 전달합니다. 이렇게 나누면 OpenSearch 클러스터 크기가 전체 로그가 아니라 상시 조회 로그에만 비례하게 되어, 세 층 합계가 전량 색인 구성의 몇 분의 1로 내려가는 경우가 많습니다.
선택 순서 #
- 조회 빈도로 로그를 분류합니다: 가끔(조사), 주기적(리포트·감사), 상시(대시보드·알림)의 세 칸에 로그 종류를 배정합니다. 이 분류가 곧 아키텍처입니다.
- 가끔 칸은 Logs Insights로 끝냅니다: 파이프라인 없이 바로 쓰고, 시간 범위를 좁히는 습관만 지킵니다.
- 주기적 칸은 S3 + Athena로 보냅니다: 파티셔닝과 Parquet 변환까지가 도입이고, 이 설계가 스캔 요금을 자릿수로 결정합니다.
- 상시 칸만 OpenSearch를 검토합니다: 상시 조회 요건을 문장으로 적을 수 있을 때만 고정비를 승인하고, 색인 대상을 그 로그로 한정합니다.
- 경계 이동을 주기적으로 봅니다: Insights 요금이 커지면 상시화 신호이니 OpenSearch 편입을, OpenSearch 색인 중 대시보드에 안 쓰는 로그는 S3 강등을 검토합니다.
정리 #
- 셋은 경쟁이 아니라 조회 빈도의 층입니다. 가끔은 Insights, 주기적은 Athena, 상시만 OpenSearch입니다.
- Insights(스캔 GB당 약 $0.005)는 파이프라인 없는 첫 번째 답이지만, 상시 조회로 쓰면 요금 구조가 무너집니다.
- Athena(스캔 TB당 약 $5)의 요금은 저장 설계가 정합니다. 파티셔닝 + Parquet이 스캔량을 자릿수로 줄입니다.
- OpenSearch는 존재 자체에 돈이 나가는 층입니다. 상시 조회 요건이 문장으로 적힐 때만, 그 로그에 한정해 색인합니다.
- 전 로그 OpenSearch 색인이 이 영역 최대의 과지출 패턴입니다. 층을 나누면 합계가 몇 분의 1로 내려갑니다.