본 게시글은 Introducing OpenTelemetry and PromQL support in Amazon CloudWatch by Rodrigue Koffi를 2026년 7월 정식 출시(GA) 시점의 원문을 번역했습니다.

• 편집자 주(2026년 7월): 이 게시물은 Amazon CloudWatch의 OpenTelemetry 지표 네이티브 수집 및 PromQL 지원 정식 출시(GA), 그리고 새로 추가된 기능과 변경된 가격 정책을 반영하여 업데이트되었습니다.

AWS에서 Kubernetes 또는 마이크로서비스 워크로드를 실행한다면, 지표에는 네임스페이스, 파드, 컨테이너, 노드, 디플로이먼트, 레플리카셋을 비롯해 사용자 지정 비즈니스 차원(dimension) 등 수십 개의 레이블이 포함되어 있을 가능성이 높습니다. 환경의 전체 그림을 파악하기 위해, 지표 파이프라인을 이미 나눠서 운영하고 있을 수도 있습니다. 즉, AWS 지표는 Amazon CloudWatch를 사용하고, 카디널리티가 높은(고유한 레이블 조합이 많은) 컨테이너 및 애플리케이션 지표는 별도의 Prometheus 호환 백엔드를 사용하는 것입니다. 일부 팀들은 한 걸음 더 나아가기도 합니다. 이러한 팀은 Prometheus CloudWatch exporter를 사용하여 GetMetricData API 호출을 통해 AWS 리소스 지표를 Prometheus 백엔드로 가져옵니다. 이 방식은 운영 부담과 비용을 늘리는 대신, 모든 지표를 한곳에서 쿼리할 수 있게 해 줍니다.

Amazon CloudWatch는 이제 OpenTelemetry 지표를 기본적으로 수집하고, Prometheus Query Language(PromQL)를 지원합니다. 이 기능은 지표당 최대 150개의 레이블을 지원하는 높은 카디널리티 지표 저장소를 도입하여, 레이블이 많이 붙은 풍부한 지표를 변환이나 잘림 없이 CloudWatch로 직접 전송할 수 있습니다. AWS에서 제공하는 지표를 자동으로 보강하는 기능과 결합되어, CloudWatch는 인프라, 컨테이너, 애플리케이션 지표를 아우르는 단일 대상이 되며, 이 모두를 PromQL로 쿼리할 수 있습니다.

이 게시물에서는 다음 방법을 알아봅니다.

• 계정에서 OpenTelemetry 지표 수집 및 자동 AWS 리소스 보강 활성화
• Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터에 Amazon CloudWatch Container Insights 배포
• Amazon CloudWatch 및 Amazon Managed Grafana에서 PromQL을 사용하여 인프라 및 AWS 리소스 지표 쿼리
• OpenTelemetry SDK로 Amazon CloudWatch에서 사용자 지정 애플리케이션 지표를 생성하고, 해당 지표가 AWS 컨텍스트로 자동 보강되는 것을 직접 확인

또한, 이 게시물의 실습에서 직접 다루지는 않지만, CloudWatch 네이티브 OpenTelemetry 지원은 다음과 같은 추가 기능과 함께 정식 출시되었습니다.

• 텔레메트리 파이프라인(Telemetry Pipelines): 지표를 저장하기 전에 라우팅·필터링·변환하는 서버 측 파이프라인
• 교차 계정 중앙 집중화: 여러 AWS 계정의 OTLP 지표를 단일 모니터링 계정으로 집계
• GPU 및 EFA 모니터링을 지원하는 EKS Container Insights: NVIDIA DCGM, AWS Neuron Monitor, Elastic Fabric Adapter(EFA) 지표를 기본으로 제공
• Bearer 토큰 인증: Bearer 토큰으로 OTLP 수집을 인증하여, IAM 자격 증명이 없는 환경에서도 지표를 전송

Amazon CloudWatch에서 OpenTelemetry 지원이 의미하는 것

OpenTelemetry Protocol(OTLP)은 OpenTelemetry(OTel) 프로젝트의 표준 와이어 프로토콜입니다. OTLP는 지표, 트레이스, 로그를 포함한 텔레메트리 데이터가 컴포넌트 간에 어떻게 인코딩되고 전송되는지를 정의합니다. 이제 CloudWatch는 리전별 OTLP 엔드포인트를 제공하며, OpenTelemetry 호환 Collector나 SDK가 이 엔드포인트로 지표를 전송할 수 있습니다.

