Amazon RDS insights

CommitLatency measures time from commit request to acknowledgment. Spikes during high DMLThroughput periods indicate storage layer I/O saturation or replication lag affecting commit acknowledgments in multi-AZ or Aurora configurations.

Aurora MySQL clusters have a hard 128 TiB storage limit. Monitoring AuroraVolumeBytesLeftTotal is more reliable than VolumeBytesUsed for anticipating out-of-space conditions because it accounts for internal housekeeping allocations.

As DatabaseConnections approaches the engine's max_connections limit, new connection attempts fail, causing application errors. For Aurora MySQL v3, AuroraSlowConnectionHandleCount and AuroraSlowHandshakeCount indicate connection establishment delays.

I/O operations per second (IOPS) hitting provisioned limits cause throttling, increasing read/write latency and degrading application performance. Correlating IOPS with latency and disk queue depth reveals I/O saturation.

RDS instances running out of storage space will enter a storage-full state, causing write operations to fail. For Aurora MySQL, AuroraVolumeBytesLeftTotal provides more accurate out-of-space detection than VolumeBytesUsed.

Elevated commit latency directly impacts application response time for write transactions. High latency indicates storage layer slowness, network issues, or insufficient IOPS provisioned for the workload.

Low freeable memory forces RDS to use swap space, drastically degrading query performance. Correlating memory pressure with buffer cache hit ratio reveals whether insufficient memory is causing excessive disk I/O.

Elevated replica lag in RDS read replicas signals that the replica is falling behind the primary, potentially causing stale reads, increased risk of data loss during failover, and storage pressure from retained logs.

High CPU utilization combined with SOS_SCHEDULER_YIELD wait events (SQL Server) or excessive context switching indicates CPU-bound queries competing for limited cores. This pattern suggests either under-provisioned instances or inefficient queries.

High CPU utilization combined with high VolumeReadIOPs indicates queries are CPU-intensive while simultaneously causing excessive storage reads, suggesting missing indexes or inefficient query plans rather than compute undersizing.

For T2/T3 instances, when CPUCreditBalance depletes while CPUCreditUsage remains high, the instance becomes CPU-throttled and performance degrades severely until credits regenerate or you pay for surplus credits.

RDS instances have connection limits that, when approached, can cause new connections to be rejected. Monitoring connection count against the limit before reaching it enables proactive scaling or connection pooling.

When FreeableMemory approaches zero, RDS instances begin using swap space causing severe performance degradation across all database operations, with disk queue depth spiking as swap I/O competes with database I/O.

Elevated aws_rds_deadlock counts indicate concurrent transactions competing for locks in incompatible order, forcing transaction rollbacks and requiring application retry logic, degrading throughput and latency.