Elasticsearch 입문 36편 — Elastic Cloud (Hosted·Serverless·ECE·ECK)

이 글은 Elasticsearch 입문에서 운영까지 시리즈 38편 중 36편이에요. 35편이 AWS 환경에서 OpenSearch 라는 한 갈래를 깊이 봤다면, 36편은 Elastic 사가 직접 운영해 주는 다른 갈래 — Elastic Cloud 를 봅니다. AWS·GCP·Azure 어느 위에서 돌리든 Elastic 사 직접 매니지드 가 핵심이고, 네 가지 라인업 (Hosted·Serverless·ECE·ECK) 이 각각 다른 운영 결을 잡아요.

Elastic Cloud 라는 자리

Elastic Cloud 는 Elastic 사 (Elasticsearch 를 만든 그 회사) 가 직접 운영해 주는 매니지드 서비스예요. AWS·GCP·Azure 세 곳 위에서 돌고, 사용자가 deployment 라는 단위로 클러스터를 한 번 만들면 그 뒤로는 노드 패치·버전 업그레이드·스냅샷·모니터링 을 Elastic 사 쪽에서 알아서 해 줘요.

35편 AWS OpenSearch Service 와 자주 헷갈리는데, 결정적인 차이가 두 가지. 첫째, 누가 운영하는가 — Elastic Cloud 는 Elastic 사, AWS OpenSearch 는 AWS. 둘째, 무엇을 운영하는가 — Elastic Cloud 는 진짜 Elasticsearch (최신 8.x·9.x 가 즉시 반영), AWS OpenSearch 는 fork 된 OpenSearch (Elasticsearch 와 점점 다른 길). 같은 AWS 위 에 둘이 다 올라가지만 물건 자체가 다른 도구 예요.

가격은 거의 늘 비슷한 인스턴스 사양 기준 Elastic Cloud 가 20~30% 비싸요. 대신 Machine Learning · Cross-cluster Replication · Searchable Snapshot · Frozen Tier · Enterprise Search · APM · Synthetics 같은 상용 기능 이 기본 포함 이라 Total Cost 로 보면 역전되는 자리가 많아요. 기능을 다 쓰면 Elastic Cloud 가 싸고, 검색·로그만 쓰면 OpenSearch 가 싸다 가 거친 결론.

Elastic Cloud 라인업은 작성 시점(2026-05-19) 기준 네 가지로 정리돼요. 각 라인업이 어떤 회사 자리 에 맞는지 한 줄로 먼저 잡고 들어가요.

• Hosted — 전통 클러스터 단위 매니지드. 가장 오래되고 표준.
• Serverless — 클러스터 개념 없음, 사용량 기반. 8.13+ 신규 라인.
• ECE (Elastic Cloud Enterprise) — 자체 데이터센터 에 깔리는 매니지드. on-premise 요구 회사용.
• ECK (Elastic Cloud on Kubernetes) — Kubernetes Operator 형태. K8s 표준화된 인프라용.

이 네 가지를 본문에서 하나씩 깊이 들어갑니다.

Hosted — 가장 표준, 가장 많이 쓰는 라인

Hosted 가 Elastic Cloud 의 기본형 이에요. deployment 라는 단위로 클러스터 한 개를 만들고, 각 노드의 사양·갯수·region 을 직접 정해서 운영해요. 35편 AWS OpenSearch Service 의 Domain 이랑 거의 같은 결 이라고 보면 됩니다.

Deployment 생성 흐름은 단순해요. Solution (Elasticsearch·Observability·Security 중 택일) → Cloud Provider (AWS·GCP·Azure) → Region → Hardware Profile → Version → Deployment Name 순서로 5분 안에 끝나요. Hardware Profile 자리에 Storage optimized · General purpose · CPU optimized · Vector search optimized · Machine Learning 같은 목적별 템플릿 이 미리 준비돼 있어서, 클러스터 사양을 백지에서 설계 안 해도 돼요.

Deployment Templates 가 Hosted 의 핵심 강점이에요. Hot/Warm/Cold/Frozen 4-tier 가 한 deployment 안에 묶여 있어서, ILM 만 잡아 두면 최신 데이터는 Hot (NVMe SSD), 7일 지난 데이터는 Warm (SSD), 30일 지난 데이터는 Cold (HDD), 90일 지난 데이터는 Frozen (S3 검색 가능) 으로 자동 이동해요. 6편(ILM) 에서 잡은 lifecycle 이 여기서 비용 절감 무기 로 직결.