CloudWatch는 지표를 수신하여, 카운터, 히스토그램, 게이지, 업다운 카운터를 포함한 OpenTelemetry 지표 유형을 변환 없이 유지하면서 새로운 높은 카디널리티 지표 저장소에 저장합니다. 이번 출시로 CloudWatch는 관측 가능성의 세 가지 기둥 전반에 걸쳐 OpenTelemetry 지원을 완성했습니다. CloudWatch는 이미 OTLP 엔드포인트를 통한 트레이스와 로그 수집을 지원하고 있었습니다. 여기에 네이티브 OTLP 지표 수집까지 더해지면서, 이제 모든 텔레메트리를 개방형 표준에 따라 단일 프로토콜로 CloudWatch에 전송할 수 있습니다.

이를 의미 있게 만드는 세 가지 기능은 다음과 같습니다:

확장된 레이블 및 카디널리티 지원. OTLP로 수집된 지표는 최대 150개의 레이블을 지원하며, 이는 기존 CloudWatch 사용자 지정 지표의 30개 차원 제한과 대비됩니다. 이를 통해 필터링과 집계를 위해 카디널리티가 높은 레이블에 의존하는 Kubernetes, 마이크로서비스, OpenTelemetry 워크로드에서 핵심적인 제약이 사라집니다. 이러한 제한은 계속 변경될 수 있으므로, 할당량 페이지에서 최신 정보를 확인하시기 바랍니다.

PromQL 쿼리 지원. OTLP를 통해 수집된 지표를 PromQL로 쿼리할 수 있습니다. 이미 Prometheus를 사용 중이라면, 새로운 문법을 익힐 필요 없이 CloudWatch와 Amazon Managed Grafana에서 동일한 쿼리 언어를 그대로 사용할 수 있습니다.

자동 AWS 리소스 보강. 이 기능은 AWS 인프라 전반에서 지표를 쿼리하고 필터링하는 방식을 근본적으로 바꿉니다. CloudWatch는 수집되는 모든 지표를 AWS 리소스 컨텍스트로 보강합니다. 즉, 계정 ID, 리전, 클러스터 ARN(Amazon Resource Name), 그리고 AWS Resource Explorer의 리소스 태그가 추가됩니다. 이 보강은 추가 계측 없이 자동으로 이루어집니다. Container Insights, 사용자 지정 애플리케이션, AWS 서비스 중 어디에서 온 지표든 AWS 계정, 리전, 환경 태그, 애플리케이션 이름을 기준으로 필터링하고 그룹화할 수 있습니다. exporter도, 사용자 지정 레이블도, 추가 API 호출도 필요 없습니다. 정식 출시와 함께 CloudWatch는 텔레메트리 파이프라인도 제공합니다. 이는 지표를 저장하기 전에 라우팅·필터링·변환할 수 있는 서버 측 처리 기능으로, 여러 계정에 걸친 중앙 집중식 관측 가능성 아키텍처를 구현할 수 있게 해줍니다.

그림 1: Amazon CloudWatch의 OpenTelemetry 지표 수집 및 보강 아키텍처.

OTLP 수집 및 AWS 리소스 보강 활성화하기

OTLP 지표를 수집하고 쿼리하려면, 먼저 계정 수준 설정 두 가지를 활성화해야 합니다. 첫 번째는 AWS 리소스에서 텔레메트리로 리소스 태그를 전파하는 설정으로, 여기서 전파되는 태그는 AWS Resource Explorer에서 확인할 수 있는 것과 동일한 태그입니다. 두 번째는 CloudWatch의 OTLP 수집을 활성화하는 설정입니다.

이 두 가지 보강 설정은 Amazon CloudWatch 콘솔이나 AWS CLI에서 활성화할 수 있습니다.

CloudWatch 콘솔에서 보강을 활성화하려면 다음 단계를 따릅니다.

1. Amazon CloudWatch 콘솔을 엽니다.
2. 탐색 창에서 설정 (Settings)을 선택합니다.
3. 텔레메트리의 리소스 태그(Resource tags for telemetry)를 활성화합니다.
4. AWS 지표에 대한 OTel 보강(OTel enrichment)을 활성화합니다.

두 설정을 모두 활성화하면, 리전 엔드포인트에서 OTLP 지표를 수집할 준비가 완료됩니다.

그림 2: CloudWatch 콘솔 설정에서 OTel 보강 및 리소스 태그 활성화

