APM 솔루션 비용 2026, Datadog·New Relic·CloudWatch 예산 기준

APM 솔루션 비용 산정을 위해 SRE가 대시보드와 예산표를 검토하는 장면 — APM 예산은 host 단가보다 trace ingestion, retention, 사용자 권한, 알림 운영이 함께 만든다.

APM 솔루션 비용을 검색하는 팀은 보통 장애가 한 번 난 뒤에 견적서를 연다.

하지만 APM은 대시보드 하나를 사는 일이 아니라 코드 계측, trace 저장, 로그 연결, 알림 운영, 장애 회고 방식을 바꾸는 구매다.

가격표만 보면 Datadog은 host와 span, New Relic은 사용자와 data ingest, CloudWatch는 signal과 trace 단위가 먼저 보인다.

그래서 같은 40개 서비스라도 어느 제품이 싸다고 단정하기 어렵다.

이 글은 APM 솔루션 비용을 공식 가격표 숫자와 운영 driver로 나눠서 예산 검토 순서를 정리한다.

핵심 요약

APM 비용은 billable host, Fargate task, ingested spans GB, indexed spans million, data ingest GB, signal count, engineer user 수에서 갈린다.
Datadog APM은 host 기반 가격과 span 초과 비용을 먼저 보고, New Relic은 100GB 무료 ingest 이후 GB 단가와 사용자 과금을 같이 본다.
CloudWatch Application Signals와 X-Ray는 요청·SLO signal, trace 저장·검색 수량이 커질 때 비용이 급격히 바뀐다.
OpenTelemetry Collector를 중간에 두면 벤더 교체 여지는 생기지만 sampling, 속성 제거, Collector 운영 책임이 새 비용으로 남는다.

이 글이 필요한 사람

Datadog, New Relic, CloudWatch 견적을 같은 기준으로 비교해야 하는 SRE 리드
APM 도입 뒤 trace와 log 비용이 예산보다 빨리 늘어난 경험이 있는 플랫폼팀
장애 대응 속도는 높이고 싶지만 전체 서비스를 전부 계측할지 고민하는 개발 조직
관측성 예산을 FinOps 보고서에 넣어야 하는 클라우드 비용 담당자
PII가 trace attribute로 흘러갈 위험을 보안팀과 미리 정리해야 하는 기술 책임자

공식 가격표 핵심 숫자부터 맞춘다

Datadog APM Billing 문서는 APM, APM Pro, APM Enterprise의 host 기반 과금과 span 초과 비용을 공개한다.

공식 표 기준 APM Host는 월 31 USD, APM Pro는 월 35 USD, APM Enterprise는 월 40 USD가 기준이다.

같은 문서에서 Fargate는 concurrent task 월 6 USD로 설명된다.

APM host마다 월 150GB ingested spans와 100만 indexed spans가 포함되고, 초과 ingested spans는 GB당 0.10 USD로 제시된다.

초과 indexed spans는 월 100만 spans당 1.70 USD로 제시된다.

Datadog pricing FAQ는 standalone APM 가격을 APM 36 USD, APM Pro 41 USD, APM Enterprise 47 USD per host per month로 별도 설명한다.

공식 출처	공식 숫자	비용 driver	예산 검토 질문
Datadog APM Billing	APM 31 USD, Pro 35 USD, Enterprise 40 USD per host/month	Billable APM host와 plan tier	APM host가 실제 trace를 보내는 host인지 확인했는가
Datadog Pricing FAQ	Standalone APM 36 USD, Pro 41 USD, Enterprise 47 USD per host/month	Infrastructure Monitoring 없이 APM만 구매할 때	현재 계약이 standalone인지 infra 결합 모델인지 확인했는가
Datadog APM Billing	150GB ingested spans와 100만 indexed spans included per APM host	Trace volume과 retention filter	상위 10개 noisy service가 포함량을 얼마나 쓰는가
Datadog APM Billing	Additional ingested spans 0.10 USD/GB	초과 trace ingest	staging과 batch job trace를 기본 제외했는가
Datadog APM Billing	Additional indexed spans 1.70 USD per million per month	검색 가능한 retained span	장애 분석에 필요한 span만 index하는가
Datadog APM Billing	Fargate 6 USD per concurrent task/month	Serverless나 task 기반 workload	task 수 변동이 월말 평균에 어떻게 잡히는가

