Skip to main content
Welcome — this lesson covers the core Amazon RDS metrics to monitor for diagnosing and optimizing database performance. These high-level metrics expose common bottlenecks and guide decisions around tuning, scaling, or re-architecting your database layer.

​
Key metrics and what they indicate

​
CPU utilization

Monitor the percentage of CPU used by your RDS instance. Sustained high CPU usually signals heavy read/write activity or inefficient queries.
  • What to check:
    • Query patterns and slow queries.
    • Index usage and full table scans.
    • Background tasks such as backups or maintenance.
  • Scaling guidance:
    • Vertical scaling (larger instance) is commonly required for write-heavy workloads.
    • Horizontal scaling (read replicas) is effective when reads dominate.
    • Always profile and optimize queries before resizing; inefficient SQL can consume CPU even on larger instances.
Before vertical scaling, profile slow queries and confirm that CPU is the real bottleneck. Increasing CPU without fixing inefficient queries can be costly and temporary.

​
Database connections

Track the total number of open connections. A sudden rise or sustained high count can indicate missing connection pooling, app misconfiguration, or too many clients.
  • Solutions:
    • Implement connection pooling in the application.
    • Use RDS Proxy to multiplex client connections and maintain a controlled pool of persistent DB connections.
A diagram titled "Database Connections" showing Amazon RDS on the left, a stacked-disk database icon in the center, and an application box on the right. It illustrates tracking the number of open connections between the application and the database.
RDS Proxy is an add-on service that sits in front of your RDS instance and maintains a configured number of persistent connections to the database. It reduces connection churn, improves application scalability, and mitigates connection storms. See the RDS Proxy docs: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html

​
Freeable memory

Freeable memory is the RAM available on the DB instance. Low freeable memory often correlates with degraded performance (e.g., increased swapping, evictions from caches).
  • If memory is low:
    • Consider vertical scaling to a larger instance type with more RAM.
    • Offload read-heavy workloads to read replicas so the primary’s memory is less pressured.
    • Re-evaluate indexing and caching strategies so working sets fit in memory.
A slide titled "Freeable Memory" showing an Amazon RDS icon on the left and a stylized RAM/chip and database icon on the right. It explains that freeable memory is the amount of RAM the instance can use and notes "Low memory → Poor performance."

​
I/O metrics (Read/Write IOPS and latency)

Key I/O metrics are ReadIOPS, WriteIOPS, ReadLatency, and WriteLatency. They show how active and responsive your storage layer is.
  • High read latency: consider read replicas, caching (Redis/Memcached), or query/index optimization.
  • High write latency: consider higher-throughput storage (Provisioned IOPS), larger instance types, or batching writes where possible.
A diagram titled "Write Latency" showing a code/application icon on the left sending write operations (arrow with a stopwatch) to an Amazon Relational Database Service (Amazon RDS) icon on the right.

​
Disk queue depth

DiskQueueDepth measures the number of pending I/O operations waiting for the disk. A sustained high queue depth indicates the disk cannot keep up with demand.
  • Remediation steps:
    • Increase IOPS or switch to higher-performance volume types (Provisioned IOPS, io2).
    • Increase instance size if the workload requires more CPU/memory to process IO.
    • Offload reads to replicas or a cache to reduce IO pressure on the primary.
A diagram titled "Disk Queue Depth" showing an application icon on the left sending multiple read/write requests that sit in a disk queue, then are processed by Amazon Relational Database Service (RDS) on the right.

​
Quick reference table

​
Monitoring tools and deeper visibility

Monitor related metrics together. Example: high CPU with low DiskQueueDepth implies compute-bound issues (optimize queries or scale CPU), while high DiskQueueDepth with high latency indicates a storage bottleneck (increase IOPS or offload reads).

​
Best practices summary

  • Profile and optimize slow queries and indexing before scaling.
  • Use connection pooling and RDS Proxy to manage connection storms.
  • Offload read traffic to read replicas or caches to reduce primary load.
  • Pick the right storage class (Provisioned IOPS / io2) for write-heavy, latency-sensitive workloads.
  • Combine CloudWatch alarms, Enhanced Monitoring, and Performance Insights for comprehensive diagnostics.
These metrics and practices will help you detect bottlenecks early and choose the most effective tuning or scaling approach for Amazon RDS-based databases.

Watch Video