많은 팀이 로그 검색과 대시보드 조회를 위해 Amazon OpenSearch를 도입합니다. 그런데 대부분은 사용량보다 먼저 요금 고지서를 보고 문제를 인식하게 됩니다.
개발환경인데 수백 달러?
사용량은 줄었는데 비용은 늘어남?
OpenSearch 비용은 단순히 인스턴스 사용 시간만이 아닙니다. RI 만료, 스토리지 누적, 인덱스 증가, 신규 인스턴스 도입, 스냅샷 증가 등 복합적인 원인이 얽혀있습니다.
이 글에서는 AWS Cost Explorer를 활용하여 OpenSearch의 비용 구조를 정확히 이해해 보도록 하겠습니다.
Amazon OpenSearch 클러스터의 비용을 정확하게 파악하려면 AWS Cost Explorer를 활용해 세부 항목을 필터링하고 분석하는 과정이 필요합니다. OpenSearch는 인스턴스 유형, 스토리지, 데이터 처리량, 스냅샷 및 모니터링(Log 및 CloudWatch) 항목별로 요금이 과금되므로, 이를 구분해 파악해야 최적의 비용 절감 전략을 수립할 수 있습니다.
먼저 AWS Cost Explorer에 접속해 OpenSearch 관련 비용을 추적하는 기본 방법은 다음과 같습니다.
AWS Console 상단 검색창에 Cost Explorer를 입력하고 선택합니다. Cost Explorer 열기를 클릭해 비용 분석 도구에 진입합니다.
비용을 세부적으로 분석하려면 Group By 항목을 적절히 설정해야 합니다. OpenSearch 비용은 UsageType 필터를 통해 상세 항목별로 확인할 수 있으며, Resource ID로 필터링하면 각 OpenSearch 도메인별로 비용을 분리해 분석할 수 있습니다. Kibana 사용량, API 호출량, 데이터 처리 비용 등을 개별 도메인 기준으로 파악할 수 있으므로, 도메인별 비용 집중도를 파악하는 데 효과적입니다.
필터링 항목은 Service: Amazon OpenSearch 선택 후, UsageType에서 각 항목을 선택하거나 전체 선택 후 후처리 방식으로 파악합니다. OpenSearch의 UsageType 항목에는 주로 Instance-Hours, EBS-Bytes, Snapshot-Bytes, Data-Transfer-Bytes 등이 포함됩니다. 이를 통해 인스턴스 유형별 요금, 스토리지 요금, 데이터 처리 요금, 스냅샷 저장 비용을 구분해 분석할 수 있습니다.
기간은 상단의 기간 선택 메뉴에서 이번 달, 지난 6개월 등 원하는 기간을 선택해 분석합니다. 일별 분석은 급격한 비용 변화나 특정 이벤트 발생 시점을 파악하는 데 유용하며, 월별 분석은 장기적인 비용 추세와 패턴을 확인하는 데 적합합니다.
예를 들어, 특정 OpenSearch 도메인의 비용이 Data-Transfer-Bytes 또는 Snapshot-Bytes 항목에서 급격히 증가했다면, 대용량 데이터의 인덱싱, 대량 스냅샷 생성, 크로스 리전 복제 등의 이벤트가 발생했을 가능성을 추적해볼 수 있습니다.
이 항목은 Amazon OpenSearch Service의 m6g.large.search 인스턴스 타입을 사용한 시간에 따라 발생하는 비용을 나타냅니다. 시간에 따라 꾸준히 발생하는 서버 사용량에 대한 비용입니다.
HeavyUsage는 예약 인스턴스(RI) 사용에 따른 시간당 요금을 나타내는 UsageType입니다. m6g.large.search는 인스턴스 타입으로, Graviton 기반 m6g 인스턴스의 large 사이즈(2 vCPU, 8 GiB 메모리)를 의미하며, OpenSearch 검색 노드에 사용되는 유형입니다.
이 항목은 AWS OpenSearch Service에서 m6g.large 타입의 인스턴스를 온디맨드로 사용한 시간당 요금을 나타냅니다. 즉, APN2(서울 리전)에서 m6g.large.search 인스턴스를 OpenSearch 클러스터의 데이터 노드, 전용 마스터 노드, UltraWarm 노드 등에 배포해 사용한 경우 발생하는 시간당 비용입니다. 예약인스턴스를 구매했을 경우 HeavyUsage로, 온디맨드인 경우 ESInstance로 비용 항목이 계산됩니다.
이 항목은 AWS OpenSearch Service에서 GP3(EBS General Purpose SSD v3) 볼륨을 스토리지로 사용한 경우, 해당 스토리지 사용량(GB 단위)에 대한 시간당 또는 GB당 요금을 나타냅니다. 즉, OpenSearch 클러스터의 데이터 노드가 사용하는 EBS 볼륨 중 GP3 타입에 해당하는 스토리지에 부과되는 요금입니다.
OpenSearch는 GP3 외에도 GP2, Provisioned IOPS (io1/io2) 등 다른 EBS 타입도 지원하며, 선택한 스토리지 타입에 따라 청구 항목 이름(APN2-ES:GP2-Storage, APN2-ES:PIOPS-Storage)이 다르게 표시됩니다.
이 항목은 AWS 리전 내 데이터 전송(Regional Data Transfer) 에 대한 비용을 나타냅니다. AWS에서 “리전 내 데이터 전송”이란 같은 리전에 위치한 서비스 간 데이터 전송(예: OpenSearch → EC2, RDS → Lambda) 또는 VPC 간 데이터 전송을 의미하며, 인터넷이나 다른 리전으로 나가지 않는 트래픽을 다룹니다.
OpenSearch의 UsageType 별 비용 구조를 예시로 분석해보겠습니다.
4개월 간 총 $4,458.72의 OpenSearch 비용이 발생했으며, 주요 항목은 다음과 같습니다.
인스턴스 사용량(HeavyUsage & ESInstance)이 대부분을 차지
APN2-HeavyUsage:r6g.large.search와 APN2-ESInstance:r6g.large가 가장 큰 비중($1,720.25 + $1,633.54 = $3,353.79, 총 비용의 약 75.2%)을 차지합니다. 이는 OpenSearch 클러스터의 컴퓨팅 인스턴스 비용이 전체의 핵심임을 보여줍니다.
RI 만료: 2025년 4월에 APN2-HeavyUsage:r6g.large.search 비용이 급격히 감소($520.80 -> $208.25)한 반면, APN2-ESInstance:r6g.large 비용이 크게 증가($302.06 -> $721.87)했습니다. 이는 기존에 구매했던 r6g.large 인스턴스에 대한 RI(예약 인스턴스)가 4월에 만료되었고, 해당 사용량이 온디맨드로 전환되어 과금되기 시작했기 때문입니다.
m6g.large.search의 변화: APN2-HeavyUsage:m6g.large.search 역시 4월에 비용이 $80.35에서 $8.53으로 크게 감소했습니다. 동시에 APN2-ESInstance:m6g.large가 4월에 $100.00으로 갑자기 발생했습니다. 이는 이 인스턴스 타입에 대한 RI도 만료되었거나, 해당 인스턴스의 사용량이 크게 줄었음을 시사합니다.
m7g.large 사용: 2025년 3월 $20.42, 4월 $0.50으로 APN2-ESInstance:m7g.large 비용이 새로 발생했습니다. 이는 새로운 세대의 Graviton3 기반 m7g 인스턴스를 테스트하거나 도입하기 시작했음을 의미합니다. m7g는 m6g보다 뛰어난 가격 대비 성능을 제공하므로, 점진적으로 기존 m6g나 r6g 인스턴스를 m7g로 전환하는 것을 검토하여 장기적인 비용 효율을 극대화할 수 있습니다.
비용절감 포인트: RI 만료로 인해 온디맨드 사용량이 증가하면 비용이 급증할 수 있습니다. 즉시 해당 r6g.large 인스턴스에 대한 새로운 RI 또는 Savings Plans 구매를 고려해야 합니다. 특히 Compute Savings Plans는 더 유연하게 다양한 인스턴스 타입과 패밀리에 적용될 수 있으므로, 향후 워크로드 변경 가능성까지 고려하여 검토해야 합니다.
저장 공간의 점진적 증가
APN2-ES:GP3-Storage: 이 항목은 2025년 1월 $126.73에서 시작하여 2월부터 4월까지 $205.03으로 꾸준히 증가하고 유지되고 있습니다. 총 $741.83를 차지합니다. 스토리지 비용의 증가는 검색 데이터 사용량 증가로 인해 디스크 공간을 확장했기 때문입니다. 이는 서비스의 데이터 인덱싱이 활발하거나, 보관하는 데이터의 양이 늘어나고 있음을 나타냅니다.
비용 절감 포인트: 불필요한 인덱스나 오래된 데이터를 주기적으로 삭제(Index Lifecycle Management, ILM 활용)하여 스토리지 사용량을 최적화해야 합니다. 또한, Hot-Warm-Cold 아키텍처를 도입하여 자주 접근하지 않는 데이터를 UltraWarm 또는 Cold Storage(S3 기반)로 이동시켜 스토리지 비용을 획기적으로 절감할 수 있습니다.
데이터 전송 비용
APN2-DataTransfer-Regional-Bytes: 이 비용은 6개월간 총 $0.37로 매우 미미한 수준입니다. 이는 OpenSearch 클러스터 내부 또는 같은 리전 내 다른 AWS 서비스 간의 데이터 전송이 매우 효율적으로 이루어지고 있거나, 이 항목에서 발생하는 전송량이 적음을 의미합니다. 현재로서는 이 부분에 대한 비용 최적화의 필요성은 낮습니다.
이번에는 Resouce ID 별로 분류하여 비용을 분석해보겠습니다.
총 $4,458.72의 비용이 집계되었으며, 이는 첫 번째 이미지와 총계가 일치하여 2025년 1월부터 4월까지의 총 비용을 나타냄을 알 수 있습니다.
No Data 항목의 높은 비중: 가장 높은 비용을 차지하는 $1,962.06가 No Data 항목으로 표시되어 있습니다. No Data는 특정 리소스 ID에 명확하게 매핑되지 않는 비용을 의미할 수 있습니다. 이는 OpenSearch 서비스의 일부 과금 항목이 리소스 ID로 세분화되지 않거나, 태그 기반 비용 할당이 완벽하게 설정되지 않았을 때 발생할 수 있습니다.
search-prod 도메인의 높은 비용: arn:aws:es:ap-northeast-2:2997347119519:domain/search-prod 도메인이 총 $1,415.26로 개별 도메인 중 가장 높은 비용을 차지합니다. 특히 2025년 4월에 $653.75로 급증했습니다. 이 도메인은 프로덕션 환경의 검색 클러스터입니다. 4월의 급증은 Usage Type 분석에서 확인된 r6g.large 인스턴스의 RI 만료와 온디맨드 전환 비용이 이 도메인에서 발생했기 때문입니다.
athena-prod 도메인 비용: arn:aws:es:ap-northeast-2:2997347119519:domain/athena-prod 도메인은 총 $654.17를 차지하며, 월별로 $94.63에서 $195.44로 꾸준히 증가했습니다. athena-prod는 ELK를 사용하는 로그 저장소로 활용되고 있습니다. 비용의 지속적인 증가는 해당 도메인의 인스턴스 사용량 또는 스토리지 사용량이 꾸준히 늘어났음을 의미합니다.
개발/테스트(dev, stg) 도메인 비용: athena-dev ($214.27), search-dev ($176.64), athena-stg ($36.32) 등 개발 및 스테이징 도메인에서도 비용이 발생하고 있습니다. 특히 search-dev는 4월에 $114.43으로 급증했습니다. athena-stg는 1월에만 비용이 발생하고 이후 $0.00으로 나타납니다. 개발/테스트 환경에서도 비용이 발생하는 것은 당연하지만, 프로덕션 환경만큼의 리소스가 필요하지 않은 경우가 많습니다. athena-stg처럼 사용 후 비용이 $0.00이 되는 것은 리소스가 잘 정리되었음을 시사합니다.
“OpenSearch 비용은 줄일 수 있습니다. 단, 보이는 것부터 봐야 합니다.”
OpenSearch 비용은 대부분이 인스턴스 비용이며, 그중 다수는 예약 인스턴스(RI) 만료로 온디맨드로 전환되며 폭등했습니다.
OpenSearch 비용 최적화는 단순히 청구서를 줄이는 일이 아닙니다. 자신의 시스템 구조를 이해하고, 우선순위를 재정렬하며, 팀이 똑같은 방향을 보게 만드는 기회입니다. 지금 우리가 할 일은 거창한 구조 변경이 아닙니다.
RI 갱신, 인덱스 정책 정리, 태그 정비부터 시작해 보세요. 비용을 개발 상황에 맞게 통제할 수 있습니다.