Amazon Managed Service for Prometheus
A fully managed Prometheus-compatible monitoring service that provides scalable metrics collection, storage, and querying for container workloads
Overview
Amazon Managed Service for Prometheus (AMP) is a fully managed monitoring service fully compatible with open-source Prometheus. It ingests metrics through the Prometheus remote write API and supports PromQL queries. It collects metrics from workloads on EKS, ECS, and EC2, storing them in auto-scaling storage. Issues with self-managed Prometheus - storage capacity management, high availability, and long-term retention - are eliminated, significantly reducing operational burden. Combined with Amazon Managed Grafana, you can build a complete observability stack from metrics collection to visualization. It is redundant across multiple AZs, providing a 99.9% availability SLA.
Workspace Design and Metrics Ingestion
An AMP workspace is the logical isolation unit for metrics. Separating workspaces by environment (dev/stg/prod) or team for clear access control and cost allocation is recommended. Metrics ingestion uses the Prometheus remote write API, sending from existing Prometheus servers, OpenTelemetry Collectors, or AWS Distro for OpenTelemetry (ADOT). In EKS environments, deploying an ADOT Collector as a DaemonSet to collect Pod metrics from each node and send to AMP is common. Authentication uses AWS SigV4 signing, enabling fine-grained access control via IAM roles. For EKS, IRSA (IAM Roles for Service Accounts) grants write permissions at the Pod level. The default ingestion rate limit is 70,000 samples per second, with increase requests available through Service Quotas. High-cardinality metrics (enormous label combinations) impact cost and performance, so designing relabel rules to exclude unnecessary labels is important.
PromQL Queries and Alert Rule Configuration
AMP fully supports PromQL, allowing metrics analysis with the same query syntax as self-managed Prometheus. Query endpoints are also protected by AWS SigV4 authentication, using the SigV4 plugin when connecting from Grafana. Alert rules and recording rules are configured as rule groups in the workspace, written in the same syntax as Prometheus rule YAML files. Amazon SNS can be specified as the alert destination, with SNS enabling integration to Lambda, PagerDuty, and Slack. Recording rules pre-compute and store frequently used complex queries, improving dashboard display speed. For example, pre-computing the 5-minute average CPU utilization across all Pods eliminates real-time calculation when displaying dashboards. In practice, defining SLI (Service Level Indicator) calculations as recording rules and monitoring SLO (Service Level Objective) achievement with alert rules is an effective design.
Cost Optimization and Multi-Account Operations
AMP pricing consists of three axes: ingested samples, stored samples, and queried samples. The first step in cost optimization is suppressing unnecessary metrics ingestion. Prometheus relabel rules (metric_relabel_configs) drop unused metrics and exclude high-cardinality labels. The default retention period is 150 days, but if only short-term metrics are needed, reducing workspace retention period lowers storage costs. In multi-account environments, aggregating metrics from each account's EKS clusters to a central monitoring account's AMP workspace is common. Cross-account writes require configuring AssumeRole from each account to the monitoring account's IAM role. Organizations SCPs control write permissions to the monitoring account, preventing unauthorized metrics submission. Grafana dashboards can register multiple workspaces as data sources, enabling cross-environment metrics comparison.