Elasticsearch 입문 35편 — AWS OpenSearch Service (Domain·Serverless·Provisioned·ES와 차이)

이 글은 Elasticsearch 입문에서 운영까지 시리즈 38편 중 35편이에요. 1편에서 OpenSearch 가 2021년 ES 7.10.2 fork 로 시작됐다 는 배경을 한 줄로 짚고 넘어갔는데, 35편은 그 한 줄을 운영 깊이 로 풀어요. AWS 환경에서 검색·로그 클러스터를 새로 짠다 면 사실상 첫 번째 후보가 AWS OpenSearch Service 예요.

왜 35편이 OpenSearch인가

시리즈 9부 클라우드 (3) 의 첫 글이에요. 26편(Cluster Operations) 부터 34편(Observability) 까지 자체 운영 깊이 를 다 풀었으니, 이제 남의 손에 운영을 맡겼을 때 어떤 그림이 되는가 — 35편 AWS OpenSearch, 36편 Elastic Cloud, 37편 IaC 로 묶이는 자리예요.

한국 회사 신규 프로젝트에서 검색·로그 인프라를 새로 짤 때 거의 첫 번째로 검토되는 게 AWS OpenSearch Service 예요. 사내 인프라가 이미 AWS 위에 올라가 있으면 VPC 안에 1급 시민으로 들어오는 매니지드 검색 엔진이라 결정이 빨라요.

이번 글에서 묶어 가는 질문은 네 가지예요. OpenSearch 가 정확히 무엇인가, ES 와 무엇이 같고 무엇이 다른가, Domain 의 Provisioned 와 Serverless 둘 중 어느 쪽을 골라야 하는가, 비용·보안·운영은 어디서 사고가 잦은가.

OpenSearch의 정체

OpenSearch = AWS 가 주도하는 Apache 2.0 라이선스의 분산 검색·분석 엔진. 2021년 1월 AWS 가 Elasticsearch 7.10.2 와 Kibana 7.10.2 를 fork 해서 만든 독립 프로젝트예요. fork 이유는 Elastic 사가 라이선스를 Apache 2.0 → SSPL + Elastic License 로 바꾼 사건 이었어요. SSPL 은 Server Side Public License 의 약자고, 오픈소스 정의에 부합하지 않는 (OSI 가 인정하지 않는) 라이선스라 AWS 가 자체 매니지드 SaaS 로 재판매 하기 어려워졌어요.

AWS 는 Apache 2.0 호환 오픈소스 검색 엔진을 잃을 수 없다 는 입장에서 fork 를 결정했어요. 그 결과 OpenSearch 는 AWS 가 코어 컨트리뷰터지만 거버넌스는 독립 — 2024년 9월 OpenSearch Software Foundation 이 Linux Foundation 산하로 출범하면서 AWS · SAP · Uber · Aiven · Aryn 같은 멤버 회사들이 함께 운영하는 vendor-neutral 프로젝트로 바뀌었어요. CNCF (Cloud Native Computing Foundation) 산하 편입은 아직 검토 단계.

작성 시점(2026-05-19) 기준 안정 메이저 버전은 OpenSearch 2.x 이고, Elasticsearch 7.10.2 의 후손이지만 8.x 의 일부 신기능 (벡터 검색 kNN·Searchable Snapshot 유사 기능) 을 독자 구현 으로 따라잡은 상태예요. 두 진영의 기능 격차가 매년 좁혀지는 중 이라고 보면 됩니다.

OpenSearch vs Elasticsearch 차이

매번 두 진영이 똑같지 않냐 는 질문이 나오는데, 2026년 시점에서는 다른 점이 더 많아졌다 가 정확한 표현이에요.

라이선스가 핵심이에요. AWS 에서 매니지드로 재판매할 수 있느냐 가 두 진영을 가르는 본질적 이유고, 기능 차이 는 그 결과에 따라 Elastic 사가 Enterprise 로 잠근 기능을 OpenSearch 가 무료로 풀어 둔 모양으로 정리돼요.

보안·alerting·기계학습 같은 자리에서 OpenSearch 가 Apache 2.0 무료 로 가는 게 한국 회사 입장에서 큰 매력이에요. Elastic 사의 Enterprise 라이선스 는 비용도 있고 재배포·SaaS 재판매 제약 도 있어요.

