クラウドネイティブなシステムの運用において、オブザーバビリティはもはや後付けの考慮事項ではなく、設計の中核に位置するものとなっています。しかし現実には、Kubernetes クラスタのメトリクスは Prometheus で、AWS リソースのメトリクスは CloudWatch で、それぞれ別々に管理しているという現場が少なくありません。このような状況では、障害発生時に複数のツールを行き来しながら原因を追う必要があり、オペレーターの認知負荷を高めてしまいます。
2026年4月、Amazon CloudWatch がこの課題に対して大きな一手を打ちました。OpenTelemetry Protocol（OTLP）によるメトリクスのネイティブ取り込みと、PromQL によるクエリをパブリックプレビューとしてサポートしたのです。これにより、OTel ベースのメトリクスパイプラインをそのまま CloudWatch に接続し、Prometheus ユーザーが慣れ親しんだクエリ言語で AWS のオブザーバビリティを活用できるようになります。本記事では、この新機能の技術的な背景と実際のメリットを詳しく解説します。
モニタリングの課題とOpenTelemetryが解決しようとしていること
現代のシステムは、マイクロサービス、コンテナ、サーバーレス、さらにはオンプレミスの要素が混在する複雑な構成を持っています。それぞれのコンポーネントがテレメトリを出力する方法もバラバラであることが多く、ログはここに、トレースはあそこに、メトリクスはまた別のシステムに——という状態が当たり前になっています。
OpenTelemetry（OTel）は、この断片化した状況に対してベンダー中立な統一フレームワークを提供するプロジェクトです。CNCF（Cloud Native Computing Foundation）のもとで開発が進められており、メトリクス・ログ・トレースという三つの柱を統一的な仕様で収集・送信できることを目指しています。OpenTelemetry が普及することで、アプリケーション側は一度 OTel SDK でインストルメンテーションを行えば、バックエンドのモニタリングシステムを変更しても収集コードを書き直す必要がなくなります。
ただし、これまで CloudWatch と OTel を組み合わせて使う場合には、OTLP で収集したメトリクスを一旦 CloudWatch Metric の形式に変換するための追加コンポーネントが必要でした。この変換処理は、OTel が持つリッチなラベル情報が CloudWatch の 30 ディメンション上限に収まりきらないという問題も抱えていました。今回のアップデートはこの状況を根本から変えるものです。
CloudWatchがOTLPエンドポイントを公開した意味
今回のアップデートの核心は、CloudWatch がリージョナルな OTLP エンドポイントを直接公開したことにあります。これにより、OpenTelemetry Collector や OTel SDK を使ったアプリケーションは、エンドポイントの向き先を CloudWatch の OTLP エンドポイントに変更するだけで、メトリクスを直接 CloudWatch に送信できるようになります。
従来は、OTel Collector から CloudWatch にデータを送るために、AWS Distro for OpenTelemetry（ADOT）のような追加レイヤーや、CloudWatch Exporter の設定が必要でした。さらに、OTel の持つメトリクスタイプをそのまま CloudWatch に保持することが難しく、カスタムメトリクスとして送信する際に情報が失われることもありました。
OTLP ネイティブ取り込みでは、Counter、Histogram、Gauge、UpDownCounter という OTel の主要なメトリクスタイプが変換なしに CloudWatch 内に保持されます。Histogram はパーセンタイル計算が可能な形式のままストアされますし、Counter の累積値も OTel の仕様通りに扱われます。既存の OTel パイプラインが持つセマンティクスを CloudWatch が理解してくれるようになった、というのがこのアップデートの本質的な意味です。
すでに Kubernetes クラスタで OTel Collector を動かしている場合、設定ファイルの exporter セクションを書き換えるだけで CloudWatch への送信を開始できます。新しいエージェントのデプロイも、独自の変換ロジックの実装も不要です。
高カーディナリティメトリクスストアで150ラベルに対応
OTel ネイティブ取り込みと同時に、CloudWatch には新しい「高カーディナリティメトリクスストア」が導入されました。このストアは 1 メトリクスあたり最大 150 ラベルをサポートしており、従来の CloudWatch カスタムメトリクスの 30 ディメンション制限を大幅に超えるものです。
なぜ 150 ラベルへの対応が重要なのでしょうか。Kubernetes 上で動くマイクロサービスのメトリクスを考えてみてください。一つの HTTP リクエストに関するメトリクスには、クラスタ名、ノード名、名前空間、Pod 名、コンテナ名、サービス名、メソッド名、ステータスコード、ターゲットホスト、デプロイバージョン……と、優に 20 を超えるラベルが付与されることが珍しくありません。これらの全てのラベルを保持したままメトリクスを格納できることで、後から任意の軸で集計・分析する柔軟性が生まれます。
特定の Pod や名前空間だけのレイテンシを見たい、特定のサービスバージョン同士を比較したい、障害発生時に問題のあるコンテナを特定したい——こういった分析要求に対して、ラベルを削ることなくデータを蓄積できることの価値は非常に大きいです。これまで「CloudWatch にはそのまま送れないから Prometheus を維持し続けなければ」と判断していたチームにとっても、選択肢が広がります。
PromQLがCloudWatchで使えるようになった実際のメリット
OTLP ネイティブ取り込みと高カーディナリティストアに続く三つ目の要素が、PromQL サポートです。OTLP 経由で取り込んだメトリクスに対して、CloudWatch コンソールおよび Amazon Managed Grafana から直接 PromQL クエリを実行できるようになりました。
Prometheus Query Language（PromQL）は、時系列メトリクスの検索・集計・演算のための表現力豊かなクエリ言語です。例えば、HTTP リクエスト数の 5 分あたりの増加率を求める式や、99 パーセンタイルレイテンシをサービスごとに集計する式など、複雑な時系列計算を簡潔に記述できます。Kubernetes の運用に携わるエンジニアの多くが、この言語に慣れ親しんでいます。
CloudWatch で PromQL が使えることの最大のメリットは、Prometheus から CloudWatch に移行する際の学習コストがほぼゼロになることです。既存のダッシュボード定義や、アラートのクエリ式を、そのまま CloudWatch 上で動かすことができます。「移行はしたいが、チームが書き溜めた PromQL 資産を捨てたくない」という声はよく聞かれますが、今回のアップデートはまさにその課題に応えるものです。
さらに重要なのが、70 以上の AWS マネージドサービスが出力するネイティブメトリクスと、OTel 経由で取り込んだカスタムメトリクスを、同じ PromQL で統合的にクエリできる点です。例えば、Lambda のスロットリングエラー数（AWS ネイティブメトリクス）とアプリケーション側が計測したリクエスト処理時間（OTel カスタムメトリクス）を一つのグラフに並べたり、相関を計算したりすることが可能になります。これは、CloudWatch を「AWS のみのモニタリングツール」から「OTel 対応のユニファイドオブザーバビリティプラットフォーム」へと変貌させる変化です。
実際の利用開始方法とパブリックプレビューの概要
本機能は 2026 年 4 月時点でパブリックプレビューとして公開されています。利用可能なリージョンは、米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（シドニー）、アジアパシフィック（シンガポール）、欧州（アイルランド）の 5 リージョンです。
利用を開始するには、まず CloudWatch コンソールから OTLP エンドポイントの URL を取得します。次に、既存の OTel Collector の設定ファイルで、exporter の設定を CloudWatch の OTLP エンドポイントを向くように変更します。認証には AWS の SigV4 署名が使われるため、Collector を動かす環境に適切な IAM 権限を付与することが必要です。Kubernetes 環境であれば、IRSA（IAM Roles for Service Accounts）を使ってサービスアカウントに権限を紐付けるのが一般的な方法です。
CloudWatch コンソールでは、OTLP 経由で取り込んだメトリクスを「CloudWatch Metrics Insights」や新しい「PromQL クエリ」インターフェースから参照できます。Amazon Managed Grafana を使っている場合は、CloudWatch をデータソースとして設定することで、Grafana ダッシュボードから PromQL クエリを実行できます。
同時期に発表された「CloudWatch OTel Container Insights for Amazon EKS」（プレビュー）も要注目です。こちらは EKS 上で動く Kubernetes ワークロードのメトリクスを、OTel ベースで収集する専用の機能です。Pod、コンテナ、ノードレベルのメトリクスを OTel 形式で CloudWatch に送信し、高カーディナリティストアで管理できます。EKS ユーザーにとっては、アプリケーションメトリクスとインフラメトリクスを一つの CloudWatch テナントで統合管理する道が開けてきます。
Amazon CloudWatch の OTel ネイティブ取り込みと PromQL サポートは、クラウドネイティブなオブザーバビリティの実践において重要な選択肢を提供するものです。Prometheus や OTel エコシステムへの既存投資を活かしつつ、AWS のマネージドサービスと統合されたモニタリング基盤を構築したいと考えているエンジニアチームにとって、試してみる価値のあるプレビューです。GA に向けてさらに機能が充実することにも期待が高まります。
