Amazon CloudWatch launched managed Prometheus collectors on July 31. Cloud operations teams can now collect Prometheus metrics from AWS infrastructure without deploying or running any agents.
The feature covers five services: Amazon EKS, Amazon EC2, Amazon ECS, Amazon MSK, and Amazon OpenSearch Service. Each uses a discovery mechanism matched to how that service exposes targets. EKS uses Kubernetes service discovery. ECS uses DNS-based discovery through AWS Cloud Map. EC2 supports direct instance scraping. MSK and OpenSearch expose open monitoring endpoints the collector polls directly.
What CloudWatch Now Handles for You
Before this, getting Prometheus metrics into CloudWatch meant running a self-managed OpenTelemetry Collector. Teams had to provision it, scale it as workloads grew, patch it, and keep it available. That work sat with the platform team.
With managed collectors, you supply a scrape configuration and connect it to your resources. CloudWatch handles provisioning, scaling, and collection automatically. The collector creates an Elastic Network Interface for each subnet you specify. An Elastic Network Interface, or ENI, is a virtual network card inside your VPC. Metrics travel through those ENIs to a CloudWatch dataset via a VPC endpoint. Scraped data never travels on the public internet.
Metrics arrive in OpenTelemetry Protocol (OTLP) format. OTLP is a vendor-neutral standard for sending telemetry data. They land alongside standard AWS vended metrics in CloudWatch. Teams can then query them with PromQL — Prometheus Query Language — the same syntax engineers already use with open-source Prometheus. Alarms, dashboards, and cross-service correlation all work from one CloudWatch view.
For EKS, MSK, and OpenSearch specifically, metrics can be visualized in automatic dashboards, queried with PromQL, and used in CloudWatch alarms.
The Operational Trade-Off
Replacing a self-managed collector removes a real maintenance surface. Teams running OpenTelemetry Collectors on EKS nodes or EC2 instances carry an upgrade cycle, availability responsibility, and scaling logic. Managed collectors absorb all of that.
The trade-off is cost structure and control. Managed collectors are charged by the hour, and standard CloudWatch OpenTelemetry metric ingestion pricing applies on top of that. Teams with high scrape frequencies or large metric cardinality should model both charges before migrating. One more cost to account for: scraping metrics may incur VPC data transfer charges between the collector and your targets.
Compressing Prometheus /metrics endpoint responses — for example, with gzip — reduces transfer volume. It does not change the number of metrics CloudWatch ingests.
Control over the collector configuration stays with the operator. You write the scrape config. CloudWatch executes it. Teams that have built custom filtering, relabeling pipelines, or routing logic into their existing collector should verify which of those behaviors the managed collector's scrape configuration syntax supports before treating migration as straightforward.
Availability and Boundaries
The feature is available in all AWS Regions where the CloudWatch OTLP endpoint is available, except Asia Pacific (New Zealand). Teams operating in that Region will need to keep their current approach for now.
This feature is distinct from Amazon Managed Service for Prometheus, which is a separate Prometheus-compatible storage and query service. AWS managed collectors — a feature of Amazon Managed Service for Prometheus — gained the ability to write to CloudWatch Metrics datasets as a new destination type in July 2026. The CloudWatch managed collectors launched July 31 are a different product: they deliver directly into CloudWatch and require no separate Prometheus workspace.
What to Check Before You Migrate
Cloud operations leaders and platform engineering teams evaluating a migration should work through four questions.
Service coverage. Does your current scraping cover only EKS, EC2, ECS, MSK, and OpenSearch? Workloads on self-managed Kubernetes outside EKS, or applications with custom Prometheus exporters on other infrastructure, fall outside the managed collector's scope today.
Discovery compatibility. Map your existing service-discovery configuration to the mechanism each service type uses. ECS target discovery relies on AWS Cloud Map DNS-based service discovery, so confirm your targets are registered there. EC2 scraping uses direct instance addressing. If your current setup relies on discovery logic that does not match these patterns, migration requires redesign, not just reconfiguration.
Cost model. Pull your current scrape interval, active series count, and metric ingestion volume. Price hourly collector charges plus CloudWatch OTLP ingestion against what you spend today on compute, storage, and operations for the self-managed collector. Include potential VPC data transfer charges in the estimate.
Scrape configuration portability. Review your existing OpenTelemetry Collector config for relabeling rules, metric filtering, or routing directives. Confirm that equivalent logic is expressible in CloudWatch's managed collector scrape configuration before decommissioning the old pipeline.
For teams that pass those checks, the path to managed collectors is a scrape configuration file and a subnet selection. For teams with more complex pipelines, the managed collector is a useful complement rather than a full replacement — particularly for the services where automatic dashboards are already built in.