AWS OpenSearch Service의 정체

AWS OpenSearch Service = AWS 가 OpenSearch (와 일부 호환 Elasticsearch 버전) 을 매니지드 형태로 제공하는 서비스. 과거 Amazon Elasticsearch Service 였던 서비스가 2021년에 OpenSearch Service 로 이름이 바뀌었어요. 같은 콘솔·같은 API 안에서 legacy Elasticsearch 7.10 이하 와 OpenSearch 1.x · 2.x 를 둘 다 띄울 수 있는 구조예요.

핵심 운영 단위는 Domain 이에요. 클러스터 한 덩어리 = Domain 한 개 라고 보면 됩니다. Domain 한 개를 만들 때 결정해야 하는 게 데이터 노드 인스턴스 타입·갯수·마스터 노드 구성·Multi-AZ 여부·VPC 격리·암호화·접근 정책 같은 자리예요.

Domain 은 Provisioned 와 Serverless 두 가지 모드를 골라요. Provisioned 는 인스턴스 단위 클러스터를 직접 사이즈 하는 전통적 매니지드 형태고, Serverless 는 OCU (OpenSearch Compute Unit) 라는 추상 단위로 자동 스케일 하는 신규 모드예요. 둘은 완전히 다른 가격 모델과 다른 운영 모델 이라 선택 자체가 결정적.

Provisioned vs Serverless 선택

Provisioned 모드

인스턴스 단위로 클러스터를 직접 사이즈 하는 전통적 운영 형태 예요. EC2 위에서 클러스터를 굴리는 자체 운영과 거의 같은 사고 모델인데, 노드 추가·삭제·패치·백업 만 AWS 가 대신해 줘요.

인스턴스 패밀리 가 풍부해요. t3.small.search 부터 r7g.16xlarge.search 까지 범용·메모리 최적화·스토리지 최적화·ARM Graviton 라인업이 다 깔려 있어요. 검색 부하는 r7g.large.search (메모리 16GB) 가 시작점이고, 로그 인덱싱 위주는 i3.large.search 같은 로컬 NVMe SSD 가 비용 효율적이에요.

Multi-AZ 구성 이 사실상 필수예요. 2 AZ 또는 3 AZ 옵션을 켜면 마스터·데이터·코디네이터 노드가 AZ 단위로 분산되고, Replica = 1 이상 잡혀 AZ 한 곳이 통째로 죽어도 클러스터가 살아 있어요. 운영 환경에서 single-AZ 로 가는 건 짐 싸 두고 사고를 기다리는 모양이에요.

전용 마스터 노드 분리도 운영에선 사실상 필수예요. 데이터 노드와 마스터 노드를 같은 인스턴스에 묶으면 대규모 색인·재할당 작업 중에 마스터가 응답 불가 가 되는 사고가 잦아요. 데이터 노드 10대 이상이거나 운영 트래픽이 있으면 — 마스터 3대 m6g.large.search 정도가 표준 셋업.

Serverless 모드

2022년 말 출시된 완전 추상화 모드 예요. 인스턴스 타입·갯수·샤드 수 같은 자리를 AWS 가 자동 결정 하고, 사용자는 컬렉션 (Collection) 이라는 단위로 인덱스를 만들고 OCU (OpenSearch Compute Unit) 사용량 으로 청구돼요.

OCU 한 개 = 6GB 메모리 + 비례 CPU + 120GB 임시 스토리지 의 추상 단위예요. 최소 2 OCU 부터 시작 (인덱싱 1 + 검색 1) 이라 유휴 상태에서도 24시간 가동 비용이 발생 하는 구조라는 점이 함정. 시간당 $0.24 × 2 OCU = 최소 월 $345 정도 — 학습용·소규모 워크로드엔 Provisioned t3.small.search (월 $30~50) 가 압도적으로 싸요.

Serverless 가 빛나는 자리는 트래픽 변동이 극심한 워크로드 예요. 예를 들어 주간 보고 시간대에만 분당 1만 쿼리, 그 외엔 분당 10 쿼리 같은 패턴이면 Provisioned 로 피크 사이즈로 24시간 켜 두는 모양보다 Serverless 가 효율적.