또는 AWS CLI로 두 가지 보강 설정을 모두 활성화할 수 있습니다. 다음 명령어를 실행합니다.

# Enable resource tags on telemetry 
aws observabilityadmin start-telemetry-enrichment 
# Enable OTel enrichment for CloudWatch 
aws cloudwatch start-otel-enrichment

두 보강 설정이 모두 활성화되었는지 확인하려면, 다음 명령어를 실행합니다.

aws observabilityadmin get-telemetry-enrichment-status
aws cloudwatch get-otel-enrichment

보강이 활성화되면, OTLP 엔드포인트를 통해 수집되는 모든 지표에 AWS 리소스 컨텍스트가 자동으로 태그로 추가됩니다. 다음 표는 CloudWatch가 추가하는 속성을 보여줍니다. 

이 속성들은 CloudWatch가 추가하며, 수동 계측이 필요하지 않습니다. 이를 통해 사용자 지정 파이프라인을 구축하거나 exporter를 운영하지 않고도 여러 AWS 계정, 리전, 리소스 태그에 걸쳐 쿼리할 수 있습니다.

OpenTelemetry 지표를 활용한 Amazon CloudWatch Container Insights

CloudWatch에서 OpenTelemetry가 실제로 작동하는 모습을 보기 위해, Container Insights부터 시작해 보겠습니다. Amazon EKS용 Amazon CloudWatch Container Insights는 이제 Prometheus와 OpenTelemetry 지표를 지원합니다. 이를 통해 컨테이너 지표가 OpenTelemetry 속성으로 표준화되고, PromQL로 쿼리할 수 있게 됩니다. 콘솔이나 AWS CLI에서 Amazon EKS 애드온을 사용하여 Container Insights를 활성화할 수 있습니다.

Container Insights가 배포되면, CloudWatch는 CPU 사용률, 메모리 사용량 및 파드 수 등 클러스터 단위 지표를 보여주는 대시보드를 자동으로 생성합니다. 이 대시보드를 보려면 CloudWatch 콘솔을 열고, 탐색 창에서 Container Insights를 선택한 다음, 드롭다운에서 클러스터를 선택합니다. 클러스터, 네임스페이스, 파드 단위 뷰를 전환하여 특정 워크로드를 자세히 살펴볼 수 있습니다.

그림 3: Amazon CloudWatch Container Insights 대시보드

CloudWatch Query Studio에서 PromQL로 지표 쿼리하기

CloudWatch 콘솔, Amazon Managed Grafana, 또는 PromQL과 AWS Signature Version 4(SigV4)를 지원하는 쿼리 인터페이스에서 PromQL로 OTLP 수집 지표를 쿼리할 수 있습니다. CloudWatch Query Studio는 콘솔에서 바로 이러한 지표를 탐색하고 시각화할 수 있는 내장 PromQL 편집기를 제공합니다. 시작하려면 PromQL 쿼리 모드를 선택합니다.

그림 4: PromQL 쿼리 모드를 사용하는 Amazon CloudWatch Query Studio 인터페이스

보강이 활성화되어 있으므로, CloudWatch가 자동으로 추가하는 태그를 사용하여 AWS 리소스 경계를 넘어 쿼리할 수 있습니다. exporter도, 사용자 지정 레이블도 필요 없습니다.

# AWS Lambda function duration for functions tagged with application "order-pipeline" 
Duration{"@aws.tag.appname"="order-pipeline"} 

# Amazon EC2 CPU utilization for production delivery workloads 
CPUUtilization{"@aws.tag.Environment"="production", "@aws.tag.Application"="delivery"} 

# Running pods grouped by AWS account and namespace 
sum by (aws_account_id, k8s_namespace_name) (kube_pod_status_phase{phase="Running"})

마지막 쿼리는 별도의 사용자 지정 계측 없이 AWS 계정과 Kubernetes 네임스페이스별로 그룹화한 실행 중인 파드 수를 반환합니다. aws_account_id 레이블은 보강 계층에서 자동으로 추가됩니다.

그림 5: Lambda 실행 시간 지표를 쿼리하는 CloudWatch Query Studio 화면

Grafana에서 PromQL로 지표 쿼리하기

Amazon Managed Grafana에서 OTLP 수집 지표를 시각화하려면, CloudWatch PromQL 엔드포인트를 가리키는 Prometheus 데이터 소스를 추가합니다. 이 섹션에서는 SigV4 인증으로 데이터 소스를 구성하는 과정을 안내합니다.

