RDS Performance Insights Disabled: Why It Matters and How to Fix It

When an RDS database starts crawling at 2am, the questions come fast: which query is eating the CPU, is it a lock, is it a missing index, or is the instance just undersized? Without the right telemetry, answering those questions means guessing. Performance Insights exists to remove the guesswork, and this check fires when an RDS instance has it switched off.

This post explains what the check looks for, why a disabled Performance Insights configuration is a real operational risk, and how to fix it across the console, CLI, and infrastructure as code.

---

What this check detects

The rds_noperformanceinsights check inspects each Amazon RDS DB instance and reports any instance where the PerformanceInsightsEnabled attribute is set to false. It applies to RDS engines that support the feature, including Aurora, PostgreSQL, MySQL, MariaDB, Oracle, and SQL Server.

Performance Insights is a database performance tuning and monitoring feature. It captures database load broken down by wait events, top SQL statements, hosts, and users, then stores that data so you can look back in time. When it is disabled, none of that history is collected, and you are left with the coarser metrics that CloudWatch provides by default.

---

Why it matters

Default CloudWatch metrics tell you that something is wrong. CPU is at 95 percent, or read latency spiked. They rarely tell you why. Performance Insights closes that gap, and the absence of it shows up at the worst possible moments.

Slower incident response

During a live incident, the fastest path to resolution is identifying the offending query or wait event. Without Performance Insights, your team falls back to running ad hoc queries against pg_stat_activity or SHOW PROCESSLIST, often while the database is already struggling. That adds load to a system that is already in trouble, and it only captures a snapshot of the present moment, not the period when the problem started.

No historical context

A query that ran fine for months can degrade gradually as a table grows or statistics drift. Performance Insights retains up to 7 days of data for free, and longer with the paid tier, so you can correlate a slowdown with a deployment, a data load, or a traffic spike. Enabling it after the incident does nothing for the incident you are currently investigating.

Capacity and cost decisions made blind

Right-sizing an RDS instance without load data usually means overprovisioning to be safe. Performance Insights shows whether you are genuinely CPU bound or whether the load is dominated by I/O waits that a different storage configuration would fix. That distinction directly affects your bill.

---

How to fix it

Enabling Performance Insights on an existing instance is a low-risk operation and does not require a reboot for most engines.

AWS Console

1. Open the RDS console and select the DB instance.
2. Click Modify.
3. Scroll to the Monitoring section.
4. Check Enable Performance Insights.
5. Choose a retention period. The free tier gives you 7 days. Longer retention (up to 2 years) is billed.
6. Select a KMS key for encrypting the Performance Insights data, or accept the default key.
7. Choose Apply immediately, then click Modify DB instance.

AWS CLI

For a standard RDS instance:

aws rds modify-db-instance \
  --db-instance-identifier my-prod-db \
  --enable-performance-insights \
  --performance-insights-retention-period 7 \
  --performance-insights-kms-key-id alpha:aws:kms:us-east-1:111122223333:key/abcd1234-... \
  --apply-immediately

For Aurora, Performance Insights is configured per DB instance in the cluster, not on the cluster itself:

aws rds modify-db-instance \
  --db-instance-identifier my-aurora-writer \
  --enable-performance-insights \
  --performance-insights-retention-period 7 \
  --apply-immediately

Terraform

For the aws_db_instance resource:

resource "aws_db_instance" "prod" {
  identifier     = "my-prod-db"
  engine         = "postgres"
  instance_class = "db.r6g.large"

  performance_insights_enabled          = true
  performance_insights_retention_period = 7
  performance_insights_kms_key_id       = aws_kms_key.pi.arn

  # ... other settings
}

For Aurora cluster instances:

resource "aws_rds_cluster_instance" "writer" {
  identifier         = "my-aurora-writer"
  cluster_identifier = aws_rds_cluster.main.id
  instance_class     = "db.r6g.large"
  engine             = aws_rds_cluster.main.engine

  performance_insights_enabled          = true
  performance_insights_retention_period = 7
}

---

How to prevent it from recurring

Fixing one instance is easy. Keeping the whole fleet compliant requires guardrails that catch a disabled configuration before it reaches production.

Policy as code in CI/CD

If you provision RDS through Terraform, add a Checkov or OPA gate to your pipeline. Checkov ships with a built-in policy for this:

checkov -d . --check CKV_AWS_118

For a custom Conftest policy using Rego:

package main

deny[msg] {
  resource := input.resource.aws_db_instance[name]
  not resource.performance_insights_enabled
  msg := sprintf("RDS instance '%s' must enable Performance Insights", [name])
}

Detect drift with AWS Config

The managed AWS Config rule rds-instance-default-admin-check does not cover this, so use a custom rule backed by Lambda, or rely on a scanner that continuously evaluates live state. The goal is to catch instances that were created outside of your IaC pipeline, where policy-as-code never had a chance to run.

---

Best practices

• Enable it on every production and staging instance. The free 7-day tier costs nothing and the data is invaluable when you need it.
• Pair it with Enhanced Monitoring. Performance Insights shows database-level waits, while Enhanced Monitoring exposes OS-level metrics like per-process CPU and memory. Together they cover the full picture.
• Use a customer-managed KMS key for the Performance Insights data store if your compliance requirements call for key rotation control and explicit audit trails.
• Match retention to your review cadence. Teams that do weekly performance reviews are well served by 7 days. Teams investigating slow seasonal trends may justify the paid long-term retention.
• Build dashboards around AAS versus vCPU count. A sustained AAS above your vCPU line is the clearest single signal that an instance needs tuning or scaling.

The cheapest time to enable observability is before you need it. Performance Insights is free at the base tier, so there is no reason to leave it off and discover the gap mid-incident.

Turn it on across the fleet, gate it in your pipeline, and let a continuous scanner catch the stragglers. Your future self, paged at 2am, will thank you.