AWS RDS Monitoring: The Complete 2026 Guide

Short answer: RDS monitoring has three native layers, and you need all three: CloudWatch metrics (60-second, free-ish, host-level basics), Enhanced Monitoring (1–60s granularity, OS-level, billed as CloudWatch Logs), and Performance Insights (query-level waits — the tool that answers "why is the database slow"). On top of those: enable slow query logs to CloudWatch, and set alarms on the seven metrics that predict outages — CPU, freeable memory, free storage, disk queue depth, replica lag, and connection counts. This guide maps each layer, gives the alarm set, and flags the cost traps (CloudWatch's per-metric pricing compounds).

The three layers and what each is for

The division of labor: CloudWatch alarms wake you up; Enhanced Monitoring tells you if it's the database or the OS; Performance Insights tells you which query. Teams that enable only the first layer get paged with no diagnosis path.

The 7 CloudWatch metrics that predict RDS outages

Alarms cost $0.10 each (standard) in CloudWatch — a dozen alarms per instance is pocket change; the compounding cost lives in custom metrics and logs, not alarms.

Related guideMySQL Monitoring: The Complete 2026 Guide→

Performance Insights: your first stop for "database is slow"

PI samples pg_stat_activity/performance_schema continuously and renders average active sessions by wait event, SQL, host, and user. The workflow that solves 90% of RDS slowness:

1. Dashboard shows load (AAS) spiking above the Max CPU line → instance is saturated.
2. Slice by Waits: IO:DataFileRead = cache miss storm; Lock waits = blocking transactions; CPU = genuine compute ceiling.
3. Slice by SQL: the top statement by load is your culprit.
4. Copy the digest, run EXPLAIN (ANALYZE, BUFFERS) against a replica, fix index or query.

Enable PI at instance creation (one checkbox); the 7-day free retention covers incident windows. Long-term PI retention exists for trend analysis but is billed — decide deliberately.

Slow query logs to CloudWatch (or anywhere useful)

# Parameter group settings (PostgreSQL shown; MySQL analogous with slow_query_log=1, long_query_time=1)
log_min_duration_statement = 1000    # ms — start at 1s, tighten on hot paths
log_statement = 'none'
# Enable log export in the console: instance → Logs → PostgreSQL log → publish to CloudWatch

Now slow queries are searchable via Logs Insights — but remember the triple billing from our CloudWatch pricing guide: ingest + storage + scan. Set a retention policy on the log group (30 days for ops), and if log volume is heavy, evaluate exporting to S3 + Athena instead. Guance and other platforms can also collect RDS logs/metrics into the same console as your APM traces — the correlation from "slow endpoint" to "this exact SQL" is what turns a 2-hour incident into a 10-minute one.

Enhanced Monitoring: when to enable

EM's unique value is per-process OS metrics: when CPUUtilization is 90%, EM tells you whether it's Postgres backends, the WAL writer, or an OS process. That distinction decides whether you tune queries or resize. Costs: EM publishes JSON to CloudWatch Logs at your chosen interval — at 1s granularity this is meaningful ingest volume; 15–60s is the sane default. Alternative: skip EM and use PI's OS metrics tab, which covers the common cases without the log-volume bill.

Related guideMySQL Integration→

The 5 RDS failure paths (and their alarms)

1. Storage exhaustion. FreeStorageSpace → 0 halts writes. Prevention: storage autoscaling enabled + alarm at 15%. The alarm without autoscaling buys you hours, not safety.
2. Connection storm. Deploy multiplies app instances; each pool opens N connections; DatabaseConnections hits max_connections; new connections refused. Alarm at 80%; fix with RDS Proxy or PgBouncer.
3. Replica lag surprise. Read-heavy feature launches against a lagging replica; users see stale data; no alarm fired because lag wasn't monitored per-replica. Alarm per-replica at 30 s.
4. IOPS ceiling. gp3 baseline IOPS silently exceeded; DiskQueueDepth climbs; latency doubles. Alarm on queue depth + latency drift.
5. Log-volume bill shock. Slow log + EM at 1 s granularity on a busy instance → CloudWatch Logs ingest dwarfs the RDS bill. Review log-group bytes monthly.

FAQ

Q: How do I monitor AWS RDS?
Enable three layers: CloudWatch metrics with alarms on CPU, freeable memory, free storage, disk queue depth, connections, replica lag, and latency; Performance Insights (free 7-day tier) for query-level waits; and slow query logs exported to CloudWatch with a 30-day retention policy. Add Enhanced Monitoring at 15–60 s granularity when you need per-process OS detail.

Q: What is the difference between Enhanced Monitoring and Performance Insights?
Enhanced Monitoring shows the operating system (per-process CPU/memory) at up to 1-second granularity, delivered via CloudWatch Logs (billed as log volume). Performance Insights shows database load — which SQL statements and wait events consume capacity. "Which process is using the box" = EM; "which query is making it slow" = PI.

Q: Is Performance Insights free?
The 7-day retention tier is free and covers incident analysis. Long-term retention (up to 2 years) is billed monthly per vCPU. Enable PI on every production instance — there is no reason not to use the free tier.

Q: Which RDS alarms should every team set?
Seven: CPU > 85%, FreeableMemory < 20%, FreeStorageSpace < 15%, DiskQueueDepth > 10, DatabaseConnections > 80% of max, ReadReplicaLag > 30 s (per replica), and read/write latency at 2× your baseline. At $0.10 per standard alarm, this set costs under a dollar per instance per month.

Q: Can I monitor RDS with tools other than CloudWatch?
Yes. Datadog, New Relic, Grafana Cloud, and Guance all collect RDS metrics via the CloudWatch API (watch the $0.01/1,000 API request cost at high poll rates) and can additionally poll pg_stat_statements/performance_schema directly for query-level data. The advantage over native CloudWatch: correlation with your APM traces and a single console; the trade-off: another meter to govern.

---

Sources: AWS RDS and CloudWatch documentation (metric definitions, PI retention tiers, EM delivery), CloudWatch pricing (verified in our CloudWatch pricing guide). Verified 2026-08-07. Published by Guance.