Frozen Tier 가 특히 강력해요. 데이터를 S3 / GCS / Azure Blob 같은 오브젝트 스토리지 에 두고, 그 자리에서 직접 검색 까지 해요. 검색 응답이 Hot 의 100배 느린 대신 스토리지 비용은 1/30 라서, 365일 보관 의무 가 있는 로그·금융 데이터에 표준 답.

Auto-scaling 이 machine learning · frozen tier 만 자동, hot tier 는 수동 이 기본이에요. 예측 못 한 트래픽 폭증 이 검색 자리에서 잦지 않아서 자동화 우선순위가 낮은 자리. 운영자가 Cloud Console 에서 vCPU·RAM·storage 를 슬라이더로 올리면 5분 내 rolling restart 로 반영돼요.

Serverless — 클러스터 개념을 지운 신규 라인

Elastic Cloud Serverless 가 2024년 12월 GA 된 신규 라인이에요. 클러스터·노드·샤드 개념을 사용자에게서 완전히 숨긴 모델이고, AWS OpenSearch Serverless 와 비슷한 결.

가장 큰 변화 두 가지. 첫째, 클러스터 사양을 안 정해요. vCPU·RAM·storage 슬라이더가 사라지고, project 라는 단위 하나만 만들면 됩니다. 둘째, 사용량 기반 과금. VCU (Virtual Compute Unit) 라는 단위로 Search VCU · Indexing VCU · ML VCU 세 가지가 분 단위로 카운트 돼요. 트래픽이 0 이면 거의 0 원, 폭증하면 자동 확장.

Project 타입은 세 가지로 Solution 별로 분리 돼 있어요.

• Elasticsearch project — 검색·벡터 검색 용. kNN·Semantic search·ELSER 같은 AI 검색 기능 이 1급.
• Observability project — 로그·메트릭·APM 용. Logs·Metrics·Traces 가 한 화면에 통합.
• Security project — SIEM·EDR 용. Detection rules·Cases·Timeline 이 1급.

세 타입이 같은 Serverless 인프라 위 에 올라가지만 UI·기능·과금 메뉴가 다르게 묶여 있어서, 목적 부터 명확해야 결정이 쉬워요.

Serverless 의 주의 자리 가 몇 개 있어요. 모든 ES 기능을 다 지원하진 않아요 — Cross-cluster Replication · Custom Plugin · 자체 mapping repository 같은 고급 운영 기능 이 빠져 있고, 클러스터 settings 를 직접 못 바꿔요. 완전 매니지드 = 자유도 낮음 의 일반 법칙. 그래서 처음 시작 이나 작은~중간 규모 자리엔 좋고, 대규모 커스텀 운영 자리엔 Hosted 가 답.

또 한 가지 — Serverless 는 처음부터 8.13+ 이에요. 이전 버전을 못 쓰고, 기존 Elasticsearch 클러스터에서 직접 마이그레이션 도 snapshot restore 기반이라 약간의 변환이 필요해요.

ECE — 자체 데이터센터로 들이는 매니지드

ECE (Elastic Cloud Enterprise) 는 Elastic 사의 매니지드 환경을 사용자 자체 인프라로 가져오는 라인이에요. 핵심 자리는 클라우드 사용이 금지된 회사 — 금융·국방·공공·의료 같은 데이터 외부 반출 금지 규제 환경.

ECE 는 Docker / Kubernetes 위에 깔리는 소프트웨어 패키지 형태로 배포돼요. 사용자 데이터센터의 기존 베어메탈·VM·K8s 클러스터 에 ECE 설치 → Elastic Cloud 와 거의 동일한 Cloud Console 이 자체 인프라 위에 뜨고 → 거기서 deployment·hardware profile·ILM·snapshot 을 똑같이 운영해요.

설치 요구 사양이 자체 운영에 비해 좀 무거워요. 3 대 이상의 director node (controller) 가 필요하고, 각 노드 16+ vCPU·64GB+ RAM 이 권장. 소규모 자리엔 안 맞고, 50+ deployment 를 한 통에서 관리 하는 진짜 enterprise 자리부터 ROI 가 나옵니다.

ECE 의 강점은 멀티테넌트 예요. 한 사내에 A팀·B팀·C팀 이 각각 별도 클러스터를 운영하는 자리에서, ECE 한 통 으로 모든 팀의 deployment 를 동일 콘솔 에서 동일 운영 절차 로 관리해요. 각 팀이 자체적으로 ES 클러스터를 띄우는 비용·실수 가 사라져요.

라이선스가 Elastic 의 enterprise 구독 이 필수예요. 가격이 Elastic Cloud Hosted 와 비슷한 수준 + 자체 인프라 비용 + 운영 인력 이라서, 진짜 클라우드 금지 환경이 아니면 Hosted 가 거의 늘 더 싸요.

