Container Monitoring with Amazon Managed Service for Prometheus - Collecting and Analyzing EKS Metrics

EKS/ECS metrics are collected in a Prometheus-compatible way and queried with PromQL. This article introduces a method for building a container monitoring platform through integration with Managed Grafana.

About 7 min readLast updated: 2026-10-31

Overview of Managed Prometheus

Managed Service for Prometheus is a Prometheus-compatible managed monitoring service. Provisioning, scaling, storage management, and high-availability configuration of Prometheus servers are automated, so you can concentrate on collecting and querying metrics. Metrics are sent with the Prometheus remote write API, and queries are run with PromQL. You can migrate existing Prometheus exporters, Grafana dashboards, and alert rules as they are.

Integration with EKS

For collecting metrics from an EKS cluster, the standard pattern is to deploy the ADOT (AWS Distro for OpenTelemetry) collector as a DaemonSet. The ADOT collector scrapes metrics from kubelet, cAdvisor, and kube-state-metrics on each node and sends them to the Managed Prometheus remote write endpoint. IRSA (IAM Roles for Service Accounts) grants the ADOT collector permission to write to Managed Prometheus. If you use the Prometheus Operator, migration is completed simply by keeping the ServiceMonitor and PodMonitor settings as they are and changing the remote write destination to Managed Prometheus. Separately from the configuration of the ADOT collector and Managed Prometheus, Datadog is already integrated with both Kubernetes and AWS, so it can monitor EKS as is. As of October 2026, the Datadog Operator is recommended for installing the Datadog Agent on a cluster, and the Agent can also be installed with a Helm chart. The state of Kubernetes resources such as Pods and Deployments can be viewed in Kubernetes Explorer. In addition, the official Datadog documentation on installing on Kubernetes recommends keeping the versions of the Cluster Agent and the Agent aligned.

PromQL and Alerting

Collected metrics are queried with PromQL, and dashboards are built with Managed Grafana. In addition to standard Kubernetes metrics such as CPU utilization, memory utilization, Pod restart counts, and request latency, you can also collect/visualize application-specific custom metrics. You can define PromQL-based alert rules in the alert manager and send notifications to an SNS topic. Because metrics are retained for 150 days, you can also make use of them for long-term capacity planning and trend analysis.

Managed Prometheus Pricing

Managed Prometheus pricing consists of metric ingestion volume, storage, and queries. For ingestion, the first 2 billion samples/month cost approximately $0.90 per 10 million samples (as of August 2026). Storage costs approximately $0.03 per GB per month, and data is retained for 150 days. Queries are based on the number of samples processed and cost approximately $0.10 per 10 million samples. Compared with self-hosted Prometheus servers, the managed service tends to have a lower total cost in medium-sized or larger environments, because the operational cost of EC2 instances and the effort of storage management are no longer needed.

Collecting from ECS and Self-Managed Clusters

The sources of metrics are not limited to EKS. On ECS, the ADOT collector is built into the task as a sidecar container, and it scrapes and sends the Prometheus-format metrics that the application exposes. You can also migrate from Prometheus that you self-manage on EC2 simply by pointing the remote write destination to the Managed Prometheus endpoint. Even for workloads running on premises or in other environments, you can use Managed Prometheus as the aggregation destination if they support remote write. You can then consolidate metrics scattered across multiple environments in one place and monitor them across environments.

Integration with Managed Grafana

For visualization, combining it with Managed Grafana is the standard choice. When you create a Managed Grafana workspace and register Managed Prometheus as a data source, you can display panels written in PromQL as they are. Authentication is integrated with IAM Identity Center or SAML, and access is controlled with the organization's single sign-on. Existing Grafana dashboards can be migrated simply by importing their JSON definitions, which lets you keep down the cost of learning the tool. Operations become stable when you divide roles between alerts on the Grafana side and alert rules on the Prometheus side and organize them so that notifications are not duplicated.

Designing Alerts and Recording Rules

Alerts are defined in the alert manager built into Managed Prometheus. Thresholds are set with PromQL conditional expressions, and notifications of fired alerts are sent via SNS. For heavy queries that are evaluated frequently, saving aggregation results in advance as separate metrics with recording rules makes the evaluation of dashboards and alerts faster. The basic approach is to design alerts based on symptoms. Monitoring indicators directly tied to user impact, such as worsening latency or rising error rates, rather than CPU utilization itself, results in practical notifications with little noise.

Multi-Account and Cost Optimization

In large-scale environments, splitting workspaces by environment or team makes the boundaries of permissions and costs clear. When aggregating metrics across accounts, the sending side assumes an IAM role and writes to a central workspace. Because ingestion is billed in proportion to the number of samples, the most important points of cost management are not sending unneeded metrics and designing so that label cardinality (the number of combinations of values) does not balloon. Because high-cardinality labels cause ingestion volume to surge, collection targets are narrowed down to what is needed.

Summary

Managed Prometheus is a Prometheus-compatible managed monitoring service and is ideal for collecting metrics from container workloads. The standard integration pattern is to automatically collect metrics from EKS with the ADOT collector, query them with PromQL, and visualize them with Managed Grafana.

References (Official AWS Resources)

The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.

If this page and the official documentation disagree, treat the official documentation as authoritative.

How AWS Keeps Time Internally - Amazon Time Sync Service and Leap Second Smearing DesignLearn how Amazon Time Sync Service works, how GPS and atomic clocks provide high-precision time sources, the design decision to absorb leap seconds through smearing, and why time synchronization matters in distributed systems.Centralizing SaaS Audit Logs with AWS AppFabric - OCSF Standardization and Security Lake IntegrationThis article explains collecting audit logs from SaaS applications with AppFabric, standardizing them to OCSF format, and building analysis pipelines.Implementing Feature Flags with AWS AppConfig - Safe Configuration Deployment and RollbackRoll out configuration changes independently from code deployments using Linear and Exponential strategies. Ensure safety with automatic rollback triggered by CloudWatch alarms.Architecture Review - Systematically Evaluating Workloads with AWS Well-Architected ToolExplains architecture reviews of workloads using AWS Well-Architected Tool. Introduces evaluation based on the 6 pillars, building improvement plans, and using custom lenses.Audit Log Design and Operations - Complete API Activity Recording with CloudTrailLearn how to design audit logs using AWS CloudTrail, including recording API activity, long-term storage in S3, and compliance automation through integration with AWS Config.Lessons from AWS Incident Reports (COE) - How Past Major Outages Shaped Design PrinciplesAnalyze the root causes of past major incidents including the S3 outage, us-east-1 DNS failure, and Kinesis outage from AWS's published Correction of Errors (COE) and incident reports, and explain how they changed AWS's design principles.Tag Design Determines Operations - Trivia and Practical Naming Conventions for AWS Resource Tagging StrategyWe explain why AWS resource tags are not just labels but the foundation for cost allocation, access control, and automation, covering tag key naming conventions, how to use the 50-tag limit, and governance through tag policies.Why AWS Service Quotas Exist - Multi-Tenant Design That Protects Shared InfrastructureExplain how AWS service quotas (formerly service limits) are not mere restrictions but a design to protect other customers in a multi-tenant environment, covering the noisy neighbor problem, soft vs hard limits, and what happens behind quota increase requests.