# Observability tier decision matrix — CloudWatch vs Application Signals vs ADOT + Managed Prometheus/Grafana

Score **0** (no), **1** (partial), **2** (yes) per row, then read the
interpretation. The goal is to stop teams from bolting on Amazon Managed
Service for Prometheus (AMP) + Amazon Managed Grafana (AMG) when CloudWatch
Application Signals would have answered the question for less operational
overhead — and conversely to stop teams from forcing high-cardinality
Prometheus workloads into CloudWatch custom metrics where they get expensive.

> Pricing and capabilities below reflect the mid-2026 model. Confirm on the
> CloudWatch, Amazon Managed Service for Prometheus, and Amazon Managed Grafana
> pricing pages before committing budget.

| Criterion | Weight | CloudWatch (core) | CloudWatch Application Signals | ADOT + AMP + AMG |
|-----------|--------|-------------------|--------------------------------|------------------|
| Just need logs, metrics, alarms on AWS services | 3 | | | |
| Want APM (service map, SLOs, traces) with near-zero setup | 3 | | | |
| Already standardized on **PromQL / Prometheus exporters** | 3 | | | |
| Heavy **Kubernetes** estate with existing Grafana dashboards | 2 | | | |
| Need **high-cardinality** custom metrics (labels explode) | 2 | | | |
| Want **OpenTelemetry**-native instrumentation (vendor-portable) | 2 | | | |
| Multi-account single-pane view required | 2 | | | |
| Team has no SRE to run a metrics backend | 2 | | | |
| Need dashboards shared with non-AWS data sources | 1 | | | |

## Interpretation

- **CloudWatch core** wins when you mostly need AWS-service telemetry, alarms,
  and Logs Insights. Don't add a second stack for this.
- **Application Signals** wins when you want APM — auto-discovered service map,
  SLOs, correlated traces — without standing up a metrics backend. It
  auto-instruments EKS/EC2/ECS/Lambda/on-prem and can ingest OpenTelemetry via
  ADOT and the CloudWatch agent. **Transaction Search must be enabled** to get
  the full APM feature set under unified pricing.
- **ADOT + AMP + AMG** wins when you're already Prometheus/PromQL-native, have
  high-cardinality Kubernetes metrics, or want OpenTelemetry-native,
  vendor-portable instrumentation with Grafana dashboards spanning AWS and
  third-party sources.

## The honest middle ground

Many teams land on **Application Signals for app-level SLOs/traces + AMP for
high-cardinality infra metrics + AMG as the unified dashboard**. That is a
valid target — but it is two billing surfaces and two query languages. Adopt it
because you measured a gap, not because the architecture diagram looked complete.

## Cost shape (read before you scale)

| Stack | Primary cost driver | Cheap to start? | Cost trap |
|-------|---------------------|-----------------|-----------|
| CloudWatch core | custom metrics + logs ingest/storage + Logs Insights scans | yes | high-cardinality custom metrics; verbose logs |
| Application Signals | unified APM pricing (spans + traces); Transaction Search | moderate | enabling on every service indiscriminately |
| AMP | **metric samples ingested** (largest driver) | free tier then pay-go | scrape-everything at 15s on a big cluster |
| AMG | **active users/workspace/month** (Editor $9, Viewer $5; +$45 Enterprise plugins) | 90-day trial (≤5 users) | every engineer as Editor when most only view |