Prometheus 데이터 소스의 SigV4 인증에는 Amazon Managed Service for Prometheus 플러그인 3.0.0 이상이 필요합니다. 이 플러그인 버전이 포함된 Amazon Managed Grafana v12 사용을 권장합니다. 오픈 소스 Grafana에서는  Amazon Managed Service for Prometheus 플러그인 3.0.0 이상을 지원하는 버전에서 이 기능을 사용할 수 있습니다.

1. Amazon Managed Grafana 워크스페이스를 엽니다.
2. Data Sources를 선택합니다.
3. Add data source를 선택합니다.
4. 데이터 소스 유형으로 Prometheus를 선택합니다.
5. URL에는 사용 중인 리전의 CloudWatch PromQL 엔드포인트를 입력합니다: https://monitoring.<AWS Region>.amazonaws.com
6. Authentication에서 SigV4를 선택합니다.
7. SigV4 인증을 위한 적절한 IAM 역할을 구성합니다.
8. 연결을 확인하려면 Save & Test를 선택합니다.

또는, 외부 CI/CD 시스템이나 AWS 외부 컴퓨팅처럼 SigV4를 사용하기 어려운 환경에서는 Bearer 토큰으로 인증할 수 있습니다. CloudWatch OTLP 엔드포인트의 Bearer 토큰 인증에 대한 자세한 내용은 Analyzing Claude Code usage with CloudWatch and OpenTelemetry를 참조하시기 바랍니다.

Save & Test가 성공하면 “Data source is working” 확인 메시지가 표시됩니다. 실패하는 경우, IAM 역할에 cloudwatch:GetMetricData 및 cloudwatch:ListMetrics 권한이 있는지, 그리고 SigV4 서명이 올바르게 구성되어 있는지 확인합니다.

데이터 소스를 구성한 후에는 Grafana 대시보드에서 동일한 PromQL 쿼리를 사용할 수 있습니다.

그림 6: CloudWatch PromQL을 사용하는 Grafana Explore

사용자 지정 애플리케이션 지표

CloudWatch OTLP 수집은 사용자 지정 애플리케이션 지표도 지원합니다. OpenTelemetry SDK로 계측된 애플리케이션은 계측 코드를 수정할 필요 없이, 클러스터에서 실행 중인 CloudWatch 에이전트를 통해 지표를 전송할 수 있습니다.

이를 실제로 확인하기 위해, aws-otel-community 리포지토리의 예제 Python 애플리케이션을 배포합니다. 이 애플리케이션은 OpenTelemetry Python SDK를 사용하여 카운터, 히스토그램, 게이지, 업다운 카운터 등 모든 OTel 지표 유형을 다루는 사용자 지정 지표를 전송합니다. 예를 들어, 이 애플리케이션은 API 응답 시간을 측정하는 latency_time 히스토그램을 정의합니다.

from opentelemetry import metrics 
meter = metrics.get_meter(__name__) 

# Histogram --- measures API latency distribution 
latency_time = meter.create_histogram( 
  name="latency_time",
  description="Measures latency time",
  unit="ms",
)

예제 애플리케이션 배포하기

GitHub의 aws-otel-community 리포지토리에서 예제 애플리케이션과 모든 배포 매니페스트를 확인할 수 있습니다. 앞서 배포한 Container Insights 애드온에는 OpenTelemetry collector 역할을 하는 CloudWatch 에이전트가 포함되어 있습니다. 예제 앱이 이 에이전트를 가리키도록 OTEL_EXPORTER_OTLP_ENDPOINT 환경 변수를 http://cloudwatch-agent.amazon-cloudwatch.svc.cluster.local:4317로 설정합니다.

이 실습에서는 CloudWatch 에이전트를 사용하지만, OTLP/HTTP를 지원하는 OpenTelemetry 호환 collector나 SDK를 사용하여 CloudWatch OTLP 엔드포인트로 지표를 직접 전송할 수도 있습니다.

PromQL로 애플리케이션 지표 쿼리하기

애플리케이션을 배포한 후, CloudWatch Query Studio를 열거나 Amazon Managed Grafana 워크스페이스에서 Explore로 이동한 다음, CloudWatch PromQL 데이터 소스를 선택합니다.

다음 쿼리는 Amazon Managed Grafana에서 예제 애플리케이션의 p99 레이턴시를 보여주며, 자동으로 보강된 @aws.region 레이블을 기준으로 그룹화합니다:

