Amazon CloudWatch（AWSのマネージド監視サービス）が、OpenTelemetry（OTel、ログ・メトリクス・トレースを統一形式で扱う業界標準規格）由来のメトリクスをネイティブに取り込み、PromQL（Prometheusのクエリ言語）でそのまま検索できる機能を2026年6月に一般提供（GA）した。2026年4月のプレビュー開始から2カ月弱での正式化である[1]。対象はAWS環境ですでにPrometheus（OSSの時系列監視ツール）資産を運用しているインフラ・SREチームと、その予算を握るIT経営層だ。新機能はGB単位の従量課金という新料金体系とセットで登場しており、移行のしやすさとコストの見通しを同時に検証する必要がある。本稿では技術面の変化とコスト試算の勘所を整理する。
予備知識
- OpenTelemetry（OTel）: ログ・メトリクス・トレースを統一形式で収集するオープンソースの計測規格。ベンダーロックインを避けつつ観測データを共通化できる。
- OTLP: OpenTelemetryが使うデータ送信プロトコル。アプリケーションや収集エージェントから監視基盤へメトリクスなどを送る際の通信規格。
- PromQL: OSSの監視ツールPrometheusが使うクエリ言語。時系列データを集計・演算して異常検知やダッシュボード表示に使う。
- カーディナリティ: メトリクスに付くラベル（タグ）の組み合わせ数の多さ。高いほど検索や保存の負荷、コストが増えやすい。
OpenTelemetryの仕組みを体系的に理解しておくと、OTLPペイロードがなぜ課金対象として膨らむのかを設計段階で見積もりやすくなる。
CloudWatchがOTelネイティブ対応をした意味
CloudWatchのOTelネイティブ対応とは、OTLP経由で送られたメトリクスをそのままの構造で保存し、PromQLで直接クエリできるようにした機能である。2026年4月2日にプレビューが始まり、6月にGAした[1]。高カーディナリティ対応の新しいメトリクスストアを新設し、1メトリクスあたり最大150ラベルまで受け付ける。従来のCloudWatchカスタムメトリクスは30次元が上限だったため、変換や切り詰めなしでラベルの多いメトリクスをそのまま送れるようになった[1]。
既存のAWS標準メトリクス（70以上のサービスから提供される標準メトリクス）と同じ画面・同じPromQL文法で横断検索できる点も変化点である[1]。送信経路はADOT（AWS Distro for OpenTelemetry、AWSが配布するOTelコレクター）を介する方法と、SDKから直接送る方法の両方がある。クエリはCloudWatch Query StudioかAmazon Managed Grafanaで実行する[1]。
既存のPrometheus運用をCloudWatchへ持ち込む前に、remote_writeの送信量やラベル設計の勘所を再確認しておきたい。
GB単位の新課金体系
CloudWatchのOTelメトリクスは、送信したOTLPペイロードの未圧縮サイズを基準にGB単位で課金される新体系を採用した。プレビュー期間中（2026年4月〜6月）は無料だったが、GA後は1GBあたり0.50ドル（約78円、1ドル=155円換算）の従量課金になり、15カ月分のストレージ込みである[2]。課金対象はメトリクス値・名前・タイムスタンプ・すべての属性・リソースメタデータを含む未圧縮サイズであり、API呼び出し回数やユニークなメトリクス系列数そのものでは課金されない[2]。
従来のCloudWatchカスタムメトリクスは「メトリクス数×月額単価」の段階制だった。最初の1万メトリクスは1個あたり0.30ドル（約47円）、次の24万個は0.10ドルと逓減する仕組みで、さらにPutMetricData APIの呼び出しに100万件あたり0.01ドルが加算される[3]。課金の軸が「メトリクスの種類の数」から「送るデータ量」に切り替わった点が実務上のインパクトである。
| 項目 | 従来のカスタムメトリクス | OTelメトリクス（GA後） |
|---|---|---|
| 課金単位 | メトリクス数（段階制） | 送信データ量（GB、未圧縮） |
| 単価の目安 | 1〜1万個目: 0.30ドル/月 | 1GBあたり0.50ドル |
| API呼び出し課金 | PutMetricData 100万件で0.01ドル | 課金対象外 |
| ラベル/次元上限 | 30次元 | 150ラベル |
| 保持期間 | 標準保持ポリシーに従う | 15カ月分がGB単価に込み |
クラウド費用の急増に気づいてから原因を突き止めるまで、FinOpsやインフラの担当者はコストエクスプローラーの画面とCloudTrailのログを手作業で突き合わせてきた。AWSは2026年6月9日、この調査作業を生成AIエージェント[…]
Prometheus資産を持つチームの移行判断
PromQLがそのまま使えることは、既存のPrometheusクエリやダッシュボードの書き換えコストを下げる。文法を学び直す必要がなく、運用ノウハウをCloudWatch側にも持ち込みやすい[1]。
これまでAWS環境で高カーディナリティなPrometheusメトリクスを扱う中心的な選択肢はAmazon Managed Service for Prometheus（AMP、AWSのマネージドPrometheus）だった。AMPはコンテナ由来の高カーディナリティなメトリクス処理に最適化されている一方、CloudWatchはログ・メトリクス・トレース・ダッシュボード・アラームを一つの画面に統合する観測基盤という立ち位置の違いがある[1][4]。
| 観点 | Amazon Managed Service for Prometheus (AMP) | CloudWatch OTelメトリクス |
|---|---|---|
| 最適な用途 | コンテナ由来の高カーディナリティ監視に特化 | ログ・メトリクス・トレースの統合監視 |
| クエリ言語 | PromQL | PromQL（CloudWatch標準メトリクスも同一画面） |
| 主な連携先 | Amazon Managed Grafana中心 | Query Studio／Managed Grafana |
| 向いているチーム | Kubernetes中心でコンテナ監視を深掘りしたいチーム | AWS全体を一元的に見たいチーム |
Azure Storage GPv1（General Purpose v1、汎用ストレージアカウント旧バージョン）が2026年10月13日に廃止される。Azureでストレージアカウントを持つ組織は、この期日までにGPv2（Gener[…]
移行前に詰めておきたいコスト試算
移行判断で最も見落としやすいのは、ラベル数の多いメトリクスほど課金対象の未圧縮サイズが膨らむという点である。150ラベルまで許容する設計は表現力を高める半面、既存のPrometheus remote_write（Prometheusが外部の保存先へデータを転送する仕組み）で大量のラベルを付けている構成をそのまま持ち込むと、想定より重いペイロードになりやすい[1][2]。
移行前には、現行のPrometheusで実際に送信しているメトリクス量を実測し、GB単価に当てはめて概算する作業が要る。既存のカスタムメトリクスと併用する場合は、どちらの課金体系が支配的になるかも切り分けたい。
※本記事は2026年7月時点の情報です。料金・提供条件は変動が速いため、最新は各公式でご確認ください。一部アフィリエイトリンクを含みます。 ✅ 先に結論（Seedance 2.0の要点） 何がすごい[…]
よくある質問（FAQ）
Q1. CloudWatchのOTelメトリクス対応はいつから使えるか。
2026年4月2日にプレビューとして提供が始まり、同年6月にGB単位の課金体系とともに一般提供（GA）された[1][2]。
Q2. 既存のPrometheus環境をすべてCloudWatchに移行する必要があるか。
必須ではない。AMPは高カーディナリティなコンテナメトリクスに最適化されており、ログやトレースまで含めた統合監視を重視する場合にCloudWatchが選択肢になる[1][4]。
Q3. GB課金は何を基準に計算されるか。
OTLPで送信したメトリクス値・名前・タイムスタンプ・属性・リソースメタデータを含む未圧縮ペイロードサイズが基準であり、API呼び出し回数やメトリクス系列数そのものでは課金されない[2]。
まとめ
CloudWatchのOTel/PromQL対応は、Prometheus資産を持つチームの技術的な移行障壁を明確に下げた。一方で課金がGB単位の従量制に変わったため、ラベル数や送信頻度次第でコストは大きく変動する。導入を検討するチームは、現行のPrometheus送信量を実測したうえでGB単価に当てはめた試算を先に行うべきだ。そのうえでAMPとの使い分けや既存カスタムメトリクスとの併用範囲を予算担当者と合意してから着手したい。技術選定とコスト設計は切り離せない。
