Amazon Aurora runs a database cluster rather than a single server. One cluster holds a writer instance, zero or more reader instances, and one shared storage volume. Monitoring it well takes two sources, so there are two dashboards per engine.
CloudWatch reports what the cluster and its instances are doing: capacity, replica lag, memory, storage I/O, and volume growth. The database engine reports what the queries are doing: buffers, locks, row activity, and table sizes. Neither source covers the other, so run both.
Available Amazon Aurora Dashboards
Choosing Between Them
| Question | Dashboard |
|---|---|
| Is the cluster sized right, and how far behind are the readers? | CloudWatch |
| How much storage is the cluster volume using? | CloudWatch |
| Which queries are scanning instead of seeking? | Engine Metrics |
| Is autovacuum keeping up, or is the buffer pool too small? | Engine Metrics |
Instance metrics on the CloudWatch dashboards group by DBInstanceIdentifier, so the writer and each reader appear as separate series. Storage volume and serverless capacity are cluster-scoped and exist only under DBClusterIdentifier.
Limitations
Replication metrics do not work on Aurora on either engine. Aurora replicates through its shared storage volume, so pg_stat_replication and SHOW REPLICA STATUS both return no rows, and the receivers' replication metrics never populate. Use Aurora Replica Lag on the CloudWatch dashboards instead.
Several standard Amazon RDS metrics do not exist on Aurora and appear on none of these dashboards: FreeStorageSpace, ReplicaLag, BinLogDiskUsage, BurstBalance, and CheckpointLag. Aurora reports VolumeBytesUsed in place of FreeStorageSpace.
Next Steps
- Set up Aurora monitoring for metrics and logs.
- Set up alerts on replica lag, connection count, and volume growth.
- Trace slow queries back to the application code that ran them.
