---
title: CloudWatch Managed Prometheus Collectors (July 2026)
description: On July 31, 2026 AWS shipped CloudWatch managed Prometheus collectors. For the AWS Example 22 shape (100 hosts x 50 metrics @ 60s), OTLP ingestion is $54/mo vs $1,500 classic custom metrics if you do not double-ingest.
url: https://www.factualminds.com/blog/cloudwatch-managed-prometheus-collectors-july-2026/
datePublished: 2026-08-03T00:00:00.000Z
dateModified: 2026-08-03T00:00:00.000Z
author: palaniappan-p
category: DevOps & CI/CD
tags: aws-cloudwatch, prometheus, observability, opentelemetry, amazon-eks, amazon-ecs, cost-optimization, devops
---

# CloudWatch Managed Prometheus Collectors (July 2026)

> On July 31, 2026 AWS shipped CloudWatch managed Prometheus collectors. For the AWS Example 22 shape (100 hosts x 50 metrics @ 60s), OTLP ingestion is $54/mo vs $1,500 classic custom metrics if you do not double-ingest.

On **July 31, 2026**, AWS [announced](https://aws.amazon.com/about-aws/whats-new/2026/07/cloudwatch-managed-collectors/) **Amazon CloudWatch managed Prometheus collectors**: fully managed, agentless scrapers that pull Prometheus-compatible metrics from **EKS, EC2, ECS, MSK, and OpenSearch** without you deploying or scaling an OpenTelemetry Collector fleet. Metrics arrive in OpenTelemetry format, query with **PromQL**, and sit next to AWS vended metrics for one alarm and dashboard surface.

This is a collector-ops and destination decision, not a free observability lunch. Ingestion still bills. Cardinality still bills. The win is deleting the scrape fleet if you pick one destination and filter before scrape.

---

## What changed

| Before                                                            | After July 31, 2026                                                    |
| ----------------------------------------------------------------- | ---------------------------------------------------------------------- |
| Self-manage ADOT / Prometheus agent HA, patching, scaling         | CloudWatch-managed scraper (ENI per subnet you specify)                |
| Metrics path often = custom metrics ($0.30/series) or AMP samples | CloudWatch destination: **OTLP $0.50/GB** (15 months storage included) |
| Separate scrape tooling per compute type                          | One CreateScraper flow for EKS / ECS / EC2 / MSK / OpenSearch          |

Official overview: [CloudWatch managed Prometheus collectors](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/managed-prometheus-collectors.html). Solution guides exist for [EC2](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Solution-Prometheus-On-EC2.html) and [ECS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Solution-Prometheus-On-ECS.html).

Architecture notes that matter on day one:

- Scraper creates an **ENI per subnet**; scrape traffic stays on private networking via VPC endpoint to CloudWatch (not the public internet).
- You still need **at least two subnets in different AZs**, security groups that allow collector to exporter ports, and a CloudWatch interface VPC endpoint if the scraper subnets have no internet path.
- Scraping can incur **VPC data transfer** between collector and targets. Compress `/metrics` responses (gzip) to shrink transfer volume; compression does **not** change CloudWatch ingested metric bytes.

Availability: all Regions where the CloudWatch OTLP endpoint exists, **except Asia Pacific (New Zealand)**.

---

## Discovery by compute type

| Source               | Discovery model                     | Gotcha                                                                              |
| -------------------- | ----------------------------------- | ----------------------------------------------------------------------------------- |
| **EKS**              | Kubernetes service discovery        | Cluster access / roles must allow the scraper to find targets                       |
| **ECS**              | DNS via **AWS Cloud Map**           | Static IPs fail after redeploy; register services in Cloud Map first                |
| **EC2**              | `static_configs` / instance targets | Exporter ports must be open to scraper security groups (Node Exporter often `9100`) |
| **MSK / OpenSearch** | Open monitoring endpoints           | Automatic dashboards available; still apply label hygiene                           |

If you run ECS on Fargate with rolling deploys, Cloud Map is not optional. Teams that copy an EC2 `static_configs` block onto ECS will see intermittent gaps that look like "flaky metrics" and are really stale targets.

---

## First-party pricing math (not a client silhouette)

No anonymized engagement is cited for this launch week. Numbers below are **reproducible arithmetic on published AWS examples**, labeled as math.

**CloudWatch OTLP vs classic custom metrics** (AWS CloudWatch pricing Example 22 shape: 100 EC2 instances, 50 metrics each, 60s interval, 500 bytes/datapoint):

| Path                                       | Monthly math                   |      Total |
| ------------------------------------------ | ------------------------------ | ---------: |
| OTLP ingestion                             | 108 GB × **$0.50/GB**          |    **$54** |
| Classic custom metrics (same 5,000 series) | 5,000 × **$0.30**/metric-month | **$1,500** |

**Direction:** −**$1,446**/month on the metric storage model alone for that illustrative shape, before collector-hour fees and VPC transfer. Source: [CloudWatch pricing](https://aws.amazon.com/cloudwatch/pricing/) Example 22 (OpenTelemetry custom metrics).

**Collector hours:** Scrapers are created with `aws amp create-scraper` and a `cloudWatchConfiguration` destination. AMP publishes agentless collector pricing at **$0.04/collector-hour** + **$0.03 per 10M samples collected** ([AMP pricing](https://aws.amazon.com/prometheus/pricing/) Example 2). One always-on scraper is about **$29.76**/month in collector hours (744 × $0.04), before the per-sample collected line. Confirm the collector charge appears as expected when the destination is CloudWatch; do not assume the OTLP GB line is the only new cost.

PromQL API scans: **$0.01 per million samples**. Console, Query Studio, and dashboard queries are free.

Halving the scrape interval from 60s to 30s roughly **doubles** OTLP GB for the same series set. Classic per-series monthly fees do not change with interval. That asymmetry is why managed collectors plus OTLP reward coarser scrapes for non-alerting infra series.

> **Reproduce this** — Open the [OTLP vs classic cost model CSV](https://www.factualminds.com/examples/architecture-blog-2026/cloudwatch-managed-collectors/otlp-vs-classic-cost-model.csv). Plug your `targets × metrics × scrape_interval × bytes_per_datapoint`. Compare to classic `unique_series × $0.30`. Walk the [destination decision matrix](https://www.factualminds.com/examples/architecture-blog-2026/cloudwatch-managed-collectors/collector-destination-decision-matrix.md) before you create a second scrape path. Sample EC2 scrape YAML (with keep/drop relabeling): [sample-ec2-scrape-config.yml](https://www.factualminds.com/examples/architecture-blog-2026/cloudwatch-managed-collectors/sample-ec2-scrape-config.yml).

For the broader stack choice (Application Signals vs AMP vs Grafana), see [Observability beyond CloudWatch](/blog/aws-observability-beyond-cloudwatch-otel-prometheus-grafana-2026/). For label hygiene, see [Prometheus cardinality explosion](/blog/prometheus-cardinality-explosion-amp-cloudwatch-cost-control/). Bill anatomy lives in [CloudWatch pricing dimensions](/blog/amazon-cloudwatch-pricing-metrics-logs-alarms-dashboards/).

---

## Opinionated recommendation

**We recommend:** If your primary pane is **CloudWatch** and you currently run a self-managed Prometheus/ADOT scrape fleet **only for metrics into CloudWatch**, migrate those scrape jobs to **managed collectors → CloudWatch dataset**, with aggressive `metric_relabel_configs` on day one.

**Trade-off you accept:** You give up ADOT processor flexibility and multi-backend dual-export on that path. If you still need traces and logs through the same collector, keep ADOT for those signals. The managed Prometheus scraper does not replace your whole telemetry pipeline.

| Situation                                               | Prefer                                                              | Why                                                 |
| ------------------------------------------------------- | ------------------------------------------------------------------- | --------------------------------------------------- |
| CloudWatch-first, Prometheus exporters on EC2/ECS/EKS   | Managed collector → **CloudWatch**                                  | Kill scrape-fleet ops; PromQL + alarms in one place |
| Grafana + recording rules + AMP already paid for        | Managed collector → **AMP** (or keep existing AMP collector)        | Do not dual-write the same series to OTLP           |
| Need traces/logs processors + metrics                   | Keep **ADOT**; add managed collectors only for isolated scrape jobs | Different jobs, different tools                     |
| EKS infra already on Container Insights OTel ($0.08/GB) | Leave CI-OTel alone; add managed collectors for **app** `/metrics`  | Different product rates and receivers               |

Related ops hygiene: [CloudWatch observability best practices](/blog/aws-cloudwatch-observability-metrics-logs-alarms-best-practices/) and [log sampling / OTel cost control](/blog/log-aggregation-sampling-cloudwatch-otel-aws/).

---

## What broke (pattern): lift-and-shift scrape YAML

> **What broke** — Teams that base64-encode an existing scrape-everything Prometheus config into `CreateScraper` without `metric_relabel_configs` see collector health "green" while Cost Explorer shows an OTel ingestion (or AMP samples) spike within **24–48 hours**. Root cause: managed collectors remove ops friction, not cardinality. A second failure mode: leaving the old ADOT DaemonSet scraping the same `job_name`, so every series is ingested twice. Detection: Cost Explorer filter on CloudWatch OpenTelemetry / AMP collector lines plus scraper vended logs for target count. Fix: one scrape path per job; drop unused families at scrape; gzip `/metrics` where supported.

Related FinOps framing: [observability FinOps / cardinality](/blog/aws-observability-finops-cardinality-cost-control/).

---

## Create a scraper (EC2 path)

Context: AWS CLI v2, AMP `create-scraper` API, CloudWatch dataset destination, scrape YAML from the sample artifact. Replace subnet, security group, and dataset ARN. Encode the YAML as the configuration blob (Linux `base64 -w 0`; macOS `base64`).

```bash
# Assumed: AWS CLI v2, credentials for the workload account, scrape YAML on disk
aws amp create-scraper \
  --alias "ec2-node-exporter-scraper" \
  --source '{
    "vpcConfiguration": {
      "subnetIds": ["subnet-aaa", "subnet-bbb"],
      "securityGroupIds": ["sg-collector"]
    }
  }' \
  --scrape-configuration configurationBlob="$(base64 < sample-ec2-scrape-config.yml | tr -d '\n')" \
  --destination '{
    "cloudWatchConfiguration": {
      "datasetArn": "arn:aws:cloudwatch:us-east-1:123456789012:dataset/default"
    }
  }'
```

Validate in CloudWatch Query Studio with a PromQL selector for your job label (for example `{job="ec2-node-exporter"}`). Collector health and scrape errors land in CloudWatch Logs; see [Monitor collectors](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/managed-prometheus-collectors-monitor.html).

---

## What to Do This Week

1. Inventory every self-managed ADOT/Prometheus agent whose **only** job is scraping `/metrics` into CloudWatch or AMP.
2. Open the [decision matrix](https://www.factualminds.com/examples/architecture-blog-2026/cloudwatch-managed-collectors/collector-destination-decision-matrix.md) and pick **one** destination per job.
3. Fill the [cost CSV](https://www.factualminds.com/examples/architecture-blog-2026/cloudwatch-managed-collectors/otlp-vs-classic-cost-model.csv) with your series count and scrape interval.
4. Pilot **one** EC2 or ECS job with keep/drop relabeling; watch OTel GB (or AMP samples) for 48 hours before fleet rollout.
5. Turn off the old scrape path for that job only after series parity checks in Query Studio or Grafana.

---

## What This Post Doesn't Cover

- Full EKS IRSA / cluster role binding walkthrough for Kubernetes service discovery (use the AWS EKS solution guide for your cluster version).
- Exact CloudWatch console clicks for automatic MSK/OpenSearch dashboards.
- Whether your CUR line item names for collector hours match AMP vs CloudWatch product codes in every region (verify in your account after the first scraper).
- Migrating Grafana dashboards off AMP when you choose CloudWatch as destination.

If you only do one thing: **do not dual-ingest**. Managed collectors remove the agent; they do not forgive scrape-everything YAML or a second collector writing the same series.

## FAQ

### What did AWS announce for CloudWatch managed Prometheus collectors?
On July 31, 2026, Amazon CloudWatch added fully managed Prometheus collectors that scrape Prometheus-compatible /metrics endpoints from Amazon EKS, EC2, ECS (via Cloud Map DNS discovery), Amazon MSK, and Amazon OpenSearch Service without deploying or operating your own OpenTelemetry or Prometheus scrape agents. Metrics land in OpenTelemetry format in a CloudWatch dataset, are queryable with PromQL alongside AWS vended metrics, and can drive CloudWatch alarms and dashboards. Availability tracks CloudWatch OTLP endpoint regions except Asia Pacific (New Zealand).

### How are CloudWatch managed Prometheus collectors priced?
AWS documents two surfaces: collectors are charged by the hour, and CloudWatch OpenTelemetry metric ingestion applies for CloudWatch destinations at $0.50 per GB ingested (uncompressed OTLP payload size), including 15 months of storage with no separate per-series custom-metric fee. Scrapers are created via the AMP CreateScraper API with a cloudWatchConfiguration destination; AMP publishes agentless collector rates of $0.04 per collector-hour plus $0.03 per 10M samples collected. Confirm both the collector line and OTLP GB line on your bill. PromQL API queries are $0.01 per million samples scanned; console and dashboard queries are free. VPC data transfer between collector ENIs and targets can add cost; gzip /metrics responses to shrink transfer volume.

### When should we NOT use CloudWatch managed collectors?
Skip them when (1) you still need a self-managed ADOT pipeline for traces, logs, and custom processors the managed scraper does not replace, (2) your team is Grafana/AMP-native and should keep an AMP workspace destination instead of dual-writing the same series into CloudWatch OTLP, (3) Kubernetes infra metrics already land via Container Insights with OpenTelemetry at the lower $0.08/GB CI-OTel rate and you are not adding custom app exporters, (4) your scrape configs still ship high-cardinality labels (user_id, raw URL, pod UID); fix labels first, (5) you cannot place the scraper in at least two AZs with security groups that reach exporters, or (6) Asia Pacific (New Zealand) is your only region.

### Do managed collectors replace Amazon Managed Service for Prometheus?
No. Managed collectors are the scrape plane. Destination can be a CloudWatch dataset or (on the same CreateScraper surface) an AMP workspace. Choose CloudWatch when you want unified PromQL with AWS vended metrics and CloudWatch alarms. Choose AMP when you need recording rules, long PromQL-native workflows, and Amazon Managed Grafana as the primary pane. Running both destinations for the same jobs doubles ingestion cost with no operational win.

### What could go wrong when migrating scrape configs?
The common failure is lifting a scrape-everything Prometheus config into a managed collector: ENIs come up, discovery works, and OTLP GB (or AMP samples) explode because metric_relabel_configs were never applied. A second failure mode is dual-running the old ADOT DaemonSet alongside the managed scraper so every series is ingested twice. Detect via a sudden OTel ingestion or AMP samples spike in Cost Explorer in the first 48 hours after create-scraper. Fix: keep only one scrape path per job and drop unused metric families at scrape time.

### How do ECS and EKS discovery work with managed collectors?
EKS uses Kubernetes service discovery. ECS uses DNS-based service discovery through AWS Cloud Map because task IPs are ephemeral; static_configs alone will miss tasks after redeploys. EC2 typically uses static_configs or instance targeting against exporter ports (for example Node Exporter on 9100). MSK and OpenSearch use open monitoring endpoints, with automatic dashboards available for EKS, MSK, and OpenSearch metrics.

---

*Source: https://www.factualminds.com/blog/cloudwatch-managed-prometheus-collectors-july-2026/*