선택 가이드

대부분의 한국 회사 운영 워크로드 = Provisioned + Multi-AZ 가 표준이고, Serverless 는 명확한 사용 자리가 있을 때만 검토 — 이렇게 정리해 두면 큰 사고 없음.

비용 모델

Provisioned 비용은 네 갈래로 쪼개져요.

(1) 데이터 노드 인스턴스 시간 — r7g.large.search 한 대 × 시간당 $0.18 × 3대 × Multi-AZ 2 = 시간당 $1.08, 월 $780 정도. 이게 본체 비용.

(2) EBS 스토리지 — gp3 100GB × 0.10$ × 노드 수 + IOPS·throughput 별도. 로그용은 i3 인스턴스 (로컬 NVMe) 가 EBS 비용을 아예 빼는 구조라 큰 데이터엔 유리.

(3) UltraWarm·Cold Storage — 핫 데이터를 UltraWarm (검색 가능 S3 캐시) 으로 옮기면 시간당 $0.024 / GB × 1000GB = 월 $17 정도로 기존 r7g 노드 비용의 1/40 까지 떨어져요. Cold Storage 는 더 싸서 S3 직접 비용 + 검색 시 활성화 모델.

(4) Data Transfer — VPC 내 트래픽은 무료 지만 Cross-AZ Replica 복제 와 외부 출력 은 과금. 큰 인덱싱 워크로드는 Single-AZ Replica = 0 으로 가서 비용을 줄이는 게 일반적이지만 HA 가 깨지는 trade-off 임을 잊으면 위험.

Serverless 비용은 OCU 사용량 × 시간 × $0.24. 인덱싱 OCU 와 검색 OCU 가 따로 청구 되고, 최소 2 OCU 24시간 이 항상 깔려 있어요. 유휴 → $345/월 기본 점이 함정.

거친 비용 가이드: 학습용 = $30~50/월, 소규모 운영 = $300~800/월, 중규모 운영 = $1,500~5,000/월, 대규모 = $10,000+ /월. Elastic Cloud 와 비교해 AWS 호스팅비 자체는 비슷, Service 추상화 비용이 Serverless 가 비싼 모양이에요.

보안 — IAM 통합·세분화 액세스·VPC

OpenSearch Service 의 보안은 AWS IAM 통합 과 fine-grained access control (FGAC) 두 축으로 굴러가요.

IAM 통합 은 AWS 계정·IAM 사용자·Role 단위로 도메인 접근 권한 을 제어해요. Resource-based Policy 와 Identity-based Policy 두 종류가 있고, 두 정책이 AND 로 평가돼서 둘 다 허용해야 접근 가능. 28편(Security · RBAC) 에서 다룬 Elasticsearch native RBAC 의 AWS 버전 이라고 보면 됩니다.

Fine-grained access control = 인덱스·필드·문서 단위 권한 을 OpenSearch 내부 사용자 (또는 SAML·Cognito 연동 사용자) 단위로 박는 기능. 예를 들어 마케팅팀은 logs- 인덱스의 user_id 필드를 가리고 검색 같은 세분화가 가능. 28편 RBAC 셋업과 거의 같은 사고 모델이에요.

VPC 격리 가 핵심이에요. 운영 도메인은 거의 모두 VPC 내부에 ENI (Elastic Network Interface) 가 박힌 형태 로 들어가요. 인터넷에 노출된 public domain 은 PoC·학습용 외에는 금기. VPC + SG + NACL 세 겹으로 막아 두는 게 표준.

암호화 는 세 곳이에요. Encryption at rest (KMS), Node-to-node encryption (TLS), Domain endpoint HTTPS (TLS). 셋 다 콘솔에서 체크박스만 켜면 자동 활성화. 콘솔에서 한 번 켠 도메인은 끄지 못함 이라 처음에 끄고 만들었다가 재생성 하는 사고가 잦아요.

인증 방식 은 세 갈래 — IAM 인증 (SigV4 서명), 내부 사용자 DB, SAML·Cognito 연동. 대시보드 로그인은 Cognito 또는 SAML, 애플리케이션 API 호출은 IAM 또는 내부 사용자 가 표준 조합이에요.

