guide 2026/6/17

CloudWatchがOpenTelemetryメトリクスにネイティブ対応 — PromQL資産を活かす移行とGB単位課金の損得

Amazon CloudWatchがOpenTelemetry(OTLP)メトリクスにネイティブ対応し、PromQLでのクエリにも対応しました。Prometheus/Grafana資産を捨てずに取り込み先をCloudWatchへ寄せる移行判断と、取込み$0.50/GB＋PromQLクエリ課金というGB単位のコスト設計を、AWSフリーランス実務目線で整理します。GAやAMPとの棲み分けは公式の最新情報もご確認ください。

#CloudWatch
#OpenTelemetry
#PromQL
#可観測性
#コスト最適化
#Prometheus

Prometheus と Grafana に OpenTelemetry を組み合わせて可観測性（システムの状態を計測・観察できるようにすること）を回している方は多いと思います。一方で、AMP や自前 Prometheus の運用費・運用負荷が悩みの種、という相談もよく受けます。せっかく育てた PromQL のクエリ資産や Grafana のダッシュボードは捨てたくない、でもコストと運用はもう少し楽にしたい——そんな場面に効きそうな発表が 2026年6月16日にありました。Amazon CloudWatch が OpenTelemetry のメトリクスをネイティブに取り込み、PromQL でクエリできるようになった、というものです。

この記事では、何ができるようになったのかを噛み砕いたうえで、本題として「取り込み先を CloudWatch へ寄せるべきか」を、移行の進め方（デュアルライト4フェーズ）と GB 単位課金のコスト設計の両面から、自分の環境に当てはめて判断できるところまで整理してみましょう。新機能の紹介で終わらせず、「寄せるべきか・いくらかかるか」を考える材料にしてもらえればと思います。煽らず、断定できないところは正直に「公式をご確認ください」と書きます。

背景：いま可観測性で起きていること

まず用語を一言ずつ。OpenTelemetry（OTel） はベンダーに依存しない計測（テレメトリ収集）の標準仕様で、アプリにメトリクスやトレースを仕込むための共通の作法です。OTLP はその OpenTelemetry がデータを送るときのプロトコル（通信規約）を指します。PromQL は Prometheus というOSSの監視ツールが備えるクエリ言語で、可観測性の現場で事実上の標準になっています。

これまで多くの現場は、「アプリを計装 → Prometheus や AMP（Amazon Managed Service for Prometheus）で保存・クエリ → Grafana で可視化」という系統と、「CloudWatch（独自のメトリクスと課金体系）」という系統の、二つを併存させてきました。結果として、保存先が分かれ、運用の手間とコストがじわじわ膨らむ、という課題がありました。今回の発表は、CloudWatch が「OTLP の送信先」かつ「PromQL のクエリ基盤」になることで、既存のツール資産を温存したまま保存先を寄せる選択肢を増やすものだ、と位置づけられます。

何ができるようになったか — OTLP取込みとPromQLクエリ

ポイントは大きく三つです。

ひとつ目は OTLP のネイティブ取込みです。送信先は https://monitoring.{region}.amazonaws.com/v1/metrics というエンドポイントで、認証は AWS の標準である SigV4 署名（リクエストに署名して本人確認する仕組み）を使い、署名対象のサービス名は monitoring です。送信側は OTel SDK、OTel Collector（otlphttp exporter と sigv4auth extension の組み合わせ）、あるいは任意の OTLP 互換クライアントが使えます。送信に必要な IAM 権限は cloudwatch:PutMetricData です。対応するメトリクス型は Counter、Gauge、Histogram の三つです。

ふたつ目は PromQL でのクエリです。Prometheus 3.0 仕様に準拠し、リソース属性や AWS 固有のメタデータをクエリ可能な PromQL ラベルとして保持します（1データポイントあたり最大150ラベル）。Prometheus 互換の API パス（/api/v1/query など）が用意され、実行には cloudwatch:GetMetricData と cloudwatch:ListMetrics が必要です。

みっつ目は、アプリのカスタムメトリクスと、AWS サービス側のメトリクス（70以上のサービス）をひとつのクエリ基盤で見られることです。

なお、この機能は2026年4月2日に公開プレビューが始まり、6月16日の発表では「ネイティブに対応した（now natively supports）」と表現されています。ただし、発表ページに「GA（一般提供）」という明示の文言はありません。料金ページに金額が掲載されている点から実質的に課金が始まっていると読めますが、GA かどうかの線引きは断定せず、利用前に公式の最新情報をご確認ください。

コスト設計 — GB単位課金の仕組みと落とし穴

ここがひとつ目の本題です。従来の Classic カスタムメトリクスは「メトリクス数（カーディナリティ）課金」でしたが、今回の OTel 取込みは「取込み GB 課金」です。コストを管理する軸そのものが変わる、というのが要点です。

OTel取込みのGB単位課金とClassicのメトリクス数課金を左右に並べた対比図。OTel取込みは取り込んだGBが課金軸で取込み0.50ドル/GB（15ヶ月保存込み）、メトリクス数・シリーズ数・APIへの個別課金はなく、コストドライバはexport間隔・属性数・総GB。Classicはメトリクス数が課金軸で段階課金とPutMetricData APIの料金がかかる。料金は公式の最新ページで確認する旨の注記つき。 — 図1: OTel取込み（GB課金）とClassic（メトリクス数課金）の課金軸の違い。料金は2026年6月時点の参考値