ECK — Kubernetes Operator 형태

ECK (Elastic Cloud on Kubernetes) 가 4가지 중 가장 현장 친화 라인이에요. Kubernetes Operator + CRD (Custom Resource Definition) 형태로 배포되고, 사용자 K8s 클러스터 위 에서 Elasticsearch·Kibana·Beats·Logstash·APM Server·Enterprise Search 같은 모든 Elastic 컴포넌트를 kubectl apply 로 관리해요.

설치는 Helm chart 한 줄 이면 끝.

helm repo add elastic https://helm.elastic.co
helm repo update
helm install elastic-operator elastic/eck-operator -n elastic-system --create-namespace

Operator 가 떠 있으면 그 뒤로 Elasticsearch CRD 한 장으로 클러스터를 띄워요.

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: prod-es
spec:
  version: 8.16.0
  nodeSets:
  - name: hot
    count: 3
    config:
      node.roles: ["master", "data_hot", "ingest"]
    podTemplate:
      spec:
        containers:
        - name: elasticsearch
          resources:
            requests:
              cpu: 4
              memory: 16Gi
            limits:
              memory: 16Gi
    volumeClaimTemplates:
    - metadata:
        name: elasticsearch-data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 200Gi
        storageClassName: gp3

ECK 의 큰 매력 두 가지. 첫째, 기존 K8s 운영 도구를 그대로 씀 — kubectl·helm·kustomize·ArgoCD·Flux 가 다 통해요. 둘째, 멀티 클라우드·하이브리드 가 자연스러움. EKS·GKE·AKS·on-premise K8s 어디에 깔든 운영 절차가 같아요.

대신 직접 운영 결이 강해요. Hosted·ECE 가 콘솔에서 슬라이더 한 번 누르면 끝 이라면, ECK 는 YAML 을 직접 짜고 git 으로 관리 하는 결. DevOps 가 강한 회사 자리엔 ECK 가 가장 자연스럽고, DevOps 인력 없음 자리엔 Hosted·Serverless 가 답.

작성 시점 ECK 최신은 2.16.x (Operator 버전) 이고, 지원 ES 버전은 7.17+ ~ 9.x 까지. Operator 버전 ↔ ES 버전 매트릭스가 공식 compatibility matrix 에 명시돼 있어서, 업그레이드 전에 매트릭스 확인 이 운영 1번 규칙. (사고 4 참조.)

비용 모델 — instance hour vs VCU

Elastic Cloud 의 과금 단위 가 라인별로 달라요. 같은 워크로드 가격을 비교할 때 매번 헷갈리는 자리니까 한 번 정리.

Hosted 는 instance 시간 + storage GB-month + outbound transfer 의 세 축 합산 이에요. AWS r6g.large 같은 EC2 가격에 Elastic 마진 20~30% 가 붙은 가격이라고 보면 거의 맞아요. 예약 요금 (1년·3년 약정) 이 30~50% 할인 까지 가능.

Serverless 는 VCU (Virtual Compute Unit) + storage GB-month 의 두 축이에요.

• Search VCU = 검색 쿼리 처리량. 분 단위 max load 기준.
• Indexing VCU = 색인 처리량.
• ML VCU = 머신러닝 추론 (ELSER·임베딩) 처리량.

VCU 가격이 작성 시점 기준 시간당 $0.1~0.3 자리이고, 분 단위 카운트 라서 피크 1시간 외엔 거의 0 인 워크로드에서 비용이 극적으로 떨어져요. 반대로 24시간 풀로드 워크로드는 Hosted 가 더 싸요.

ECE 는 Elastic Enterprise 구독 + 자체 인프라 비용. 자체 인프라가 이미 sunk cost 인 환경에선 구독 라이선스 비용만 추가.

ECK 는 Kubernetes 위에서 사용자 직접 운영 이라 Elastic 사에 별도 사용료 X (Basic license 무료 기능 한도 내). 상용 기능 (Machine Learning·Cross-cluster Replication·Searchable Snapshot 등) 을 쓰려면 Enterprise 구독 별도 구매.

거친 의사결정 표.

ES vs AWS OpenSearch vs Elastic Cloud 선택 가이드

35편이 AWS 환경 = OpenSearch 라고 결론을 냈는데, 36편이 Elastic Cloud 를 깊이 본 지금은 그 결론이 항상 옳진 않다 는 게 명확해져요. 네 축으로 다시 봅니다.

(1) 라이선스 — Apache 2.0 만 허용하는 회사·정부 자리는 OpenSearch. SSPL/Elastic License 가 OK 면 Elasticsearch 가 기능·생태계 측면에서 우위.

