SYSTEM Cited by 6 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 push-vs-pull-monitoring.

Seen in

• sources/2026-09-30-aws-running-multi-day-az-evacuation-drills-with-arc-zonal-shift — Per-AZ CloudWatch dashboards as the auditable evidence of an AZ evacuation drill. A 48–72h evacuation needs continuous automated observation, not a visual confirmation; the drill mandates per-AZ metric breakdowns per layer — ALB/NLB HealthyHostCount/RequestCount/TargetResponseTime/HTTPCode_Target_5XX_Count, ECS/EKS CPU + node_status_condition, RDS DatabaseConnections/ReplicaLag, Aurora AuroraReplicaLag/BufferCacheHitRatio. Dashboards are exported as snapshots before/during/after and combined with the ARC zonal-shift event history (list-zonal-shifts) to produce an auditable evidence package for financial-services operational-resilience programs. (Source: sources/2026-09-30-aws-running-multi-day-az-evacuation-drills-with-arc-zonal-shift)

• sources/2026-09-10-aws-building-resilient-real-time-streaming-workers-with-amazon-dynamodb-leases — CloudWatch as the custom-metric autoscaling signal for a stateful worker fleet. Each worker publishes ActiveConnections (namespace WsFleet, dimensioned by service) every 30 s via put_metric_data; an Application Auto Scaling target-tracking policy scales the ECS/Fargate fleet on the fleet-average value (e.g. 700 connections/task target). Illustrates driving capacity off an application-domain metric rather than CPU/memory when the real load signal is connection count. (Source: sources/2026-09-10-aws-building-resilient-real-time-streaming-workers-with-amazon-dynamodb-leases)

• sources/2026-09-09-aws-testing-application-resilience-with-amazon-sqs-and-aws-fault-injection-service — CloudWatch as the dual role of dashboard and experiment stop condition in a resilience test. The load-bearing distinction: a CloudWatch alarm used as an FIS stop condition must fire on a signal that stays healthy if resilience works (application error rate, ALB HTTPCode_Target_5XX_Count, DLQ depth) — never on a metric the experiment is designed to move (ApproximateAgeOfOldestMessage, NumberOfMessagesSent), which would trip in the first phase and abort the run. The same ApproximateAgeOfOldestMessage metric is fine as a production SLA alert but wrong as an experiment stop condition. Also the reading guide for the queue metrics under impairment: NumberOfMessagesSent → 0, ApproximateNumberOfMessagesVisible goes flat, and count-based metrics include retries/duplicates so treat them as trend indicators.

• sources/2026-08-19-aws-ai-powered-clinical-trial-eligibility-and-safety-using-amazon-bedrock-agentcore — end-to-end observability across the three screening agents: agent traces (step-by-step execution logs), latency metrics, error rates (failed tool calls, guardrail blocks), judge pass/flag scores, HITL override/review-latency metrics, and alarm-based escalation when safety thresholds are breached.

• sources/2026-08-21-aws-how-agentflo-built-ai-sales-agents-with-amazon-bedrock-agentcore-part-2 — the sink for AgentCore Observability traces: AgentFlo builds CloudWatch dashboards (active sessions, response times, tool-call patterns), tracks P50/P95 latency + throughput per agent type, alerts on baseline deviation, and does per-merchant/agent/conversation cost attribution.

• 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 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 dead-mans-switch and patterns/alerts-as-code.
• — 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.
• push-vs-pull-monitoring — the architectural axis Metric Streams resolves.
• dead-mans-switch
• concepts/observability
• cloudwatch-metric-stream-to-vpc-otel-collector — composite VPC-private push-monitoring architecture.
• patterns/alerts-as-code