이 글은 LLM API 가격표가 아니므로 입력 토큰과 출력 토큰 기준 대신 APM host, GB, indexed spans, signals, USD 단가를 본다.

따라서 “APM 한 달 얼마”라는 질문은 먼저 사용량 단위를 맞춰야 답이 나온다.

New Relic과 CloudWatch는 과금 축이 다르다

New Relic pricing은 100GB data ingest 무료 구간과 사용자 유형별 가격을 앞에 둔다.

공식 설명 기준 core user는 49 USD부터, full platform user는 edition에 따라 10 USD부터 시작한다.

또한 original data option은 무료 100GB 이후 월 0.40 USD/GB이고, Data Plus는 월 0.60 USD/GB로 설명된다.

EU data center 저장은 추가 0.05 USD/GB per month로 제시된다.

CloudWatch pricing은 Application Signals와 X-Ray trace 수량을 예시로 제시한다.

AWS 예시에서는 signal 100만 개당 1.50 USD, 다음 구간 0.75 USD, 더 큰 구간 0.30 USD가 계산에 쓰인다.

같은 예시에서 X-Ray 저장 trace는 0.000005 USD, 검색·스캔 trace는 0.0000005 USD 단위로 계산된다.

제품·모델	공식 숫자	강점	주의할 비용
New Relic	100GB data ingest free, 이후 original 0.40 USD/GB	host 수보다 ingest와 사용자 중심으로 예산을 잡기 쉽다	전사 full user와 Data Plus 선택이 커지면 좌석·GB 비용이 같이 오른다
New Relic	Core user 49 USD부터, full platform user 10 USD부터	개발자 접근 권한을 세분화해 볼 수 있다	권한 관리가 없으면 full platform user가 늘어날 수 있다
New Relic	Data Plus 0.60 USD/GB, EU 저장 추가 0.05 USD/GB	보존·거버넌스 요구를 가격 항목으로 분리한다	규제나 EU 보관 요구가 있으면 GB 단가가 바뀐다
CloudWatch Application Signals	100만 signals당 1.50 USD, 0.75 USD, 0.30 USD tier 예시	AWS workload와 IAM·CloudWatch 운영 흐름이 맞다	요청량과 SLO signal 수가 커지면 월 비용이 빠르게 커진다
AWS X-Ray	Stored trace 0.000005 USD, scanned/retrieved trace 0.0000005 USD 예시	샘플링 비율을 비용 변수로 직접 본다	trace search 습관이 많으면 분석 비용도 추적해야 한다

이 조건이면 New Relic 모델을 먼저 검토한다.

서비스 수는 많지만 host 수 산정이 어렵고, 개발자별 접근 권한과 data ingest 통제가 예산의 핵심인 경우다.

이 조건이면 CloudWatch 중심 파일럿이 자연스럽다.

대부분의 workload가 AWS 안에 있고, X-Ray와 CloudWatch Logs, Metrics, Application Signals 운영 경험이 이미 있는 경우다.

APM 솔루션 비용은 “몇 대”보다 “얼마나 남길지”에서 갈린다

AWS의 APM 설명은 응답 시간, 오류율, transaction tracing, instance, request, uptime, SLA를 대표 지표로 설명한다.

이 지표를 전부 오래 저장하고 전부 검색 가능하게 만들면 비용은 자연스럽게 오른다.

Datadog도 ingestion controls와 retention filters로 trace volume과 저장 대상을 조정하는 흐름을 문서화한다.

핵심은 모든 요청을 영구 보관하는 것이 아니다.

장애 원인 분석에 필요한 error, high latency, checkout, payment, identity trace를 우선 남기고 정상 트래픽은 sampling으로 줄여야 한다.

