There's a category of release I've learned to pay attention to: the one where a piece of infrastructure you were running stops being necessary. Terraform 1.11 did it when S3-native locking made the DynamoDB lock table optional. One less thing to provision, manage and pay for.
On 31 July AWS did it to the OpenTelemetry Collector.
CloudWatch now supports managed Prometheus collectors: scraping metrics from EKS, EC2, ECS, MSK and OpenSearch without you deploying or operating any agent. You provide a scrape configuration and a connection to your resources. AWS handles provisioning, scaling and collection.▸The 60-second version — flip through the deck8 slides · swipe →
Two launches that only make sense together
The collector announcement on its own reads like an operational convenience. The interesting part is what landed six weeks earlier.
On 16 June, CloudWatch started ingesting OpenTelemetry metrics natively, over OTLP, queryable with PromQL. Three details in that launch matter more than the headline:
That 30-dimension ceiling is the reason so many teams run a split pipeline: CloudWatch for AWS vended metrics, a Prometheus-compatible backend for anything with Kubernetes labels on it. Lifting it to 150 removes the technical reason for the split.
Managed collectors then remove the last self-run component on the path.
What the collector actually does for you
Discovery is per service, and it's the part that would otherwise be your YAML:
| Service | Target discovery |
|---|---|
| EKS | Kubernetes service discovery |
| ECS | DNS-based discovery via AWS Cloud Map |
| EC2 | direct instance scraping |
| MSK, OpenSearch | open monitoring endpoints |
Metrics arrive in OpenTelemetry format and are queryable with PromQL alongside AWS vended metrics. EKS, MSK and OpenSearch get automatic dashboards. Everything is available for CloudWatch alarms.
The enrichment is the quiet win. Because CloudWatch attaches AWS resource context on ingest, a query like this works without a single custom label in your instrumentation:
sum by (aws_account_id, k8s_namespace_name)
(kube_pod_status_phase{phase="Running"})
The aws_account_id label is added by the enrichment layer. On a multi-account estate, that's the query you previously built an exporter and a relabel config to make possible.
The collector wasn't hard. It was just always yours to keep alive.
Now check the meter
Here's where I stop cheering.
Removing a component removes operational cost. It does not remove cost. It changes its shape, and the new shape has three separate meters:
| What | How it bills |
|---|---|
| Managed collector | per hour |
| OTLP metric ingestion | per GB, 15 months of storage included, no separate charge for API calls or unique series |
| PromQL queries | per million samples scanned |
The first two are predictable. The third is the one to model before you migrate, because it prices a behaviour that used to be free at the margin.
A self-hosted VictoriaMetrics box has a cost you already paid. Whether a dashboard on the office TV refreshes every 30 seconds or every 5 minutes changes nothing on the invoice. Under per-query pricing, that refresh interval, multiplied by every panel, every dashboard and every alert evaluation, is a line item. Not necessarily a large one. But it's a variable where you used to have a constant, and variables are what surprise people at the end of the month.
The other practical caveats: managed collectors are available in all Regions where the CloudWatch OTLP endpoint exists, except Asia Pacific (New Zealand). And OTLP ingestion itself is in all commercial Regions except Middle East (UAE), Middle East (Bahrain) and Israel (Tel Aviv). Check your Region list before you write the migration ticket.
Where I've landed
My default for a metrics stack is still self-hosted VictoriaMetrics with Grafana, shipped as versioned charts and reconciled by ArgoCD on day one of a cluster. Two reasons, both boring: it's portable across clouds, and its cost is a shape I can predict a year out.
That's a default, not a religion. We reach for a cloud-native backend on purpose when compliance demands it, when the operational cost of self-hosting at volume exceeds the managed bill, or when a client's footprint is single-cloud and native integration beats portability they'll never use.
This launch moves that last case. On an AWS-only estate, "we run our own collector" was defensible mostly because the alternative meant a split pipeline and a 30-dimension ceiling. Both of those arguments just expired.
If you're multi-cloud, keep your collector. If you're all-in on AWS, the honest question is no longer whether the managed path works. It's whether you've modeled what your dashboards cost per query.
Are you running a self-managed collector on AWS today, and what would it take for you to delete it? And if anyone has real numbers on PromQL query billing at dashboard scale, I want to see them.