Amazon CloudWatch

What it is

Amazon CloudWatch is AWS’s built-in monitoring and observability service, launched in 2009 as a metrics and alarms product for EC2 and other AWS resources. It has since grown far beyond that scope: it now collects logs (CloudWatch Logs), custom application and infrastructure metrics, dashboards, alarms, synthetic canaries, and container/Kubernetes-specific views (Container Insights). Every AWS service emits some level of metrics and logs to CloudWatch by default, which makes it the baseline observability layer for almost any AWS-hosted workload, whether or not you adopt anything else on top of it.

The more significant recent evolution is CloudWatch Application Signals, an APM-style layer that gives an application-centric, auto-instrumented view of services and their dependencies (service maps, SLOs, latency/error/fault detection) built on top of OpenTelemetry data, with distributed tracing itself handled by AWS X-Ray underneath. AWS has been actively expanding this: Application Signals is increasingly the primary surface for tracing and APM workflows, with X-Ray functioning more as its storage/query backend, and it’s being rolled into more services (e.g., automatic enablement in the CloudWatch Observability EKS add-on) and gaining features like automatic capture of exceptions, performance anomalies, and deployment events.

Why teams choose it

• Zero-setup baseline coverage. Because AWS services emit metrics and logs to CloudWatch automatically, teams get infrastructure-level visibility without deploying or configuring anything, which is hard for third-party tools to match on AWS-native workloads.
• Tight IAM and billing integration. Alarms, dashboards, and access controls live inside the same AWS account and IAM model as everything else, which simplifies governance for AWS-centric organizations.
• Expanding into APM territory. Application Signals narrows the gap with dedicated APM vendors for teams that don’t want a separate tracing/APM product, though its feature depth and UX still generally trail purpose-built tools like Datadog or Dynatrace.
• Cost and UX friction at scale. Custom metrics, long log retention, and high-resolution dashboards can get expensive quickly, and the UI is widely considered less polished than dedicated observability vendors, which is why many AWS-heavy teams still export data to a third-party backend once they outgrow the basics.

Pricing model

CloudWatch pricing is granular and usage-based: metrics are billed per metric (with tiered pricing and a free tier for default AWS metrics), logs are billed for ingestion and storage volume, and dashboards, alarms, and API requests are each billed separately. Application Signals and related APM features add their own usage-based charges on top (typically per trace or per monitored entity). There’s no seat-based pricing — cost scales with the number of resources, custom metrics, and data volume you generate, which means costs can be difficult to predict without active cost management, especially for high-cardinality custom metrics.

Alternatives

For teams wanting a more purpose-built observability experience without leaving AWS, Amazon Managed Service for Prometheus-compatible setups or a self-hosted Prometheus/Grafana stack are common upgrades from raw CloudWatch metrics. Commercial alternatives with deeper cross-cloud and APM capability include Datadog, New Relic, and Dynatrace, all of which integrate with AWS but aren’t tied to it, which matters for multi-cloud or hybrid environments.