운영 — Snapshot·UltraWarm·Cold Storage·메트릭

Snapshot 자동

OpenSearch Service 는 시간별 자동 Snapshot 을 AWS 관리 S3 버킷 에 저장해요. 최근 14일치 보관·복구 가능 이 기본값. 추가로 수동 Snapshot 을 자체 S3 버킷 에 떠 두는 게 표준 — 14일 이전 복구·다른 도메인 이관·재해 복구 자리에 필요해요.

수동 Snapshot 셋업은 S3 버킷 생성 → IAM Role 부여 → 도메인에 repository 등록 → curl 로 snapshot 명령 의 4단계. 27편(Snapshot Restore) 의 자체 운영 ES 와 거의 같은 사고 모델이에요.

UltraWarm 티어

핫 인덱스를 S3 캐시 노드로 옮겨 비용을 1/10~1/40 까지 줄이는 매니지드 티어 기능이에요. 자체 운영 ES 의 Searchable Snapshot 과 비슷한 자리지만, AWS 한정·관리형 이라 사용성이 훨씬 좋아요.

흐름은 Hot (r7g 노드) → UltraWarm (S3 캐시) → Cold (S3 raw) 의 세 단계. ILM 정책 (또는 ISM, Index State Management — OpenSearch 의 ILM 대체) 으로 30일 hot → 90일 ultrawarm → 365일 cold → delete 같은 자동 흐름을 박을 수 있어요.

함정은 UltraWarm 검색 응답 — 캐시 미스 시 S3 에서 read-through 라 수 초~수십 초 까지 느려질 수 있어요. 대시보드 사용자 검색 자리엔 권장 X, 야간 배치 분석·드물게 조회되는 컴플라이언스 데이터 자리에 적합.

Cold Storage

UltraWarm 보다 한 단계 더 싼 저장 전용 티어. 검색하려면 Cold → UltraWarm 으로 일시적 mount 가 필요해서 분 단위 활성화 지연 이 있어요. 법정 보관 의무 5년 로그 같은 자리가 전형적.

CloudWatch 메트릭

OpenSearch Service 는 CloudWatch 에 거의 모든 클러스터 메트릭을 자동으로 흘려요. ClusterStatus.red·yellow·green, FreeStorageSpace, CPUUtilization, JVMMemoryPressure, SearchLatency·IndexingLatency, Shard 갯수 — 30편(Monitoring) 의 _cluster/health · _nodes/stats 정보를 AWS 콘솔에서 그래프로 직접 보는 형태.

CloudWatch Alarm 표준 셋업으로 ClusterStatus.red > 0 → SNS 알림, FreeStorageSpace < 20% → 알림, JVMMemoryPressure > 85% → 알림 세 개는 처음부터 박아 두는 게 좋아요.

자주 만나는 사고

사고 1 — 단일 AZ 설정으로 운영 진입

원인 — PoC 단계에 비용을 아끼느라 1 AZ 로 만든 도메인을 그대로 운영 트래픽에 붙임. AZ 한 곳이 통째로 죽으면 클러스터 자체가 정지.

해결 — 운영 도메인은 무조건 Multi-AZ (2 AZ 이상) + Replica ≥ 1. Single-AZ → Multi-AZ 전환은 도메인 in-place 업데이트로 가능하지만 수 시간 소요. 처음부터 잡는 게 정신 건강에 이로움.

사고 2 — IAM Resource Policy 와 Identity Policy 충돌

원인 — Resource-based Policy 가 deny 하는데 IAM Role 의 Identity Policy 는 allow 같은 모양이면 AWS 의 정책 평가 규칙상 명시적 deny 가 우선 이라 접근이 막혀요. 왜 권한이 있는데 안 되는가 가 가장 흔한 디버깅 자리.

해결 — CloudTrail 로 실제 호출 거절 사유 확인 + IAM Policy Simulator 로 평가 시뮬레이션. 운영에서는 Resource Policy 는 도메인 단위 큰 그림 (특정 VPC 만 허용), 세부 인덱스·필드 권한은 fine-grained access control 로 분리해 두면 충돌이 적어요.

사고 3 — Serverless 비용 폭증

