Amazon CloudWatch is AWS's native observability service. Almost everything it does reduces to three primitives plus an event bus. **Metrics** — time-series numeric data, organized by namespace (`AWS/RDS`, `AWS/EC2`, custom) and scoped by dimensions (e.g. `InstanceId`). AWS services publish them automatically; you add custom metrics via `PutMetricData` or the embedded metric format (EMF). Standard resolution is 1-minute, high-resolution down to 1-second. Metric math and statistics (Avg, Sum, p99) compute over them. Retention is automatic and tiered (downsampled over ~15 months). Cost trap: you pay per custom metric **and** per API call, so high-cardinality custom metrics get expensive fast. **Logs** — log groups (one per app/service) hold log streams (one per source). Ingested via the CloudWatch agent, Lambda, or SDK. Query with **Logs Insights** (its own query syntax, not SQL). Metric filters can extract metrics from log patterns so you can alarm on log content. Retention is per log group and defaults to **never expire** — a silent, compounding cost trap. **Alarms** — watch a single metric or a metric-math expression against a threshold over N evaluation periods. States: `OK` / `ALARM` / `INSUFFICIENT_DATA`. Actions fire on state change (SNS notify, Auto Scaling, EC2 action). **Composite alarms** combine child alarms with boolean logic to suppress noise. Alarms are the action layer — metrics and logs are inert without them. **EventBridge** (formerly CloudWatch Events) — the event bus reacting to AWS API activity and schedules (cron). Now a separate service, but the bridge from observability to automation. Mental model: **Metrics + Logs are signal; Alarms + EventBridge are the actuators** that turn signal into action. Most CloudWatch bill surprises trace to custom-metric API volume and never-expiring log retention. In the vault: [[CFN Failure Rollback Behavior]] uses CloudWatch alarms as CloudFormation rollback triggers, and `Confirming a DB-Saturating Query — Performance Insights + APM` uses the `CPUUtilization` metric as the third confirming signal for RDS saturation. --- *Source: [[AWS CloudWatch Concepts (AWS Docs)]] — https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html*