SYSTEM Cited by 3 sources

Amazon CloudWatch

What it is

Amazon CloudWatch is AWS's managed observability service for metrics, logs, and alarms across AWS services and customer applications. Most AWS services auto-publish default metrics (CPU, IOPS, network bytes, per-service-specific counters) to CloudWatch at no additional charge; opt-in tiers (higher-resolution metrics, Logs ingestion, custom dashboards, cross-account / cross-region aggregation) are billed separately.

Stub — expand as dedicated CloudWatch-internals sources are ingested.

Sub-services on the wiki

• systems/amazon-cloudwatch-metric-streams — push-based near-real-time export of CloudWatch metrics into Firehose delivery streams. Supports OTel 0.7 / 1.0 / JSON output formats. The structural inverse of pull-based Prometheus + CloudWatch-exporter scraping (which hits API throttling at fleet scale). See concepts/push-vs-pull-monitoring.

Seen in

• sources/2026-05-13-aws-streaming-cloudwatch-metrics-to-vpc-based-opentelemetry-collectors-using-lambda — canonical wiki disclosure of CloudWatch Metric Streams as the push-based replacement for Prometheus + CloudWatch-exporter pull. Customer's prior architecture used Prometheus + CloudWatch exporter, which "resulted in higher API throttling. This caused metric loss and created gaps in observability data for business-critical systems. The frequent polling approach in this model also resulted in higher costs from API calls." The push replacement uses Metric Streams (in JSON format) into Firehose → Lambda transform → internal NLB → OTel collector on EC2 inside the VPC. Canonical wiki naming for the CloudWatch Metric Streams → VPC OTel collector pattern and the push-vs-pull monitoring trade-off at the observability altitude. Format support enumerated verbatim: "With CloudWatch Metric Streams, you can stream metrics in OpenTelemetry 0.7, 1.0, and JSON formats."

• sources/2026-05-12-aws-building-hybrid-multi-tenant-architecture-for-stateful-services — canonical wiki instance of per-tenant-dimensioned CloudWatch metrics as the natural observability shape for cluster-per-tenant multi-tenant SaaS. AWS ad-serving platform emits metrics with tenant_id as a CloudWatch dimension directly from each tenant's ECS service. First-class metric catalogue: memory usage per ECS service (alarms at 70% warn / 85% critical); TargetResponseTime per ALB target group (100–200 ms baseline for stateful services; alert on 2× for >5 min); HTTPCode_Target_5XX_Count per target group; ALB tier-level health (ActiveConnectionCount, ProcessedBytes, Route 53 health checks). Structured CloudWatch Logs with tenant_id, tier_id, region fields in every entry; single log group per tier with tenant-prefixed log streams. Verbatim CloudWatch Logs Insights query example for cross-tenant error-rate analysis. First canonical wiki instance of CloudWatch metrics + Logs as the two-altitude observability shape (tenant-level + tier-level) for patterns/hybrid-multi-tenant-architecture.

• sources/2026-05-05-airbnb-monitoring-reliably-at-scale — canonical wiki instance of CloudWatch as the external-control-plane watchdog for an internal observability stack's dead-man's switch. Airbnb routes a continuous always-firing Alertmanager heartbeat via SNS to CloudWatch, where a rate alarm on incoming SNS messages pages on-call when the heartbeat stops. The architectural property that makes CloudWatch load-bearing here is that it runs on a different cloud control plane than the K8s-hosted internal stack it watches — so a dedicated-cluster incident cannot take both down simultaneously. New role on the wiki: observability-stack watchdog on an independent control plane. See concepts/dead-mans-switch and patterns/heartbeat-absence-as-alert-trigger.
• — canonical wiki disclosure of CloudWatch's three-tier billing model for Amazon Aurora monitoring:
  1. Default Aurora metrics — "Amazon Aurora will send a wide array of metrics to CloudWatch every minute for both the cluster and each individual instance at no extra cost."
  2. Enhanced Monitoring — "uses CloudWatch Logs, which are charged based on how much data is sent into CloudWatch each month. Associated costs may differ drastically between clusters, but you do get more granular data to analyze as needed."
  3. Performance Insights — "bills based on how long you wish to retain the data, up to two years. The first seven days are included at no additional cost, but you will be billed for any data retention beyond that." First canonical wiki instance of CloudWatch's three-tier DB-monitoring billing surface. Morrison's framing: CloudWatch is an "external tool" requiring context-switch from the DB console — vs PlanetScale's in-dashboard Insights product which bundles query-level observability directly.

Related

• systems/amazon-cloudwatch-metric-streams — push-based metric-export sub-service.
• systems/amazon-data-firehose — the only delivery target Metric Streams supports.
• systems/opentelemetry — open standard CloudWatch metrics can be pushed into via Metric Streams.
• systems/aws-rds, systems/amazon-aurora — default DB-metric publishers.
• systems/aws-observability-access-manager — cross- account CloudWatch aggregation primitive.
• systems/aws-sns — SNS-topic-rate-alarm is the substrate for the dead-man's-switch watchdog.
• systems/alertmanager — upstream sender of the DMS heartbeat that CloudWatch watches.
• concepts/observability — parent category.
• concepts/push-vs-pull-monitoring — the architectural axis Metric Streams resolves.
• concepts/dead-mans-switch
• concepts/meta-monitoring
• patterns/cloudwatch-metric-stream-to-vpc-otel-collector — composite VPC-private push-monitoring architecture.
• patterns/heartbeat-absence-as-alert-trigger