Skip to main content
In this lesson we’ll cover Prometheus — an open-source monitoring and alerting system built for collecting and analyzing time-series metrics from applications and infrastructure. Why monitoring matters
  • Just as health reports collect metrics (blood sugar, cholesterol, weight) to determine overall health, monitoring systems collect operational metrics (CPU, memory, request latency) to assess the health of your services.
  • Metrics let you observe current health, analyze historical trends, and investigate incidents (for example, “what happened Saturday night?”).
To monitor effectively you need:
  • A way to collect metrics from targets (applications, servers, containers).
  • Durable time-series storage to retain metrics for historical analysis.
  • A query language and API to retrieve and slice metrics quickly.
What is Prometheus? Prometheus is an open-source monitoring solution that:
  • Scrapes metrics from instrumented targets.
  • Stores them in a time-series database.
  • Exposes a powerful query language, PromQL, for aggregation and analysis.
Think of Prometheus as an open-source equivalent to managed monitoring solutions like CloudWatch, but available on any platform. Key high-level components
  • Targets: services or applications exposing metrics (HTTP endpoints, exporters).
  • Scraper: pulls metrics from targets at configured intervals.
  • Time-series DB: stores metric samples and associated labels.
  • HTTP server: exposes metrics, PromQL endpoints, and status APIs.
A slide titled "Prometheus and PromQL" showing the Prometheus Server architecture. It depicts Targets feeding into a Retriever, then into a Time Series DB and an HTTP Server which serves data to a user.
Amazon Managed Service for Prometheus (AMP) Amazon’s managed offering (AMP) provides a Prometheus-compatible ingestion and storage backend so you can send metrics from:
  • Amazon EKS, Amazon ECS
  • Amazon EC2
  • AWS Lambda
  • On-premises servers
Use PromQL to query AMP-stored metrics or visualize them with tools like Grafana. AMP reduces operational overhead by handling scaling, durability, and upgrades for you. Benefits of a managed Prometheus solution
  • Automatic scaling for ingestion and storage
  • Deep integration with AWS services
  • No manual infrastructure management (setup, upgrades, scaling)
  • Full PromQL compatibility
  • Cost efficiency: pay for what you use
A slide titled "Key Features" showing four numbered panels with colorful circular icons. The panels list: 01 Scalability, 02 Integrated with AWS, 03 Fully Managed, and 04 PromQL Support.
How Prometheus integrates with AWS services
  • Service discovery: Prometheus discovers targets across environments (EKS, on-prem, etc.) and scrapes metrics from them.
  • Alerting rules: Prometheus evaluates rules and generates alerts when thresholds are breached.
  • Integration: In AWS setups, alerts and metrics can be forwarded or connected to CloudWatch and other AWS services to fit existing operational workflows.
Common architecture pattern
  • Prometheus scrapes containers and services (EKS, on-prem).
  • Prometheus evaluates alerting rules and forwards alerts to Alertmanager.
  • Alertmanager groups, silences, and routes alerts, and can forward notifications to AWS channels like SNS or CloudWatch.
Architecture diagram titled "Amazon Managed Service for Prometheus" showing Amazon EKS and Prometheus ingesting metrics into the Amazon Managed Service for Prometheus. The managed service then triggers Amazon CloudWatch, with container workloads shown inside the EKS boundary.
Alerting with Alertmanager When an alerting rule fires:
  • Prometheus sends the alert to Alertmanager.
  • Alertmanager handles grouping, inhibition, and silencing and routes alerts to the proper receivers.
  • In AWS integrations Alertmanager can post to an SNS topic (via webhook or integrations). SNS then delivers notifications to email, SMS, Lambda, or other subscribers.
  • CloudWatch can be incorporated into this workflow so teams reuse existing alarm actions and on-call integrations.
A simple diagram titled "Amazon Managed Service for Prometheus" showing a flow from Amazon Managed Service for Prometheus to an Alert Manager (with a "Threshold reached" label) and then triggering Amazon SNS ("Trigger").
Quick reference table: Prometheus components and roles When to choose AMP vs self-managed Prometheus
  • Use AMP when you want to offload operational tasks (scaling, durability, upgrades) and prefer AWS-native integration.
  • Use self-managed Prometheus when you need complete control over configuration, retention, or custom deployment topologies and are prepared to operate the infrastructure.
Best practices
  • Instrument services with sensible metrics and labels.
  • Leverage service discovery for dynamic environments (EKS, ECS).
  • Keep alerting rules actionable and avoid noise; route alerts through Alertmanager for grouping and silencing.
  • Use AMP or a federated setup for large-scale environments to handle long-term storage and high ingestion rates.
Summary
  • Prometheus collects and stores time-series metrics and exposes them via PromQL.
  • Operating Prometheus at scale requires managing ingestion, storage, and availability; a managed service like AMP reduces that burden.
  • AMP supports standard Prometheus workflows (scraping, PromQL, alerting) and integrates with AWS services; Alertmanager can route alerts into AWS notification systems (SNS, CloudWatch) to reach on-call teams quickly.
Note: For the AWS Solutions Architect Associate Certification exam you do not need deep implementation details of Prometheus; understanding its role (metrics collection, time-series storage, PromQL, and integration points such as Alertmanager/SNS/CloudWatch) is sufficient.

Watch Video