AWS RDS Enhanced Monitoring gives you real-time OS-level metrics for your database instance. It shows details like CPU, memory, disk I/O, file system activity, and running processes, which helps you see what is happening inside the RDS host.
Standard CloudWatch metrics are still useful, but they do not show the full operating system view. In this guide, you’ll learn what AWS RDS Enhanced Monitoring is, how it works, how to enable it, and what it may cost.
Key Takeaways
- Enhanced Monitoring gives you OS-level visibility; standard CloudWatch gives you hypervisor-level visibility.
- It is disabled by default on new RDS instances.
- Its data is stored in CloudWatch Logs, not CloudWatch Metrics.
- The log group name is
RDSOSMetrics. - At 60-second granularity, the cost is about
$0.14per instance per month. - At 1-second granularity, the cost is about
$8.04per instance per month. - Enabling or disabling it does not reboot or restart your DB instance.
- It complements Performance Insights by covering OS-level behavior instead of SQL-level activity.
- The IAM trust entity must be
monitoring.rds.amazonaws.com. - For Multi-AZ DB clusters, use
modify-db-cluster, notmodify-db-instance.
What is AWS RDS Enhanced Monitoring?
RDS Enhanced Monitoring is a feature in Amazon Relational Database Service that deploys an agent directly on the operating system of your DB instance’s host. That agent collects granular OS-level metrics, including CPU breakdown by process, memory consumption, disk I/O queues, file-system usage, and network throughput, and publishes them to Amazon CloudWatch Logs (not standard CloudWatch metrics) in real time.
By default, Enhanced Monitoring is disabled when you create a new RDS instance. You must enable it explicitly, either when you create the instance or by modifying an existing one.
It is available for every RDS engine: MySQL, PostgreSQL, MariaDB, Oracle, Db2, and Microsoft SQL Server.
CloudWatch vs Enhanced Monitoring
Standard CloudWatch metrics for RDS are collected by the hypervisor, the virtualization layer beneath your instance. Enhanced Monitoring collects from an agent inside the OS on the host. This distinction matters when diagnosing performance issues on smaller instance classes, where multiple VMs may share a single physical host.
Disclaimer: This table reflects AWS RDS monitoring behavior at the time of writing. CloudWatch metrics, Enhanced Monitoring intervals, retention periods, and CloudWatch Logs costs may vary by Region or change over time. Always check the latest AWS documentation before making production monitoring decisions.
| Standard CloudWatch | RDS Enhanced Monitoring | |
|---|---|---|
| Data source | Hypervisor (VM layer) | OS agent on the host |
| Granularity | 1-minute minimum | 1, 5, 10, 15, 30, or 60 seconds |
| CPU breakdown | Total CPU only | user, system, IRQ, steal, idle, wait |
| Process-level visibility | None | Per-process CPU and memory |
| Memory | FreeableMemory only | active, buffered, cached, free, total |
| Disk I/O | ReadIOPS, WriteIOPS, Latency | Queue depth, avg request size, await, util% |
| Stored in | CloudWatch Metrics | CloudWatch Logs (RDSOSMetrics) |
| Default retention | 15 months | 30 days (configurable) |
| Extra cost | Included in RDS | CloudWatch Logs ingestion + storage fees |
Note
CPU readings from CloudWatch and Enhanced Monitoring often differ slightly, especially on smaller instance classes where multiple VMs share one physical host. If your CloudWatch CPU shows 30% but you are seeing slowdowns, the OS-agent reading from Enhanced Monitoring will give you the accurate picture.
What OS Metrics Does RDS Enhanced Monitoring Expose?
Metrics are published to CloudWatch Logs as JSON records every N seconds (based on your configured granularity). Each JSON record includes the instance ID, engine type, number of vCPUs, uptime, and the following metric groups:
Disclaimer: The exact Enhanced Monitoring metrics available can vary by database engine, RDS configuration, and AWS updates. Use this table as a practical guide, but confirm the latest metric list in the official AWS RDS documentation before relying on it for production monitoring or alerting.
| Group | Metrics | What it tells you |
|---|---|---|
| CPU | user, system, idle, wait, irq, steal, nice, total | Which processes consume CPU; steal shows CPU taken by other VMs on the same host |
| Memory | active, buffered, cached, free, hugePagesFree, total | True OS-level memory pressure beyond CloudWatch FreeableMemory |
| Disk I/O | avgQueueLen, avgReqSz, await, readIOsPS, writeIOsPS, readKbPS, util% | I/O queue depth and latency per device; util% shows saturation |
| File system | total, used, usedFiles, usedPercent, usedFilePercent | Disk usage per mount point including /rdsdbdata (database files) |
| Network | rx, tx (bytes/s) | Network throughput at OS level |
| Processes | cpuUsedPc, memUsedPc, pid, rss, name, tgid, vss | Per-process resource consumption; useful for identifying rogue threads |
SQL Server note
Microsoft SQL Server supports a slightly narrower range of Enhanced Monitoring metrics than the other engines. Process-level and some file-system metrics are not available for SQL Server instances.
How to Enable RDS Enhanced Monitoring
You need two things: a monitoring granularity (in seconds) and an IAM role that grants RDS permission to write to CloudWatch Logs.
Option A – AWS Console
1. Open the RDS Console: Go to console.aws.amazon.com/rds, select your DB instance, and click Modify.
2. Find the Monitoring section: Scroll to Additional configuration > Monitoring. Check Enable Enhanced Monitoring.
3. Set granularity: Choose your monitoring interval: 1, 5, 10, 15, 30, or 60 seconds. A shorter interval means more data and higher cost. Start with 60s and tune down if needed.
4. Select or create the IAM role: Choose rds-monitoring-role from the dropdown. If it does not exist, select Create a new role and AWS will create it automatically with the AmazonRDSEnhancedMonitoringRole policy attached.
5. Apply the change: Click Continue, then choose Apply immediately or schedule for the next maintenance window. Click Modify DB instance.
Option B – AWS CLI
Disclaimer: AWS CLI syntax, IAM permissions, and RDS parameters may change over time. Test these commands in a non-production environment and verify the latest AWS documentation before using them in production.
Create IAM role (run once)
First, ensure the IAM role exists (one-time setup):
aws iam create-role \
--role-name rds-monitoring-role \
--assume-role-policy-document '{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Principal":{"Service":"monitoring.rds.amazonaws.com"},
"Action":"sts:AssumeRole"
}]
}'
aws iam attach-role-policy \
--role-name rds-monitoring-role \
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRoleEnable Enhanced Monitoring on your instance:
aws rds modify-db-instance \
--db-instance-identifier YOUR_DB_INSTANCE_ID \
--monitoring-interval 60 \
--monitoring-role-arn arn:aws:iam::YOUR_ACCOUNT_ID:role/rds-monitoring-role \
--apply-immediately
# Valid values for --monitoring-interval: 0, 1, 5, 10, 15, 30, 60
# Setting 0 disables Enhanced MonitoringReplace YOUR_DB_INSTANCE_ID and YOUR_ACCOUNT_ID with your actual values. For Multi-AZ DB clusters, use modify-db-cluster instead of modify-db-instance.
Enable Enhanced Monitoring on a Multi-AZ DB cluster
aws rds modify-db-cluster \
--db-cluster-identifier YOUR_CLUSTER_ID \
--monitoring-interval 60 \
--monitoring-role-arn arn:aws:iam::YOUR_ACCOUNT_ID:role/rds-monitoring-role \
--apply-immediatelyOption C – CloudFormation and Terraform
MyRDSInstance:
Type: AWS::RDS::DBInstance
Properties:
MonitoringInterval: 60
MonitoringRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/rds-monitoring-role"Terraform snippet
resource "aws_db_instance" "example" {
# ... other config ...
monitoring_interval = 60
monitoring_role_arn = aws_iam_role.rds_monitoring.arn
}How to Verify Enhanced Monitoring is Working
Via CLI
aws rds describe-db-instances \
--query 'DBInstances[*].{ID:DBInstanceIdentifier, Interval:MonitoringInterval}'
# MonitoringInterval > 0 => Enhanced Monitoring is ENABLED
# MonitoringInterval = 0 => Enhanced Monitoring is DISABLEDIf MonitoringInterval is 0 or missing, it is disabled. Any value greater than 0 means it is active.
Via Console
In the RDS Console, select your instance, open the Monitoring tab, and switch the view to Enhanced Monitoring. You should see OS-level graphs for CPU, memory, disk I/O, and network within about 60 seconds of enabling it.
Via CloudWatch Logs
Navigate to CloudWatch → Log groups → RDSOSMetrics. Your instance will have its own log stream named after its resourceId. Each log event is a JSON document containing the OS metrics for that monitoring interval.
How to Disable RDS Enhanced Monitoring
Set the monitoring interval to 0 to turn it off completely:
aws rds modify-db-instance \
--db-instance-identifier YOUR_DB_INSTANCE_ID \
--monitoring-interval 0 \
--apply-immediatelyPricing and Cost Estimates
Enhanced Monitoring itself adds no RDS charges. However, because metrics are written to CloudWatch Logs, you pay for CloudWatch Logs data ingestion and storage. The data volume is directly proportional to your granularity. The following figures are from the official AWS RDS FAQ:
Pricing disclaimer: AWS pricing and data-volume examples may change by Region and over time. The estimates below use the AWS RDS FAQ example and us-east-1 CloudWatch Logs ingestion pricing. Actual costs depend on Region, retention, free-tier eligibility, log storage, and the number of RDS instances monitored.
| Granularity | Data / month (GB) | Approx. cost (us-east-1) |
|---|---|---|
| 60 seconds | 0.27 | ~$0.14 |
| 30 seconds | 0.53 | ~$0.27 |
| 15 seconds | 1.07 | ~$0.54 |
| 10 seconds | 1.61 | ~$0.81 |
| 5 seconds | 3.21 | ~$1.61 |
| 1 second | 16.07 | ~$8.04 |
* us-east-1 CloudWatch Logs ingestion at $0.50/GB. Storage ($0.03/GB/month after first 5 GB free) adds a small additional amount. Multiply costs by the number of instances monitored.
Cost tip
Use 60-second granularity as your default. Enable 1 to 5 second intervals only when actively debugging a performance issue, then revert. You can also reduce the RDSOSMetrics log group retention (default: 30 days) to control storage costs.
CloudWatch Logs may include free-tier usage depending on account eligibility. After that, Enhanced Monitoring logs are billed using standard CloudWatch Logs ingestion and storage rates.
Go beyond RDS Enhanced Monitoring with CubeAPM
RDS Enhanced Monitoring gives you OS-level metrics. CubeAPM goes further, correlating those metrics with application traces, slow query analysis, logs, and real-time alerts in one platform. No data leaves your VPC, costs 60-80% less than Datadog or New Relic, and deploys in minutes via OpenTelemetry.
+ Correlate RDS OS metrics with app traces and logs in one view
+ Runs inside your VPC – no telemetry leaves your cloud
+ OpenTelemetry-native with 800+ integrations including RDS, EC2, and EKS
+ Smart sampling cuts storage by up to 95% – predictable per-GB pricing
+ Unlimited data retention – no 30-day CloudWatch Logs expiry to worry about
Technology disclaimer: AWS monitoring features, pricing models, retention rules, IAM requirements, and supported database engines can change over time. This guide is based on publicly available AWS documentation at the time of writing. Before enabling Enhanced Monitoring in production, confirm the latest details in the official AWS RDS and CloudWatch documentation.
FAQs
1. Does enabling Enhanced Monitoring require a reboot?
No. Enabling or changing the granularity of Enhanced Monitoring does not restart your DB instance. The change applies immediately when you use –apply-immediately.
2. Is there any performance overhead on my database?
Minimal. The monitoring agent runs on the host OS, not inside the DB engine. AWS states the overhead is negligible for production workloads. For production teams, CubeAPM can help place these OS-level metrics beside application behavior, so database slowdowns are easier to investigate in context.
3. Can I use Enhanced Monitoring with RDS Multi-AZ?
Yes. Enhanced Monitoring works with Multi-AZ deployments. For standard RDS DB instances, configure it on the DB instance. For Multi-AZ DB clusters, configure it at the cluster level with modify-db-cluster.
4. How is Enhanced Monitoring different from Performance Insights?
They are complementary. Enhanced Monitoring is OS-level: it shows CPU steal, memory pressure, and disk queue depth, which are useful for infrastructure-level bottlenecks. Performance Insights is SQL-level: it shows database load by wait type, query, host, or user, which is useful for tuning slow queries. Use both together for complete visibility.
5. Where exactly is the data stored?
In a CloudWatch Logs log group called RDSOSMetrics. Each RDS instance gets its own log stream named after its resourceId. You can query it with CloudWatch Logs Insights or export it via subscription filters.
6. Does Enhanced Monitoring work for Aurora?
Yes. For Aurora clusters, you configure Enhanced Monitoring at the cluster level or override it at the instance level using the same MonitoringInterval and MonitoringRoleArn parameters.