원인 — Provisioned t3.small.search 와 같은 감각으로 Serverless 컬렉션을 켜 둠. 유휴여도 최소 2 OCU × 24시간 × $0.24 = 일 $11.52, 월 $345 부터.

해결 — 학습·소규모 = Provisioned t3.small.search 가 항상 싸요. Serverless 는 피크/유휴 차이가 10배 이상 이거나 멀티 테넌트 격리가 필요한 자리에만. Budget Alert 를 처음부터 박아 두면 사고를 일찍 발견 가능.

사고 4 — UltraWarm 검색 응답 폭증

원인 — 대시보드 사용자 검색 인덱스를 ILM 정책으로 UltraWarm 으로 자동 이동 시켜 두고는, 사용자가 옛 인덱스를 검색 할 때 S3 read-through 로 10초~30초 폭증. 사용자 컴플레인 폭주.

해결 — 사용자 facing 검색 인덱스는 UltraWarm 에 두지 않음. UltraWarm 은 야간 배치·컴플라이언스·드물게 조회되는 로그 자리에 한정. 사용자 검색은 Hot tier 에 남기고 별도 비용 처리.

사고 5 — 버전 in-place 업그레이드 한계

원인 — OpenSearch 1.x → 2.x 같은 메이저 업그레이드를 도메인 in-place 로 가능하지만, Elasticsearch 7.10 → OpenSearch 1.x 전환은 in-place 지원, Elasticsearch 7.x → 8.x 는 지원 X (AWS 가 Elasticsearch 8.x 는 제공하지 않음). 라이선스 분기 이후 AWS 매니지드의 ES 라인업은 7.10 이 종착역.

해결 — 새 도메인을 OpenSearch 로 만들고 Snapshot 으로 데이터 이관 이 표준. 27편(Snapshot Restore) 의 cross-cluster restore 절차 그대로 진행. 애플리케이션 코드는 opensearch-py 등 클라이언트로 점진적 교체.

사고 6 — VPC 도메인의 cross-region 접근 제한

원인 — VPC 도메인은 도메인 endpoint 가 ENI 로 박혀 다른 region·다른 VPC 에서 직접 접근 불가. 멀티 리전 운영에서 Tokyo region 도메인에 Seoul region 의 EKS 가 직접 붙는 시나리오가 막힘.

해결 — VPC Peering 또는 Transit Gateway 로 네트워크 연결, Route53 Private Hosted Zone 으로 도메인 endpoint 의 사설 DNS 해석. 또는 region 별로 도메인 분리 + cross-cluster replication 으로 데이터 동기화.

사고 7 — Shard 수 자동 튜닝 부재

원인 — Provisioned 모드에서 Shard 수는 여전히 직접 설계 해야 함. AWS 가 인스턴스만 관리하고 인덱스 설계는 사용자 책임. Primary Shard = 1 또는 = 100 같은 극단으로 잡으면 자체 운영과 똑같은 사고.

해결 — 27편(Shard Allocation) 의 데이터 1TB 기준 Primary Shard 20~30개 가이드 그대로. 시간 데이터는 ISM rollover 자동 셋업.

운영 권장 패턴

운영 도메인은 첫날부터 Multi-AZ + 전용 마스터 + VPC + KMS + node-to-node TLS + Domain HTTPS 를 다 켜고 시작해요. 나중에 켜는 비용이 더 큼 — 재생성 작업 + 데이터 마이그레이션 이 동반돼서 사실상 새 도메인 만들기 가 됩니다.

IAM 권한은 최소 권한 원칙 으로 service-linked role + 도메인 단위 resource policy + 인덱스 단위 fine-grained access control 세 겹으로 박아요. 전체 도메인 admin 권한을 가진 IAM Role 은 emergency break-glass 자리에만 보관하고, 평시 운영은 역할 분리된 사용자 가 fine-grained 권한으로 조작.

비용 알람은 CloudWatch + AWS Budgets 두 군데에 박아 둡니다. CloudWatch 는 메트릭 임계값 (디스크·메모리·노드 수) 알람, Budgets 는 월 비용 예산 80%·100% 알람. Serverless 도메인은 OCU 사용량 메트릭 도 별도 알람으로.