비용 driver	늘어나는 이유	줄이는 기준	실패 신호
Billable host	서비스와 node가 늘면 agent가 붙는 host도 늘어난다	DB, cache, queue처럼 trace를 보내지 않는 host를 분리한다	host 수와 service 수가 맞지 않는다
Ingested spans	정상 요청, batch job, health check가 모두 trace를 만든다	endpoint별 sampling과 health check 제외를 둔다	상위 10개 endpoint가 ingest 대부분을 차지한다
Indexed spans	검색과 회고를 위해 span을 보존한다	error, p95 latency, VIP flow 중심으로 retention filter를 둔다	장애와 무관한 span이 30일 보존된다
Data ingest GB	logs, traces, metrics, profiles가 한 계정에 합쳐진다	팀별 ingest owner와 예산 alert를 둔다	신규 서비스 배포 후 GB가 설명 없이 증가한다
User seats	장애 대응 참여자가 모두 고급 권한을 요구한다	dashboard viewer와 incident owner 권한을 분리한다	퇴사자와 이동자 좌석이 남아 있다

이 경우는 비싼 APM도 값어치가 낮다.

대시보드는 멋지지만 alert owner, trace retention 정책, deploy marker, incident workflow가 연결되지 않는 경우다.

반대로 단가가 높아도 p95 지연과 오류 원인을 10분 안에 찾고 rollback 판단이 빨라지면 운영 비용은 줄 수 있다.

OpenTelemetry는 비용 절감 도구가 아니라 선택권 확보 장치다

OpenTelemetry 공식 문서는 OTel을 traces, metrics, logs를 생성·수집·export하는 vendor-agnostic observability framework로 설명한다.

또한 OpenTelemetry 자체는 observability backend가 아니며 저장과 시각화는 다른 도구의 몫이라고 분리한다.

이 구분이 비용 검토에서 중요하다.

OTel Collector를 두면 Datadog, New Relic, CloudWatch, Grafana 계열로 보내는 경로를 바꾸기 쉬워진다.

하지만 Collector 운영, sampling 정책, 속성 삭제, 장애 시 backpressure 대응은 새 운영 비용이다.

이 조건이면 OTel을 앞에 둔다.

벤더 변경 가능성이 높고, 여러 언어와 runtime이 섞였으며, trace attribute 보안 통제가 필요한 경우다.

이 경우는 단일 벤더 agent부터 시작한다.

팀이 작고 첫 장애 분석 체계를 빨리 잡아야 하며, Collector 운영자를 둘 여유가 없는 경우다.

실무 시나리오 1: 결제 API 8개 서비스의 trace 폭증

구독 결제 회사가 checkout, billing, account, notification 서비스를 모두 APM에 붙였다고 가정하자.

첫 달에는 오류 원인 파악이 빨라졌지만 결제 성공 요청과 health check trace까지 전부 남아 비용이 예산을 넘는다.

이 조건이면 제품 교체보다 retention policy와 sampling을 먼저 고친다.

결제 실패, refund, payment provider timeout, identity error trace는 보존하고 정상 heartbeat와 polling endpoint는 낮은 비율로 둔다.

성공 기준은 “trace가 많다”가 아니라 장애 회고 때 필요한 span을 15분 안에 찾는 것이다.

실무 시나리오 2: 개발자 60명이 모두 full 권한을 요구하는 조직

New Relic처럼 사용자 유형이 예산에 영향을 주는 모델에서는 좌석 정책이 비용 통제의 핵심이다.

모든 개발자에게 full platform 권한을 주면 장애 분석은 편하지만 월 비용과 데이터 접근 위험이 같이 오른다.

이 조건이면 권한을 incident responder, service owner, dashboard viewer로 나눈다.

장애 주간 on-call은 높은 권한을 갖고, 일반 개발자는 dashboard와 alert 상태를 보는 권한부터 시작한다.

보안팀은 trace attribute에 이메일, 토큰, 주문번호 원문이 들어가는지 권한 설계와 함께 점검한다.

실무 시나리오 3: AWS 중심 팀의 CloudWatch 파일럿

AWS 안에서 ECS, Lambda, API Gateway, DynamoDB를 주로 쓰는 팀은 CloudWatch와 X-Ray부터 파일럿하는 편이 빠르다.