(2) 기능 — Machine Learning · Cross-cluster Replication · Frozen Tier · APM · Enterprise Search · ELSER (Elastic 자체 sparse vector 모델) 같은 고급 기능 이 필요하면 Elastic Cloud 가 압도적. OpenSearch 는 기본 검색·집계·기본 kNN 까지는 동등하지만 그 위 자리가 점점 갈라져요.

(3) 운영 결 — 완전 매니지드 + 기능 1급 + 가격 약간 비쌈 = Elastic Cloud Hosted. 완전 매니지드 + AWS IAM/VPC 통합 + 가격 약간 쌈 = AWS OpenSearch Service. 직접 운영 + 기능 자유 + 인력 부담 = ECK 또는 EC2·VM 직접 설치.

(4) 비용 — 고급 기능 다 씀 → Elastic Cloud (총 비용 우위). 기본 검색·로그만 → OpenSearch (단가 우위). 피크 트래픽 짧음 → Serverless (둘 다 우위).

네 축을 한 표로 압축.

자주 만나는 사고

사고 1 — Region 미고려

원인 — Elastic Cloud deployment 를 AWS us-east-1 에 만들었는데, 앱이 AWS ap-northeast-2 (서울) 에서 돈다. cross-region 으로 검색 응답이 200ms+ 기본 RTT 가 깔려요.

해결 — deployment region = 앱 region 이 1번 규칙. Elastic Cloud 는 region 변경이 안 됨 — snapshot → 새 region 에 restore 로 마이그레이션 필요. 최초 생성 시 region 결정 이 가장 중요.

사고 2 — Snapshot Lifecycle Policy (SLM) 미설정

원인 — Hosted 가 기본 자동 스냅샷 을 30분마다 직전 24시간 만 보관해요. 30일 전 데이터 복구 가 안 됨.

해결 — Custom Snapshot Repository 를 S3/GCS 에 만들고 SLM 으로 일별·주별·월별 보존 정책을 명시. 28편(Snapshot) 패턴 그대로.

사고 3 — Hot Tier 폭증

원인 — ILM 을 안 잡아서 모든 데이터가 Hot 에 쌓이고, Hot 디스크가 90% 도달 해서 write 거부. NVMe SSD 단가가 Cold 의 30배 라 비용도 폭증.

해결 — 7일 → Warm, 30일 → Cold, 90일 → Frozen 의 4-tier ILM 을 deployment 생성 직후 박아 둠. 6편(ILM) 패턴.

사고 4 — ECK Operator Version Mismatch

원인 — ECK Operator 2.10 에 Elasticsearch 9.0 을 띄우려고 시도. 공식 compatibility matrix 미확인. Operator 가 ES 9.x 를 모르고 reconcile 무한 루프.

해결 — ECK Operator ↔ ES 버전 매트릭스 를 항상 먼저 확인. Operator 부터 먼저 업그레이드 → 그다음 ES 가 표준 순서.

사고 5 — Serverless Project Size Limit

원인 — Serverless 가 project 당 storage 상한 (작성 시점 기준 1PB) 과 VCU 상한 이 있어요. 대규모 batch indexing 으로 짧은 시간 안에 한도 초과 → throttle.

해결 — 대규모 색인은 Hosted·ECK 가 답. Serverless 는 작은~중간 규모 자리. 한도 초과 자주 발생하면 라인 자체를 바꿔야 함.

사고 6 — Cross-cluster Replication 미지원 자리 선택

원인 — 멀티 region 재해 복구 가 요구인데 Serverless 또는 Basic 라이선스 ECK 를 골랐고, Cross-cluster Replication (CCR) 이 안 됨.

해결 — CCR 필요 → Hosted Platinum/Enterprise 또는 ECE/ECK + Enterprise 구독. Serverless 는 현재 CCR 미지원 (2026-05 시점).

사고 7 — Cloud Provider Lock-in 가정

원인 — Elastic Cloud = AWS 전용 으로 잘못 알고 deployment 를 AWS 에 만들었다가, 회사가 GCP 로 표준 변경. 동일 region 안에서 AWS → GCP 마이그레이션 도구가 없음.

해결 — 최초 deployment 시 cloud provider 도 region 만큼 결정적. 멀티 클라우드 요구 면 ECK + 각 클라우드 K8s 가 가장 유연.

운영 권장 패턴

(1) Production 은 Hosted 또는 ECK, PoC 는 Serverless