ISM 정책 (OpenSearch 의 ILM 대체) 으로 Hot → UltraWarm → Cold → Delete 자동 흐름을 박아 두면 로그 비용이 시간이 갈수록 줄어드는 구조가 자동으로 잡혀요. 수동으로 인덱스 청소 하는 모양은 사고 친화적.

시험 직전 한 번 더 — 압축 노트

• OpenSearch = 2021년 AWS 가 Elasticsearch 7.10.2 fork 로 만든 Apache 2.0 검색 엔진. 2024년 Linux Foundation 산하 OpenSearch Software Foundation 거버넌스.
• AWS OpenSearch Service = AWS 매니지드 OpenSearch + legacy ES 7.10 이하. 과거 Amazon Elasticsearch Service 의 후신.
• 운영 단위 = Domain, 두 모드 = Provisioned vs Serverless.
• Provisioned = 인스턴스 단위 사이즈, t3·m6g·r7g·i3 라인업, Multi-AZ + 전용 마스터 표준.
• Serverless = OCU (OpenSearch Compute Unit) 단위 자동 스케일, 최소 2 OCU · 월 $345 부터, 피크/유휴 차이 큰 자리.
• 인스턴스 시작점 = 학습 t3.small.search, 검색 r7g.large.search, 로그 i3.large.search.
• 비용 4갈래 = 데이터 노드 시간 + EBS + UltraWarm/Cold + Data Transfer.
• UltraWarm = S3 캐시 노드 티어, 비용 1/10~1/40. 단 검색 응답이 수 초~수십 초 까지 폭증 가능.
• Cold Storage = S3 raw, 분 단위 mount 지연, 컴플라이언스 5년 로그 자리.
• 보안 = IAM 통합 + fine-grained access control + VPC + KMS + node-to-node TLS + HTTPS. 한 번 끄고 만들면 재생성 필요.
• 인증 = IAM SigV4 · 내부 사용자 · SAML · Cognito. 대시보드는 Cognito/SAML, API 는 IAM/내부 사용자.
• ES 와 차이 = 라이선스 (Apache vs SSPL), 보안 무료, ML Commons, Alerting Plugin 무료.
• in-place 업그레이드 한계 = ES 7.x → 8.x 지원 X, ES 7.10 → OpenSearch 는 가능. 메이저 전환은 Snapshot + 새 도메인.
• 7대 사고 = Single-AZ 운영·IAM Resource Policy 충돌·Serverless 비용 폭증·UltraWarm 응답 폭증·메이저 업그레이드 한계·VPC cross-region 제한·Shard 수 미설계.
• 메트릭 = CloudWatch 자동, 알람 3개 = cluster status red, free storage < 20%, JVM memory > 85%.
• 운영 권장 = Multi-AZ + 전용 마스터 + VPC + KMS + ISM 자동 티어링 + Budget 알람 처음부터 다 켜기.
• 한국 시장 표준 = 신규 AWS 프로젝트 = OpenSearch Service, 멀티 클라우드·자체 운영 = Elastic Cloud 또는 self-managed ES.

시리즈 다른 편

• 30편 = Monitoring — _cluster/health · _nodes/stats · slow log · Grafana 대시보드
• 31편 = Performance Tuning — Refresh interval · Shard size · Heap · Query rewrite
• 32편 = Spring Data Elasticsearch — Repository · Template · POJO 매핑
• 33편 = Kibana · ELK Stack — Logstash · Beats · Dashboard 설계
• 34편 = Observability — APM · OpenTelemetry · Trace 연동
• 다음 글 = 36편 Elastic Cloud — Hosted · Serverless · Multi-Cloud · 한국 region
• 37편 = IaC — Terraform · CloudFormation · CDK 로 OpenSearch 자동화
• 38편 = 시리즈 마무리 — 결정 트리·체크리스트·자격증

한 줄 정리 — AWS OpenSearch Service = Apache 2.0 OpenSearch 를 매니지드로 제공 하는 AWS 표준 검색 인프라. Provisioned (운영 표준) vs Serverless (피크/유휴 큰 자리) 둘 중 선택이 결정적이고, Multi-AZ + 전용 마스터 + VPC + KMS + ISM 자동 티어링 을 처음부터 다 켜고 시작 하는 게 운영 후 사고 90% 를 미리 막는 길.