具体的には、OTel 取込みは $0.50/GBで、これに15ヶ月分の保存が含まれます。メトリクス数・保存・シリーズ数への個別課金はありません。PromQL クエリは $0.01/100万スキャンサンプルで、コンソール（Query Studio）やダッシュボード経由のクエリは無料です。比較のため、従来の Classic は段階課金（最初の1万メトリクスで $0.30、以降 $0.10、$0.05）に加えて PutMetricData の API 料金がかかる体系でした。

課金の軸	OTel取込み（今回）	Classic（従来）
何で課金されるか	取り込んだGB	メトリクス数（カーディナリティ）
参考料金	取込み $0.50/GB（15ヶ月保存込み）	$0.30→$0.10→$0.05 の段階課金＋API料金
主なコストドライバ	export間隔・1点あたり属性数・総GB	ユニークなメトリクス本数
クエリ課金	$0.01/100万スキャンサンプル（コンソールは無料）	取得API等に準拠

取込み量は「CloudWatch が受信した OTLP ペイロードの非圧縮サイズ」で測られます。1データポイントの目安は属性10〜15個でおおむね300〜600バイトとされますが、これは公式も「typical（目安）」と書いている幅のある値です。試算するときは幅を持たせ、「export 間隔を◯秒・属性を◯個と仮定すると」という条件付きで考えるのが安全です。傾向としては、高カーディナリティ・多シリーズの環境は GB 課金が有利に働きやすい一方、属性の盛りすぎや高頻度の export は取込み GB を押し上げます。なお金額は2026年6月時点の参考値です。「最安」や「◯%削減」といった断定はできませんので、必ずCloudWatchの公式料金ページで最新の値をご確認ください。

使うときの判断 — 寄せるべきか・移行の進め方

ふたつ目の、そして記事のいちばんの本題です。Classic（PutMetricData / EMF）から OTel への移行は、一斉切替（flag day）ではなく、ワークロード単位の段階移行で進められます。基本は次の4フェーズです。

Classicから OTel へのデュアルライト4フェーズを左から右への横フローで示した図。①デュアルライト（ClassicとOTelの両方へ送り並走）→②検証（Query StudioでPromQLを実行し値が揃うか確認）→③コンシューマ再作成（アラームとダッシュボードをPromQLベースに作り直す）→④切替（Classic側の送信を停止し該当分の課金も止める）。 — 図2: Classicから OTel への段階移行（デュアルライト4フェーズ）

順に、(1) デュアルライト＝Classic と OTel の両方へメトリクスを送り、止めずに並走させる、(2) 検証＝Query Studio で PromQL を実行して値が揃うか確認する、(3) コンシューマ再作成＝アラームとダッシュボードを PromQL ベースに作り直す（アラームは put-metric-alarm の --metrics に PromQL 式を指定できます）、(4) 切替＝Classic 側の送信を止める、という流れです。停止すればその分の課金も止まります。EC2 の CPU や RDS の接続数といった AWS 側が出すメトリクス（vended メトリクス）は手動移行が不要で、「OTel Vended Metric Enrichment」を有効にすればコード変更なしで PromQL からクエリできます。

向き不向きも整理しておきましょう。

	内容
向きやすい	Prometheus/Grafana 資産を活かしたい／可観測性のコストを一元化したい／70以上のサービスメトリクスを1基盤で見たい
慎重に検討	AMPやremote_write前提のパイプラインがある／高頻度・大規模クエリでPromQL制限に当たりそう／Grafana側の設定を新たに整える必要がある

PromQL には実務で効く制限があります。設計時に頭に入れておきましょう。

項目	値（2026年6月時点の参考値）
1クエリの最大返却シリーズ数	500（超過分は切り詰め）
1リクエストの最大時間範囲	7日
24時間あたりスキャン可能サンプル数	3億
同時実行クエリ数（アカウント）	30
クエリ実行タイムアウト	20秒

最後に、誠実にお伝えしておきたい点です。AMP との公式な棲み分け、Prometheus の remote_write 互換の可否、Grafana の SigV4 データソース設定の具体手順は、現時点の公式資料では明確にされていません。「AMP は不要になる」といった断定はしませんし、Grafana 連携の手順をここで断言することも避けます。これらは公式の最新情報をご確認ください。提供リージョン（東京・大阪を含むか等）も拡大・更新されるため、利用前の確認をおすすめします。

まとめ

ポイントを3つに絞ります。

CloudWatch が OTLP のネイティブ取込みと PromQL（Prometheus 3.0 準拠）に対応し、PromQL や Grafana の資産を温存したまま保存先を寄せられる選択肢が増えました。
課金は取込み GB 単位（$0.50/GB・15ヶ月保存込み）と PromQL のスキャンサンプル課金で、Classic の「メトリクス数課金」とはコストを管理する軸が変わります。試算は前提付きで、金額は公式の最新ページでご確認ください。
移行はデュアルライト4フェーズで段階的に進められ、vended メトリクスは自動でクエリできます。GA の明示や AMP との棲み分けは断定せず、公式の最新情報をご確認ください。

可観測性のコストと運用をどう最適化するかは、コンピュートやサーバーレスのコスト設計とも地続きのテーマです。あわせて、コンピュート側の最適化として EC2 Graviton4、サーバーレスの起動コストとして AWS Lambda SnapStart for Python、そして最近の発表をまとめた AWS最新サービスの解説ハブも参考にしてみてください。SRE や可観測性、AWS 運用の移行・コスト最適化を一気通貫で語れると、実務でも評価されやすい領域だと感じています。