프로덕션 SLA 가 명확한 자리 는 Hosted (운영 부담 X) 또는 ECK (자유도) 둘 중 하나로 가요. Serverless 는 PoC·내부 도구·트래픽 가변 자리 에서 최고의 시작 비용·시간 우위.

(2) Region·Cloud Provider 는 최초에 못 박기

deployment 생성 폼에서 region 과 cloud provider 를 바꾸려면 새 deployment + snapshot restore 가 유일한 길. 5분짜리 결정이 향후 1년 비용을 결정 하니까 앱·DB·캐시 region 과 동일 인지 체크리스트 로 박아 둡니다.

(3) ILM 4-Tier 를 deployment 와 같이 박기

새 deployment 만들고 첫 인덱스 만들기 전에 ILM 정책 4-tier 를 만들어 두면 Hot Tier 폭증 사고 가 사라져요. 6편 ILM 패턴이 Elastic Cloud 위에서 직접 비용 우위 로 환산됨.

(4) ECK 는 GitOps 와 묶기

ECK 의 YAML 을 손으로 kubectl apply 하면 ECE 의 매니지드성을 다 잃어요. git repo + ArgoCD/Flux 로 모든 변경이 git PR 을 거쳐 들어가게 묶어야 진짜 운영 친화 가 돼요.

(5) Stack Monitoring 별도 deployment 분리

운영 deployment 와 monitoring deployment 를 같은 자리 에 두면 로그·메트릭 폭증 이 검색 응답을 막는 사고가 잦아요. Elastic Cloud 는 monitoring 전용 deployment 를 1/4 사이즈 로 별도로 만들고 Stack Monitoring 으로 두 deployment 를 연결하는 게 표준.

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

• Elastic Cloud = Elastic 사 직접 매니지드, AWS·GCP·Azure 위.
• 35편 OpenSearch vs 36편 Elastic Cloud — 운영자 (AWS vs Elastic), 도구 (OpenSearch vs Elasticsearch), 가격 (싼 단가 vs 1급 기능).
• 라인업 4 — Hosted · Serverless · ECE · ECK.
• Hosted — deployment 단위, Hot/Warm/Cold/Frozen 4-tier, Deployment Templates, Auto-scaling 부분만.
• Serverless — 2024-12 GA, VCU 분 단위 과금, project 3 타입 (ES·Observability·Security), 클러스터 개념 사라짐.
• ECE — 자체 DC 매니지드, Docker/K8s 위, director node 3+, 멀티테넌트 강함.
• ECK — K8s Operator + CRD, helm install, YAML/GitOps, Operator-ES 버전 매트릭스 필수.
• VCU — Search VCU · Indexing VCU · ML VCU 세 축, 시간당 $0.1~0.3.
• Frozen Tier — S3/GCS 직접 검색, 응답 100배 느림, 비용 1/30.
• Hot 폭증 · Region 미고려 · SLM 미설정 · Operator mismatch · Serverless 한도 · CCR 미지원 · Cloud 락인 이 7대 사고.
• CCR (Cross-cluster Replication) = Hosted Platinum/Enterprise·ECE/ECK Enterprise 만, Serverless 미지원.
• 선택 트리 — Apache 2.0 강제 → OpenSearch · K8s 표준 → ECK · 자체 DC → ECE · 가변 트래픽 → Serverless · 그 외 → Hosted.
• Region·Cloud Provider = deployment 최초 생성 시 결정, 사실상 불변.
• 상용 기능 = Machine Learning · CCR · Searchable Snapshot · Frozen · APM · Enterprise Search · ELSER → Elastic Cloud 압도.

시리즈 다른 편

• 이전 글 = 35편 AWS OpenSearch Service — Domain·Serverless·Provisioned
• 다음 글 = 37편 IaC — Terraform·CDK·Helm·ECK Manifest
• 6편 = ILM — Hot/Warm/Cold/Frozen 4-tier
• 28편 = Snapshot — repository·restore·SLM
• 30편 = Monitoring — Stack Monitoring·Prometheus·Grafana
• 33편 = Kibana·ELK — Logstash·Beats·Discover
• 34편 = Observability — APM·logs·metrics 통합
• 38편 = 시리즈 마무리 — 결정 트리·체크리스트·자격증

한 줄 정리 — Elastic Cloud = Elastic 사 직접 매니지드 4가지 라인업. Hosted (표준)·Serverless (가변 트래픽)·ECE (자체 DC)·ECK (K8s) 가 각각 다른 자리. AWS OpenSearch 대비 단가는 20~30% 비싸지만 ML·CCR·Frozen·ELSER 같은 1급 기능이 기본 포함 이라 총 비용 역전 자리가 많은 선택지.