IAM, 로그 그룹, metric, alarm, dashboard가 이미 같은 계정 정책 안에 있기 때문이다.

다만 Application Signals 비용은 요청 수와 SLO 수가 커질수록 달라진다.

트래픽이 분당 2만 5,000개 수준인 서비스와 시간당 2,000개 수준인 내부 API는 같은 방식으로 예산을 잡으면 안 된다.

이 경우는 파일럿 전에 request rate, sampling rate, SLO 개수, trace 검색 습관을 수치로 적어야 한다.

도입 전 30일 파일럿 순서

서비스 3~5개를 골라 traffic, error rate, latency, owner, 배포 빈도를 표로 만든다.
공식 가격표 기준으로 host, GB, indexed spans, signals, user 수 중 어떤 단위가 주비용인지 표시한다.
프로덕션만 먼저 계측하고 staging과 development는 기본 제외하거나 낮은 sampling으로 둔다.
trace attribute에서 이메일, 토큰, 세션 ID, 주문 원문 같은 민감정보가 나가는지 배포 전에 점검한다.
첫 2주는 모든 데이터를 보되 상위 noisy service와 endpoint를 매일 기록한다.
3주 차에는 retention filter, sampling, 권한, alert owner를 조정하고 월 예산 예측치를 다시 계산한다.
4주 차에는 실제 장애 또는 모의 장애를 넣어 원인 분석 시간, rollback 결정 시간, 회고 증거 품질을 측정한다.

파일럿 종료 후에는 “대시보드가 보기 좋다”가 아니라 MTTR 단축, 불필요한 alert 감소, 예산 예측 오차, 보안 attribute 제거율로 판단한다.

비용·보안·운영 리스크 체크리스트

리스크	확인 질문	통제 방법	증적
Trace 비용 급증	신규 배포 후 ingest GB와 indexed spans가 얼마나 늘었나	service owner별 budget alert와 sampling rule을 둔다	월간 usage export와 변경 티켓
PII 유출	trace attribute에 이메일, 토큰, 결제 원문이 들어가나	Collector나 SDK에서 민감 attribute를 삭제한다	attribute denylist와 샘플 trace 검수
권한 과다	모든 개발자가 billing과 raw trace를 볼 수 있나	role 기반으로 dashboard viewer와 incident owner를 나눈다	권한 매트릭스와 정기 리뷰
벤더 잠금	agent와 query가 특정 제품 문법에만 묶였나	OpenTelemetry와 표준 semantic convention을 일부 적용한다	계측 표준 문서와 exporter 구성
알림 피로	p95 latency와 error alert가 같은 팀에 중복 발송되나	SLO와 owner 기준으로 alert를 재분류한다	alert audit와 incident review

운영 스켈레톤: APM 예산 기준 YAML

아래 YAML은 특정 제품의 실행 설정이 아니라 예산과 owner를 고정하는 내부 검토 템플릿이다.

공식 가격표에서 확인한 단가와 조직의 실제 사용량을 넣어 월간 예산 회의에 붙인다.

# apm-budget-baseline.yaml
# 목적: APM 솔루션 비용을 host, telemetry, user, alert, retention 기준으로 한 달 전에 예측한다.
# 실제 단가는 공식 가격표, 계약서, 리전, 환율, 사용량 정책을 다시 확인한다.

service_scope:
  owner: sre-platform
  critical_services:
    - checkout-api
    - billing-worker
    - account-web
  environments:
    production: true
    staging: sampled
    development: excluded_by_default

apm_usage_drivers:
  billable_hosts: 42
  fargate_or_serverless_tasks: review_separately
  monthly_ingested_spans_gb: 6200
  monthly_indexed_spans_million: 280
  trace_retention_days:
    default: 15
    incident_services: 30
  full_platform_users: 18
  basic_dashboard_users: 45

cost_guardrails:
  sample_non_critical_endpoints: true
  retain_errors_and_high_latency_first: true
  alert_on_ingest_growth_percent_weekly: 25
  owner_required_for_new_instrumentation: true
  monthly_budget_review_day: 5