histogram_quantile(0.99, sum by (le, aws_region) (rate(latency_time_bucket{resource_service_name="python-demo-app"}[5m])))


보강이 활성화되어 있으므로, 모든 애플리케이션 지표는 자동으로 AWS 리소스 컨텍스트로 보강됩니다. 예를 들어, 추가 계측 없이도 cpu_usage 레이블을 반환합니다.

요금

OTLP 엔드포인트를 통해 수집된 OpenTelemetry 지표는 수집된 GB당 정액 요금으로 과금되며, 여기에는 15개월간의 저장 비용이 포함됩니다. API 호출이나 고유 지표 시계열(time series)의 개수에 대한 별도 요금은 없습니다. PromQL 쿼리는 스캔된 100만 샘플당 과금됩니다. 최신 요금 정보는 Amazon CloudWatch 요금 페이지를 참고하시기 바랍니다.

이번 실습에서 사용된 Amazon EKS 및 Amazon Managed Grafana 리소스는 표준 요금으로 과금됩니다. 비용이 계속 청구되지 않도록, 실습을 마친 후 다음 섹션의 정리 단계에 따라 리소스를 정리하시기 바랍니다.

리소스 정리

• 예제 애플리케이션을 삭제합니다.

  kubectl delete -f demo-app.yaml

• EKS 클러스터에서 Amazon CloudWatch Observability 애드온을 제거합니다.

  aws eks delete-addon \
   --cluster-name \
   --addon-name amazon-cloudwatch-observability
  

  Grafana 워크스페이스에서 Prometheus 데이터 소스를 제거합니다. (Grafana 콘솔에 로그인한 후 Data Sources로 이동하여, 이전에 구성한 CloudWatch PromQL 데이터 소스를 삭제합니다.)

• Amazon Managed Grafana 워크스페이스를 삭제합니다. (이 실습을 위해 생성한 경우에만)

  aws grafana delete-workspace --workspace-id

• Amazon EKS 클러스터를 삭제합니다. (이 실습을 위해 생성한 경우에만)

  aws eks delete-cluster --name

• OTel 보강을 비활성화합니다. (계정에서 더 이상 필요하지 않은 경우)

  # Disable OTel enrichment 
  aws cloudwatch stop-otel-enrichment 
  
  # Disable telemetry enrichment 
  aws observabilityadmin stop-telemetry-enrichment

• IAM 정책을 분리합니다. (이 실습을 위해 특별히 연결한 정책인 경우)

  aws iam detach-role-policy \
    --role-name \
    --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

결론

이 글에서는 Amazon CloudWatch의 네이티브 OpenTelemetry 지표 수집을 살펴보았습니다. 보강 계층을 활성화하고, Amazon EKS에 Container Insights를 배포하고, OpenTelemetry SDK로 사용자 지정 애플리케이션 지표를 전송하고, PromQL로 모든 지표를 쿼리했습니다.

이제 정식 출시된 이 기능을 통해 지표 파이프라인을 Amazon CloudWatch로 통합할 수 있습니다. 더 많은 레이블을 지원하는 카디널리티가 높은 지표, PromQL 쿼리, 자동 AWS 리소스 보강이 함께 작동하여, 인프라 지표, 컨테이너 지표, 애플리케이션 지표가 모두 동일한 파이프라인으로 흐르고 동일한 AWS 리소스 컨텍스트를 갖습니다. 별도의 백엔드도, exporter도, 추가 API 호출도 없이 AWS 지표를 통합된 뷰로 확인할 수 있습니다.

OpenTelemetry를 사용한 애플리케이션 수준 계측에 대한 더 많은 실습 예제는 다음 리소스를 참고하시기 바랍니다.

• AWS Observability Best Practices Guide: OpenTelemetry SDK로 애플리케이션을 계측하는 패턴
• One Observability Workshop: AWS에서 지표, 트레이스 및 로그를 위한 실습 랩
• AWS Observability Accelerator: 텔레메트리 수집과 쿼리를 자동화하는 CDK 패턴 및 Terraform 모듈

CloudWatch의 네이티브 OpenTelemetry 지표 수집과 PromQL 지원이 이제 정식 출시되었습니다. 시작하려면, 계정에서 보강 계층을 활성화하고 Amazon EKS 클러스터에 CloudWatch Observability 애드온을 배포합니다. 리전별 가용성은 Amazon CloudWatch 설명서를 참조하시기 바랍니다.