OpenSearch 비용 구조 완전 이해하기
“매달 수십에서 수백만 원씩 나가는 OpenSearch 비용, 정말 줄일 수 없을까요?”
많은 팀이 로그 분석과 검색에 OpenSearch를 사용하면서도, 정확한 요금 구조를 모르거나 잘못된 구성으로 인해 불필요한 비용을 지출하고 있습니다.
특히 하루 몇 번만 대시보드를 보는 환경에서 24시간 돌아가는 클러스터, 오래된 데이터가 많은데도 전부 EBS에 저장, 사용량에 비해 과도한 노드 구성은 대표적인 낭비 패턴입니다.
이 글에서는 OpenSearch의 비용이 어떤 식으로 과금되는지 먼저 알아보기로 하겠습니다.
OpenSearch란 무엇인가?
OpenSearch는 검색과 로그 분석에 최적화된 오픈소스 기반의 분산형 검색 엔진입니다. AWS에서는 Elasticsearch의 오픈소스 분리 버전인 OpenSearch를 관리형 서비스(Amazon OpenSearch Service) 형태로 제공합니다.
즉, OpenSearch는 기본적으로 Elasticsearch와 비슷한 역할을 합니다. 대량의 데이터를 검색하고, 집계하고, 분석하는 데 주로 사용됩니다.
Elasticsearch와의 관계
원래 Elasticsearch는 Elastic사가 개발한 오픈소스 검색 엔진이었습니다. AWS에서도 과거에는 Elasticsearch를 기반으로 한 Amazon Elasticsearch Service를 제공했습니다. 하지만 Elastic사가 2021년에 라이선스를 변경하며 오픈소스 라이선스가 아닌, 제한적인 라이선스로 전환했습니다.
이에 따라 AWS는 Elasticsearch 오픈소스 버전을 기반으로 독립적인 프로젝트인 OpenSearch를 만들었고, 기존 Amazon Elasticsearch Service도 2021년 9월부터 Amazon OpenSearch Service로 이름을 변경해 지원하기 시작했습니다.
OpenSearch 주요 기능 및 활용 사례
OpenSearch는 AWS에서 제공하는 오픈소스 기반의 검색 및 로그 분석 서비스로, 대규모 데이터 검색과 실시간 분석을 효율적으로 처리할 수 있는 기능을 제공합니다. 이를 통해 다양한 데이터 소스에서 들어오는 정보를 저장, 검색, 집계하고 시각화할 수 있어, 빠르고 직관적인 데이터 탐색 환경을 구축할 수 있습니다. OpenSearch는 특히 다음과 같은 기능과 활용 사례에서 큰 강점을 발휘합니다.
먼저, 로그 분석에서는 서버나 애플리케이션에서 발생하는 로그 데이터를 수집하고, 이를 빠르게 검색하거나 패턴을 분석해 문제를 식별할 수 있습니다. 예를 들어, 웹 서버의 에러 로그를 OpenSearch에 저장해두면, 특정 오류 코드가 언제, 얼마나 발생했는지를 쉽게 조회할 수 있습니다. 또한, 필터링과 집계를 통해 장애 패턴을 찾아내고, 알림 시스템과 연동해 실시간 경고를 받을 수도 있습니다.
둘째, 검색 엔진 역할로도 많이 사용됩니다. 전자상거래 사이트에서는 상품 검색, 뉴스 포털에서는 기사 검색, 내부 시스템에서는 문서 검색에 OpenSearch를 적용해 사용자가 원하는 데이터를 빠르게 찾을 수 있는 환경을 제공합니다. OpenSearch는 대량의 데이터에서 빠른 검색 속도를 보장하며, 검색 결과를 정확하고 직관적으로 제공하기 위해 다양한 정렬, 필터링, 랭킹 기능을 지원합니다.
셋째, 모니터링 및 시각화 도구로서의 역할도 큽니다. OpenSearch는 OpenSearch Dashboards(구 Kibana)라는 시각화 도구를 제공해, 검색 쿼리 결과를 그래프, 차트, 테이블로 표현할 수 있습니다. 이를 통해 CPU 사용량, 메모리 사용률, 요청 처리 속도 같은 시스템 지표를 실시간 대시보드로 구성할 수 있으며, 네트워크 트래픽, API 응답 시간, 사용자 접속 패턴 등의 모니터링 지표도 손쉽게 시각화할 수 있습니다.
결국 OpenSearch는 단순한 데이터 저장소를 넘어, 로그 분석, 검색, 모니터링까지 한 번에 처리할 수 있는 통합 데이터 플랫폼 역할을 수행하며, 운영 효율성을 높이고 문제 해결 시간을 단축하는 데 큰 기여를 합니다.
OpenSearch 주요 요금 체계 구성
OpenSearch는 프로비저닝된 도메인을 사용하거나 Serverless로 사용할 수 있습니다. 프로비저닝 서비스를 이용할 경우 인스턴스 유형에 따른 비용이 과금되며 Serverless로 사용할 경우 인덱싱과 검색, 그리고 스토리지에 컴퓨팅 및 사용량에 따라 부과되는 OCU 개념이 비용으로 적용됩니다.
주요 요금의 상세한 내용은 아래 링크에서 확인할 수 있습니다.
https://aws.amazon.com/ko/opensearch-service/pricing/
인스턴스 유형 및 크기별 요금
OpenSearch의 요금은 크게 인스턴스 사용 시간, 스토리지, 데이터 처리량에 따라 부과되며, 인스턴스 유형과 크기에 따라 시간당 요금이 다르게 책정됩니다. OpenSearch는 EC2 인스턴스 기반으로 동작하기 때문에, 선택한 인스턴스의 vCPU 수, 메모리 용량, 그리고 성능 특성(일반, 메모리 최적화, 컴퓨팅 최적화 등)에 따라 비용이 달라집니다.
주요 인스턴스 유형과 크기별 요금 특징
보통 CPU와 메모리를 기준으로 인스턴스를 선택할 수 있으며 3가지 인스턴스 중 목적에 따라 선택하게 됩니다.
범용 인스턴스 (m 시리즈) 예: m6g.large.search (2 vCPU, 8 GiB 메모리), m6g.xlarge.search (4 vCPU, 16 GiB 메모리) 로그 분석, 검색, 모니터링 등 일반적인 사용 사례에 적합 CPU, 메모리 성능의 균형을 고려해 다양한 워크로드에 유연하게 대응
메모리 최적화 인스턴스 (r 시리즈) 예: r6g.large.search (2 vCPU, 16 GiB 메모리), r6g.xlarge.search (4 vCPU, 32 GiB 메모리) 대규모 로그 분석, 데이터 집계, 검색 결과 캐시 처리에 적합 높은 메모리 용량을 요구하는 워크로드에서 유리
컴퓨팅 최적화 인스턴스 (c 시리즈) 예: c6g.large.search (2 vCPU, 4 GiB 메모리), c6g.xlarge.search (4 vCPU, 8 GiB 메모리) 검색 처리 속도에 민감한 API 응답, 대량 검색 처리에 최적화 CPU 처리량이 중요한 워크로드에 적합
요금 계산 방식
인스턴스 요금은 시간 단위로 계산되며, 선택한 인스턴스 유형과 크기에 따라 달라집니다. 예를 들어 m6g.large.search는 시간당 약 $0.112, r6g.xlarge.search는 시간당 약 $0.228 정도의 요금이 부과됩니다 (서울 리전 기준, 2024년 6월 기준). 클러스터를 구성할 때 선택한 인스턴스 개수와 가동 시간에 따라 총 요금이 달라지므로, 클러스터 규모와 사용 패턴에 맞게 인스턴스 크기와 개수를 최적화하는 것이 중요합니다.
Compact 실무 팁
OpenSearch는 검색 쿼리 처리 시 CPU를, 집계나 대량 데이터 처리 시 메모리를 더 많이 사용합니다. 실제 워크로드에 필요한 최소 사양을 산출하고, 이를 기준으로 인스턴스를 선택해야 합니다.
OpenSearch 클러스터는 최소 3개 이상의 노드를 요구하지만, 1개로도 운영할 수 있습니다. 특히 개발 환경에서 데이터 볼륨/트래픽 대비 과도한 노드 개수를 설정하면 비용이 급증합니다.
Graviton(m6g, r6g, c6g)은 동일 스펙의 Intel(m5, r5, c5) 대비 시간당 요금이 20% 저렴합니다. 단 ARM 아키텍처에 대한 애플리케이션 호환성 검토가 필요하며, 특정 플러그인이나 모듈의 ARM 지원 여부는 반드시 확인해야 합니다.
OpenSearch는 장기 클러스터 운영 시, Reserved Instance(HeavyUsage 항목)으로 정액 비용 할인을 받을 수 있습니다. 1년 이상 고정 운영 시 반드시 구매하는게 좋습니다.
OpenSearch Serverless
OpenSearch Serverless는 클러스터나 노드를 직접 구성하거나 관리할 필요 없이, AWS가 자동으로 리소스를 프로비저닝하고 확장하여 사용자의 워크로드에 맞게 서비스를 제공하는 형태입니다. 이를 통해 사용자는 인프라 관리의 복잡성을 줄이고, 데이터 수집 및 검색에 집중할 수 있습니다.
OpenSearch 프로비저닝과 서버리스의 비교기존 OpenSearch는 클러스터 크기(노드 수, EBS 용량)를 사전에 예측하고 설정해야 합니다. 하지만 일부 워크로드는 사용량이 고르지 않고, 하루 중 특정 시간대만 사용되거나, 월 몇 번만 트래픽이 발생하는 경우가 많습니다.
예를 들어 개발/테스트 환경의 로그 분석이나 간헐적으로 사용하는 대시보드, 또는 하루 한두 번만 대량 검색하는 배치 작업인 경우입니다. 이런 상황에서는 고정된 클러스터를 유지하면 불필요한 비용이 발생할 수 있습니다. Serverless는 실제 사용한 만큼만 요금이 발생하므로, 이런 간헐적 사용에 매우 적합합니다.
반면 Serverless는 대량의 데이터(수백 GBTB 단위) 또는 초당 수천수만 건의 대규모 검색 트래픽에 적합하지 않습니다. Serverless는 백그라운드에서 리소스를 자동 확장하긴 하지만, 예측 가능한 고성능 보장이 어렵고, 사용량이 많아질수록 요금이 빠르게 증가할 수 있습니다. 이 경우 Managed OpenSearch 클러스터를 선택해, 원하는 인스턴스 크기와 수량으로 성능을 고정하는 것이 더 유리합니다.
OpenSearch Serverless의 비용은 주로 다음 세 가지 요소로 구성됩니다.
OCU (OpenSearch Compute Unit) 사용량
데이터 수집 및 검색 작업에 사용된 OCU 시간에 따라 과금됩니다. 최소 배포는 일반적으로 인덱싱 및 검색 각각에 대해 0.5 OCU씩, 총 1 OCU로 시작합니다. 운영 환경에서는 고가용성을 위해 인덱싱 및 검색 각각에 대해 1 OCU씩, 총 2 OCU로 구성하는 것이 일반적입니다.
스토리지 비용
데이터는 Amazon S3에 저장되며, 저장된 데이터의 용량에 따라 월별로 과금됩니다. 예를 들어, 서버리스 스토리지 비용은 월 $30부터 시작합니다.
Direct Query 비용
S3, CloudWatch Logs, Security Lake와 같은 외부 데이터 소스에 직접 쿼리하는 경우, 추가적인 OCU 사용량에 따라 비용이 발생합니다.
Amazon EBS 볼륨 요금
OpenSearch는 분산 검색 및 로그 분석을 위한 시스템이며, 데이터를 안전하게 저장하고 처리하기 위해 노드(서버) 간에 데이터를 분산 저장합니다. 이때 각 노드의 디스크 공간은 EBS 볼륨을 통해 제공됩니다. 즉, OpenSearch 클러스터의 데이터 노드(Data Node)는 EC2 인스턴스 + EBS 볼륨으로 구성됩니다. EBS는 OpenSearch의 데이터 저장소이며, 인덱스 데이터, 세그먼트, 로그 파일 등을 보관합니다.
OpenSearch의 볼륨 타입별 비교대부분의 OpenSearch 클러스터는 gp3로 충분하며, 고성능 대규모 클러스터의 경우에만 io2 고려할 수 있습니다.
OpenSearch 기타 서비스별 요금 구조
Amazon OpenSearch Ingestion
Amazon OpenSearch Ingestion은 AWS에서 제공하는 완전관리형 서버리스 데이터 수집 서비스로, 실시간 로그, 메트릭, 추적 데이터를 OpenSearch에 스트리밍할 수 있도록 지원합니다. 이 서비스는 Data Prepper를 기반으로 하며, 데이터의 필터링, 변환, 정규화, 집계 등의 처리를 수행할 수 있습니다. 기존에 많이 사용하는 Logstash나 Fluent Bit 등을 대체할 수 있습니다.
Amazon OpenSearch Ingestion은 다음과 같은 특징이 있습니다.
서버리스 아키텍처: 인프라 관리 없이 자동으로 확장 및 축소됩니다.
다양한 데이터 소스 지원: Amazon Kinesis Data Firehose, Amazon MSK, Amazon S3, Fluent Bit 등 다양한 소스와의 통합이 가능합니다.
데이터 처리 기능: 필터링, 변환, 정규화, 집계 등의 데이터 전처리 기능을 제공합니다.
보안 및 컴플라이언스: 데이터 마스킹, 필터링 등을 통해 민감한 정보를 보호하고 규정 준수를 지원합니다.
비용 효율성: 사용량 기반 과금으로, 필요에 따라 리소스를 조정하여 비용을 최적화할 수 있습니다
즉 서버리스로 관리 리소스를 최소화할 수 있고 필요한 만큼만 비용을 지불하게 되는 구조로 사용할 수 있습니다. 이 서비스는 사용한 리소스에 따라 과금되며, 주요 요금 구조는 다음과 같습니다.
OpenSearch Compute Units (OCUs)
OpenSearch Ingestion은 OCU(OpenSearch Compute Unit) 단위로 컴퓨팅 리소스를 측정합니다. 1 OCU는 약 15 GiB의 메모리와 2 vCPU로 구성됩니다. OCU는 시간당 $0.24의 요금이 부과되며, 분 단위로 청구됩니다.
파이프라인 용량 설정
사용자는 각 파이프라인에 대해 최소 및 최대 OCU 수를 설정할 수 있습니다. OpenSearch Ingestion은 이 범위 내에서 자동으로 확장하거나 축소하여 워크로드를 처리합니다. 워크로드가 적을 때는 최소 OCU 수로 유지하여 비용을 절감하고, 워크로드가 증가하면 자동으로 확장하여 성능을 유지할 수 있습니다.
파이프라인 일시 중지
파이프라인을 일시 중지(Stop) 하면, 해당 기간 동안 OCU 요금이 발생하지 않습니다. 개발, 테스트 환경이나 비업무 시간대에 파이프라인을 일시 중지하여 비용을 절감할 수 있습니다.
다음은 OpenSearch Ingestion을 사용할 때의 월간 비용 예시입니다.
Amazon OpenSearch Service Direct Query
Amazon OpenSearch Service의 Direct Query 기능은 Amazon S3, CloudWatch Logs, Security Lake와 같은 외부 데이터 소스에 저장된 데이터를 OpenSearch로 가져오지 않고도 직접 분석할 수 있는 제로 ETL(Extract, Transform, Load) 방식의 통합 기능입니다. 이를 통해 복잡한 데이터 수집 파이프라인을 구축하지 않고도 실시간 분석이 가능하며, 비용과 운영 부담을 줄일 수 있습니다.
OpenSearch Dashboards의 Query Workbench를 통해 OpenSearch SQL 또는 PPL을 사용하여 외부 데이터 소스를 직접 쿼리할 수 있습니다. 예를 들면 S3 또는 CloudWatch의 로그를 직접 쿼리를 사용하여 분석할 수 있습니다. Materialized Views를 활용하면 자주 사용하는 쿼리 결과를 인덱싱하여 대시보드나 알림에 활용할 수 있습니다.
Direct Query를 활용하면 데이터를 OpenSearch로 이동시키는 전통적인 ETL 과정을 생략할 수 있습니다. 이는 예를 들어 동일한 데이터를 S3와 OpenSearch에 중복 저장할 필요가 없음을 의미합니다. Athena 같은 도구를 쓰지 않아도 OpenSearch 내에서 직접 분석이 가능합니다.
데이터 이동 없이 직접 분석이 가능하므로 운영 복잡성이 감소합니다. 반면 인덱싱된 데이터에 비해 쿼리 성능이 낮을 수 있고 일부 고급 쿼리 기능은 지원되지 않습니다.
비용 구조
OpenSearch Compute Units (OCUs): Direct Query는 사용한 컴퓨팅 리소스에 따라 시간당 OCU 단위로 과금됩니다.
세션 유지 비용: Amazon S3의 경우, 쿼리 실행 시 최소 3분 동안 세션이 유지되며, 이 기간 동안 OCU 비용이 발생합니다.
인덱싱된 뷰 비용: 인덱싱된 뷰를 생성하는 경우, 추가적인 인덱싱 및 저장 비용이 발생할 수 있습니다.
추가 서비스 비용: AWS Glue Data Catalog, Amazon S3, CloudWatch Logs 등의 서비스 사용에 따른 추가 비용이 발생할 수 있습니다.
UltraWarm 및 콜드 스토리지
UltraWarm과 콜드 스토리지(Cold Storage)는 OpenSearch의 데이터 저장 계층 중 하나로, 고비용의 EBS 스토리지 대신 장기 저장용 저비용 스토리지를 제공하기 위한 옵션입니다.
EBS (Hot)
빠른 검색/집계 성능을 제공. 고가의 SSD 기반 스토리지.
UltraWarm
검색 가능한 상태로 오래된 데이터를 저장. 비용 절감 목적.
콜드 스토리지
가장 저렴한 저장 계층. 쿼리 시 데이터 로드를 트리거해야 함.
즉, UltraWarm과 콜드 스토리지는 “데이터를 오래 보관하지만 자주 조회하지 않는” 워크로드에 적합합니다. 예를 들어, 3개월 이상 지난 로그 데이터를 보관해야 하지만 검색 빈도는 낮은 경우 UltraWarm/콜드 스토리지를 고려해야 합니다.
EBS 볼륨 대비 UltraWarm/콜드 스토리지의 장단점즉, UltraWarm은 EBS보다 저렴하지만 성능은 조금 느린 검색이 필요한 데이터에, 콜드 스토리지는 거의 검색하지 않지만 보관해야 하는 데이터에 적합합니다.
UltraWarm 비용 구조요금 계산 예시
1TB의 로그 데이터를 UltraWarm에 저장: 1024GB × $0.024 = 약 $24.57/월
UltraWarm 노드 2대 운영: 2 × $0.136 × 24시간 × 30일 = 약 $195.84/월
즉, 스토리지 비용은 저렴하지만, UltraWarm 노드 운영 비용이 추가 발생합니다. 따라서 데이터양이 클수록, 예를 들어 3TB 이상부터 EBS보다 저렴해질 수 있습니다.
UltraWarm 노드 비용 예시
콜드스토리지 비용 구조요금 계산 예시
1TB 데이터를 콜드 스토리지에 저장: 1024GB × $0.012 = 약 $12.29/월
100GB의 데이터를 쿼리 검색(로드)할 경우: 100GB × $0.10 = $10.00/쿼리당
즉, 콜드 스토리지는 저장 비용은 가장 저렴하지만, 검색할 때마다 별도의 비용이 발생하는 구조입니다. 따라서 “정말 가끔 검색하는 데이터”에만 사용하는 것이 적합합니다.
스냅샷 스토리지
스냅샷 스토리지는 OpenSearch 클러스터의 백업 저장 공간을 의미합니다. 즉, 클러스터 내 인덱스와 데이터를 주기적으로 백업해 두는 기능이며, 보통 Amazon S3에 저장됩니다. 스냅샷은 클러스터의 장애 발생 시 데이터를 복원하거나, 특정 시점으로 롤백할 때 사용됩니다.
스냅샷은 장애 발생 시 데이터를 복구할 수 있는 유일한 안전장치입니다. 특히 중요한 운영 데이터(로그, 모니터링 지표, 검색 인덱스 등)를 다룰 때는 스냅샷 없이 운영하는 것은 리스크가 큽니다. 운영 환경에서는 반드시 사용하는 것이 좋습니다.
요금 구조
OpenSearch의 스냅샷은 저장소(S3) 비용과 직접적으로 연결됩니다. 즉, OpenSearch 자체 요금에는 포함되지 않고, S3 사용 요금만 별도로 청구됩니다.
S3 스토리지 요금: 저장 용량에 따라 요금 발생 (서울 리전 기준 약 $0.025/GB/월)
S3 요청 요금: PUT/GET/LIST 요청당 요금 발생 (1,000건당 약 $0.005 ~ $0.0004)
예를 들어
스냅샷 데이터 100GB → 약 $2.50/월 (S3 Standard 스토리지 기준)
스냅샷 백업 시 10,000개의 인덱스 파일 저장 → PUT 요청 10,000건 → 약 $0.05 추가
의 비용이 발생하게 됩니다.
결론
OpenSearch 비용은 단순히 인스턴스 가격의 합이 아니라, “어떤 데이터가 언제, 얼마나 자주, 어떤 방식으로 검색되는가”에 따라 달라집니다. 자주 조회하지 않는 데이터는 UltraWarm 또는 콜드 스토리지로 옮기고, 간헐적인 트래픽에는 Serverless로 전환하며, Graviton 인스턴스, Reserved Instance, EBS 최적화를 통해 구조 자체를 Lean하게 바꾸는 것이 핵심입니다.
운영 환경에 딱 맞는 구성으로 전환해, “계속 써야 하니까 어쩔 수 없다”는 말 대신, “써도 비용 걱정 없는 구조”를 만드는 것이 필요합니다. 그리고 어떤 식으로 비용이 나가는지를 정확히 이해하는 것이 그 출발점입니다.
