AWS Managed Prometheus cost: per sample ingested and stored

Quick answer

Amazon Managed Service for Prometheus bills per metric sample ingested (tiered, falling at volume), per query sample processed, and for storage per GB-month. Ingestion is the main line, and it scales with metric cardinality times scrape frequency, so reducing high-cardinality labels and lengthening scrape intervals on low-value metrics are the biggest levers.

Amazon Managed Service for Prometheus removes the operational burden of running Prometheus, and prices it by the metric samples flowing through. Because sample volume is the product of how many time series you have and how often you scrape them, cardinality control is the heart of managing this cost.

Samples, queries, and storage

Dimension	Bills for
Ingestion	Per metric sample ingested (tiered)
Query	Per query sample processed
Storage	Per GB-month

A sample is one data point for one time series at one moment. Ingestion is billed per sample, at tiered rates that fall with volume, and is usually the dominant line. Queries bill per sample processed, and storage bills per GB-month for retained metrics.

Cardinality is the cost driver

Sample volume equals the number of active time series times the scrape frequency. High-cardinality labels, per-request IDs, per-user tags, unbounded dimensions, explode the number of time series, multiplying ingestion. A single label with thousands of values can turn a modest metric into a huge one. Controlling which labels you attach is the biggest lever.

Controlling Managed Prometheus cost

Drop or relabel high-cardinality labels before ingestion, lengthen scrape intervals on metrics that do not need second-level resolution, keep only the metrics you actually query, and set retention to what you use. This is the metrics equivalent of the sampling discipline in CloudWatch metrics cost: ingest what earns its keep, and cut the cardinality and frequency of the rest.

FAQ

How is Amazon Managed Prometheus priced?

Per metric sample ingested (tiered, falling at volume), per query sample processed, and for storage per GB-month. Ingestion is usually the dominant line, and it scales with metric cardinality times scrape frequency, so cardinality control is the main cost lever.

What drives Managed Prometheus cost?

Sample volume, which equals the number of active time series times how often you scrape them. High-cardinality labels (per-request IDs, per-user tags, unbounded dimensions) explode the number of time series, multiplying ingestion cost. A single label with thousands of values can make a metric enormous.

How do I reduce Prometheus cardinality cost?

Drop or relabel high-cardinality labels before ingestion, lengthen scrape intervals on metrics that do not need second-level resolution, keep only metrics you actually query, and set retention to what you use. Reducing cardinality and scrape frequency cuts ingestion, the main cost.

Why is high cardinality expensive in Prometheus?

Because each unique combination of label values is a separate time series, and you pay per sample ingested per series. A label with many possible values multiplies the number of series, and thus samples, for the same underlying metric, so unbounded labels can dominate the bill.

Does scrape interval affect Prometheus cost?

Yes. Sample volume is series times scrape frequency, so scraping every 15 seconds produces four times the samples of every minute for the same metrics. Lengthen scrape intervals on metrics that do not need high resolution to reduce ingestion cost.

Does C3X estimate observability cost?

Managed Prometheus cost is driven by sample ingestion, queries, and storage, which are usage inputs tied to cardinality and scrape frequency. C3X prices the surrounding infrastructure, and you model metric volume to estimate the observability charges.

What to do next

Estimate the infrastructure around your observability before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.