RDS Auto Minor Version Upgrade Disabled: Why It Matters and How to Fix It

Patching a database is one of those chores nobody wants to schedule manually, which is exactly why AWS lets RDS handle minor version upgrades for you. When that setting is off, your instance stops receiving the patch releases that fix bugs and close security holes in the engine. The Lensix check rds_nominorupgrade catches RDS instances where Auto Minor Version Upgrade is disabled so you can turn it back on before a known CVE catches up with you.

---

What this check detects

Every RDS instance has a property called AutoMinorVersionUpgrade. When it is set to true, AWS automatically applies eligible minor engine version upgrades during your scheduled maintenance window. A minor version is something like moving from PostgreSQL 15.4 to 15.5, or MySQL 8.0.35 to 8.0.36. These releases ship security patches, stability fixes, and small improvements without breaking compatibility.

This check fails when it finds an instance with AutoMinorVersionUpgrade set to false. That means the database stays pinned to whatever minor version it was launched or last manually upgraded to, and it will not pick up new patches on its own.

---

Why it matters

Minor releases are where database engines ship the bulk of their security fixes. A PostgreSQL minor release, for example, often bundles fixes for several CVEs at once. If auto upgrade is off and nobody is manually patching, your instance accumulates known vulnerabilities that attackers can look up in public advisories.

The risk is not theoretical. Consider these scenarios:

• Exposed credentials plus an unpatched CVE. If an attacker gets a foothold through a leaked connection string or an SSRF bug in your app, an outdated engine gives them privilege escalation or remote code execution paths that newer versions have already closed.
• Compliance drift. Frameworks like PCI DSS, SOC 2, and HIPAA expect timely patching of systems that handle sensitive data. An auditor who finds a database three minor versions behind will flag it.
• End-of-life surprises. When AWS deprecates a minor version, instances that have not kept current can be force-upgraded on AWS's schedule, often with less warning than you would like.
• Compounding upgrade debt. The longer you skip patches, the larger the version gap becomes, which makes the eventual catch-up upgrade riskier and harder to test.

Leaving this off is usually not a deliberate decision. It tends to happen because the instance was created from an old Terraform module, copied from another instance, or restored from a snapshot that carried the setting over. Either way, the database quietly stops getting patched and nobody notices until something goes wrong.

---

How to fix it

The fix is to set AutoMinorVersionUpgrade back to true. You can do this from the console, the CLI, or your infrastructure as code, and it does not require recreating the instance.

Option 1: AWS Console

1. Open the RDS console and select Databases.
2. Choose the instance, then click Modify.
3. Scroll to Maintenance and check Enable auto minor version upgrade.
4. Click Continue, choose to apply during the next maintenance window, and confirm.

Option 2: AWS CLI

Enable the setting on a single instance:

aws rds modify-db-instance \
  --db-instance-identifier my-prod-db \
  --auto-minor-version-upgrade \
  --apply-immediately

To apply during the maintenance window rather than immediately:

aws rds modify-db-instance \
  --db-instance-identifier my-prod-db \
  --auto-minor-version-upgrade \
  --no-apply-immediately

If you have a maintenance window that does not line up with your low-traffic hours, set it explicitly so patches apply at a sensible time:

aws rds modify-db-instance \
  --db-instance-identifier my-prod-db \
  --auto-minor-version-upgrade \
  --preferred-maintenance-window "sun:06:00-sun:07:00"

Find every instance in a region that still has the setting disabled:

aws rds describe-db-instances \
  --query "DBInstances[?AutoMinorVersionUpgrade==\`false\`].DBInstanceIdentifier" \
  --output table

Option 3: Terraform

Set the attribute on your aws_db_instance resource so the fix is permanent and tracked in code:

resource "aws_db_instance" "prod" {
  identifier                  = "my-prod-db"
  engine                      = "postgres"
  engine_version              = "15.5"
  instance_class              = "db.m6g.large"
  auto_minor_version_upgrade  = true
  maintenance_window          = "sun:06:00-sun:07:00"
  # ... other settings
}

Option 4: CloudFormation

{
  "Type": "AWS::RDS::DBInstance",
  "Properties": {
    "DBInstanceIdentifier": "my-prod-db",
    "Engine": "postgres",
    "AutoMinorVersionUpgrade": true,
    "PreferredMaintenanceWindow": "sun:06:00-sun:07:00"
  }
}

---

How to prevent it from happening again

Fixing one instance is easy. Keeping every new instance compliant is the real goal. Bake the requirement into the places where databases get created.

Catch it in CI/CD with policy as code

If you provision RDS through Terraform, add a Checkov or OPA check that blocks any plan where the setting is off. Checkov ships a built-in rule for this:

checkov -d . --check CKV_AWS_226

For a custom OPA/Conftest rule against a Terraform plan:

package terraform.rds

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_db_instance"
  resource.change.after.auto_minor_version_upgrade == false
  msg := sprintf("RDS instance '%s' must enable auto_minor_version_upgrade", [resource.address])
}

Enforce at runtime with AWS Config

AWS Config has a managed rule, rds-instance-minor-version-upgrade-enabled, that continuously evaluates every RDS instance and reports any with the setting disabled. Pair it with a remediation action to auto-correct drift:

aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "rds-minor-upgrade-enabled",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "RDS_INSTANCE_MINOR_VERSION_UPGRADE_ENABLED"
    }
  }'

Standardize on a module

The most reliable fix is to make sure nobody hand-rolls RDS resources. Provide a shared Terraform module with auto_minor_version_upgrade defaulted to true and require teams to use it. That way the safe default is the path of least resistance.

---

Best practices

• Keep auto minor upgrades on everywhere by default. There are very few good reasons to disable it. If you have one, document it and set an expiry date for the exception.
• Set maintenance windows to match your quiet hours. Auto upgrades apply during this window, so put it where a brief failover or restart causes the least disruption.
• Run Multi-AZ for production. With a standby in place, RDS applies patches to the standby first and fails over, which cuts the upgrade downtime to seconds instead of minutes.
• Test minor upgrades in lower environments first. Even minor releases occasionally change behavior. Let staging take the upgrade a few days ahead of production so you catch surprises early.
• Plan major version upgrades separately. Auto upgrade never handles majors. Track engine end-of-life dates and schedule those upgrades deliberately with proper testing.
• Watch pending maintenance. Use aws rds describe-pending-maintenance-actions to see what upgrades are queued so nothing lands unexpectedly.

Auto minor version upgrades are a quiet bit of housekeeping that pays off the moment a CVE drops for your engine. Turn the setting on, point the maintenance window at your quiet hours, and let AWS handle the patching so your team can spend its attention elsewhere.