stop_conditions:
  - monthly_cost_exceeds_budget_by_20_percent
  - indexed_span_growth_without_incident_reason
  - pii_detected_in_trace_attribute
  - no_owner_for_top_10_noisy_services

계측 스켈레톤: Collector에서 비용과 보안을 먼저 통제한다

OpenTelemetry Collector를 쓰는 팀은 backend 전송 전에 batch, sampling, attribute 삭제 기준을 둬야 한다.

아래 예시는 실제 vendor exporter가 아니라 비용 통제 흐름을 보이기 위한 구성 골격이다.

# otel-collector-cost-control.yaml
# 목적: vendor lock-in을 줄이고, 백엔드 전송 전 sampling·attribute 제한 기준을 둔다.
# 실제 processor 이름과 exporter 설정은 조직의 Collector 버전과 보안 정책에 맞춘다.

receivers:
  otlp:
    protocols:
      grpc: {}
      http: {}

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
  batch:
    timeout: 5s
    send_batch_size: 4096
  attributes/drop_sensitive:
    actions:
      - key: user.email
        action: delete
      - key: request.header.authorization
        action: delete
  tail_sampling:
    decision_wait: 10s
    policies:
      - name: keep-errors
        type: status_code
        status_code:
          status_codes: [ERROR]
      - name: keep-slow-checkout
        type: latency
        latency:
          threshold_ms: 1200
      - name: sample-normal-traffic
        type: probabilistic
        probabilistic:
          sampling_percentage: 5

exporters:
  otlp/apm_backend:
    endpoint: apm-backend.example.internal:4317
    headers:
      api-key: ${APM_BACKEND_API_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, attributes/drop_sensitive, tail_sampling, batch]
      exporters: [otlp/apm_backend]

견적 비교 스크립트: 월 비용과 운영 리스크를 같이 본다

제품별 가격 단위가 다르면 한 줄 월액 비교가 흔들린다.

아래 Python 스켈레톤은 base cost, overage, seat, governance, incident workflow, lock-in risk를 함께 보는 예시다.

#!/usr/bin/env python3
# apm_quote_compare.py
# 목적: APM 견적을 제품명보다 비용 driver와 운영 리스크 기준으로 비교한다.
# 숫자는 예시이며 실제 가격은 공식 가격표와 계약 조건을 반영해 입력한다.

from dataclasses import dataclass

@dataclass
class ApmQuote:
    name: str
    base_monthly_usd: float
    overage_monthly_usd: float
    engineer_seat_monthly_usd: float
    governance_score: int
    incident_workflow_score: int
    lock_in_risk: int

    def decision_score(self) -> float:
        cost_penalty = (self.base_monthly_usd + self.overage_monthly_usd + self.engineer_seat_monthly_usd) / 1000
        return self.governance_score + self.incident_workflow_score - self.lock_in_risk - cost_penalty

quotes = [
    ApmQuote('vendor-host-based', 2100, 430, 0, 18, 17, 7),
    ApmQuote('vendor-usage-based', 900, 780, 360, 16, 14, 5),
    ApmQuote('cloud-native-signals', 1250, 160, 0, 13, 12, 4),
]

for quote in sorted(quotes, key=lambda q: q.decision_score(), reverse=True):
    print(quote.name, round(quote.decision_score(), 1))

구매 전에 vendor에게 물어볼 질문

Billable host나 user 정의가 autoscaling, container, Fargate, serverless에서 어떻게 계산되는가
Trace ingestion과 retention 초과분을 서비스별로 제한하거나 알림으로 막을 수 있는가
OpenTelemetry native ingestion, vendor agent, custom instrumentation을 섞을 때 지원 범위가 어디까지인가
민감 attribute 삭제, 로그와 trace 연결, RBAC, 감사 로그를 어떤 plan에서 제공하는가
계약 중 plan tier를 올리거나 내릴 때 included span, data ingest, user 권한이 어떻게 바뀌는가
장애 회고에 필요한 trace와 log 보존 기간을 15일, 30일, 90일로 바꿀 때 비용이 어떻게 달라지는가